Apex appliances
Apex is an appliance that runs assessment work inside your network. Where a scanner executes discovery and vulnerability tasks handed to it, Apex additionally runs guided assessment sessions - scans, vulnerability scans, campaigns, and scheduled work - and produces reports from them.
It ships as cyberoptix.apex and runs a single service, apex-daemon, which polls for
work every 30 seconds.
Before you start
- Ubuntu Server 24.04, with root or sudo access.
- Outbound HTTPS to your platform's API hostname. No inbound connections are needed.
- Your organization ID from the platform.
redis-serveron the host. The daemon orders itself after it and will not work without it.
Install
If this host has never had a Purple Team Software package on it, add the repository.
Include the rm -f - gpg --dearmor prompts before overwriting an existing keyring, and
on a re-run that prompt has nothing attached to answer it:
sudo rm -f /usr/share/keyrings/purpleteamsoftware-archive-keyring.gpg
wget -O - https://apt.fury.io/purpleteamsoftware/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/purpleteamsoftware-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/purpleteamsoftware-archive-keyring.gpg] https://apt.purpleteamsoftware.com/ /" | sudo tee /etc/apt/sources.list.d/purpleteamsoftware.list
sudo apt update && sudo apt install cyberoptix.apex -y
Installation also provisions the scanning toolchain and grants it the narrow privileges
it needs: nmap gets raw-socket capability through setcap, and a scoped
/etc/sudoers.d/cyberoptix-apex allows dmidecode (for the hardware UUID) and the
account-management commands Apex uses to provision logins.
The daemon runs as the unprivileged optix user. Everything it needs beyond that is
granted narrowly rather than by running the whole appliance privileged, which is why the
sudoers file lists specific commands instead of a blanket rule.
Link it to your organization
Installing does nothing on its own. Linking binds the appliance to your organization:
sudo apex link --url https://<your-api-hostname> --organization_id <your-organization-id>
That writes baseurl, credentials, mode and organization_id to
/etc/optix/apex-config.json.
Linking is also what enables the assessment features that call out to a language model. Those requests are proxied through the platform API rather than going direct, so key management and billing stay on the platform side and the appliance holds no model provider credentials of its own. An unlinked Apex has no access to them at all.
Start the daemon
sudo systemctl enable --now apex-daemon.service
systemctl status --no-pager apex-daemon redis-server
Both should be active (running). The daemon polls every 30 seconds, so give it that long before concluding nothing is happening:
sudo journalctl -u apex-daemon.service -f
Then confirm the appliance appears in the platform under Validation Operations.
Configuration
Defaults live in /etc/optix/apex.yaml. The settings worth knowing:
| Setting | Default | Purpose |
|---|---|---|
agent.max_concurrent_tools | 5 | How many tools run at once |
agent.default_timeout_secs | 30 | Per-tool timeout |
agent.session_dir | /var/lib/optix/apex/sessions | Where session state is kept |
safety.allowed_scope | empty | Targets Apex may act on |
safety.no_go_zones | empty | Targets it must never touch |
safety.max_risk_level | medium | Ceiling on action risk |
safety.allowed_scope and no_go_zonesBoth ship empty. These are the appliance's own guardrails, and they are the difference between an assessment confined to what you intended and one that reaches further. Set them before running anything against a production network.
Running work
Apex is driven from the platform, but the same operations are available locally:
apex scan --help
apex vulnscan --help
apex campaign --help
apex report --help
A session interrupted part-way can be picked up rather than restarted:
apex resume --help
apex version
Next
- Scanners - the lighter-weight alternative for pure discovery and scanning
- Troubleshooting - an appliance that is not reporting in