Deployment models

Obexum is a single self-contained Go binary — about 41 MB, no runtime dependencies, no installer service, no agent left behind on the target. The audit logic, the 620-check catalogue, the remediation playbooks and a bundled CVE snapshot are all embedded in the binary, so it runs the same way connected or fully air-gapped. The binary never phones home: it has no telemetry and makes no network calls of its own. The only time it talks to the network is when you point it at a target, or when you explicitly hand it a portal token to upload a result.

Everything below is a way of running that one binary. Pick the model that matches how you reach your hosts and where you want the data to live; they are not mutually exclusive, and many teams use two or three at once (a laptop for ad-hoc work, a jump-box for the fleet, CI for the gate).

1. Local / single host

The binary runs on the machine it audits and inspects that same host directly — no SSH hop, no second box. This is the default local://localhost target.

When to use it

• You are hardening or auditing the box you are already logged into.
• A host can only be reached by someone sitting on it (no inbound SSH, or policy forbids remote admin).
• Quick one-off checks, a developer workstation, or learning the tool.

How the binary is obtained

Download the signed build for that host's OS from Account → Builds, copy it onto the machine, and run it. On Linux/BSD that is typically chmod +x obexum && sudo mv obexum /usr/local/bin/; on Windows it is the signed obexum.exe.

How the target is reached

It isn't reached — it's local. Run obexum scan with no target (defaults to local), or be explicit with obexum scan --target local://localhost. The scan reads local files, registry/service state and process information directly. Run it with enough privilege to see what it audits (root / Administrator) for complete coverage. A built-in local dashboard is available with obexum gui, which binds to 127.0.0.1:7070 by default.

Data residency

Fully local. History and diff state live in a SQLite database at ~/.obexum/obexum.db, and reports (Markdown, JSON, HTML, SARIF) are written under ~/.obexum/scans/. Nothing leaves the host unless you choose to upload it.

2. Jump-box auditing many hosts

One trusted machine — a bastion, an audit VM, an admin workstation — runs the binary and reaches the rest of the fleet remotely: SSH for Linux and BSD hosts, and OpenSSH for Windows. The targets stay clean; only the jump-box has the binary.

When to use it

• You audit a fleet and don't want to copy a binary onto every host.
• Centralised credentials/keys and a single egress point for the auditor.
• Recurring engagements where you keep a named inventory of targets.

How the binary is obtained

Download one signed build per target OS from Account → Builds and keep them on the jump-box. The build matches the OS being audited, so a mixed estate means a small handful of binaries on the bastion — not one per host.

How targets are reached

Register hosts once and scan them by short name:

obexum targets add prod-dc-01 --type windows-dc --host 10.0.0.5 --user Administrator
obexum targets add web-07     --type ssh        --host 10.0.2.7 --user root --key ~/.obexum/keys/obexum_ed25519
obexum scan --target prod-dc-01

Target types are ssh, windows, windows-dc and local; the SSH port defaults to 22 and can be overridden with --port. You can also scan a host directly by spec without registering it — e.g. obexum scan --target ssh://root@10.0.2.7 or obexum scan --target local://localhost. Obexum connects over your existing SSH transport, runs read-only checks, and disconnects — it installs no agent and leaves no service running on the target.

Data residency

Results land on the jump-box — SQLite history at ~/.obexum/obexum.db, report files under ~/.obexum/scans/. Target hosts store nothing. If you want shared dashboards across a team, add the portal (model 5) on top of this.

3. CI/CD pipeline

The binary runs inside a pipeline as a gate — build an image or provision a host, scan it, and pass or fail the stage on the result. Because it is a single static binary with no dependencies and emits machine formats (JSON and SARIF), it drops into any runner.

When to use it

• Golden-image / hardened-base pipelines that must not regress.
• Infrastructure-as-code changes you want audited before they ship.
• Continuous compliance evidence on every build.

How the binary is obtained

Download the signed per-OS build once and vendor it into the runner image, a package registry, or an artifact store your pipeline already trusts. Pin the version so builds are reproducible. No network fetch from us is needed at run time.

How targets are reached

Usually the runner scans local://localhost against the image or container it just built. To audit a freshly provisioned host instead, point it over SSH exactly as a jump-box would (--target ssh://…). Drive everything non-interactively: ask for SARIF with -f sarif to feed your code-scanning dashboard, or JSON with -f json to parse yourself, and use the scan exit status to fail the job.

Data residency

Artifacts stay in your pipeline — report files in the workspace, SARIF in your code-scanning store, JSON wherever you archive build output. Nothing is sent anywhere by default. If you want the trend in the portal, add an upload step (model 5) using an engagement token from CI secrets.

4. Air-gapped

Obexum is built to run with no internet access at all. The audit catalogue, remediation playbooks and a bundled CVE snapshot are compiled into the binary, so an offline scan produces the same findings and the same remediation guidance as a connected one.

When to use it

• Classified, OT/ICS, or otherwise isolated networks with no egress.
• Environments where carrying data in or out is a controlled, audited act.
• Anywhere a tool that "calls home" is simply not allowed.

How the binary is obtained

On a connected machine, download the signed per-OS build from Account → Builds, verify its signature, then carry it across the air-gap on removable media into the enclave. Nothing else needs to cross the boundary for scanning to work.

How targets are reached

Inside the enclave it behaves like model 1 or 2: scan the local host with local://localhost, or reach other isolated hosts over SSH within the same network. No outbound connection is ever attempted; the CVE data it correlates against is the embedded snapshot from the build you carried in. To refresh that data, bring in a newer signed build the same way.

Data residency

Everything stays inside the enclave — SQLite history and report files on the machine that ran the scan. To get results out for review, export the report files and move them across the air-gap deliberately. The hosted portal is, by design, not part of this model; if you want dashboards in an isolated network, run the portal self-managed inside it (model 5).

5. Hosted portal vs self-managed

The scanner is complete on its own — you can run every model above and never touch a portal. The portal is an optional layer on top that adds web dashboards, scan history across hosts, time-series trends and shared, multi-user engagements. The binary is the same in both cases; the only difference is whether scan results are uploaded and, if so, to whose server.

Self-managed (scanner only)

Don't upload anything. Results live solely on the machine that ran the scan — SQLite at ~/.obexum/obexum.db and report files under ~/.obexum/scans/ — and you share HTML/PDF/JSON reports however you already share files. This is the right default for air-gapped work and for anyone who wants zero data leaving their own infrastructure.

Hosted portal (this site)

Create an engagement in the portal, which mints a per-engagement upload token (a scoped JWT). The scanner uploads only when you hand it that token:

obexum scan --target ssh://Administrator@10.0.0.5 --upload-token $OBX_ENGAGEMENT_JWT

After the scan completes, the result JSON (plus a small host-metadata block) is POSTed over HTTPS to /api/v1/scans, authenticated with that engagement token — nothing else is sent, and the upload is idempotent so retries are safe. Builds downloaded from the portal can be built with the token pre-embedded, so a scoped binary uploads automatically with no extra flag. Upload is always opt-in: no token, no upload.

Self-managed portal

If you want the dashboards but not the multi-tenant hosted service, the portal can run on infrastructure you control (it is a Go service backed by PostgreSQL, typically fronted by a TLS reverse proxy such as Caddy). Point the scanner at it with --portal-url:

obexum scan --target ssh://Administrator@10.0.0.5 --upload-token $JWT --portal-url https://obexum.internal.example.com

In this arrangement every byte — scans, findings, history — stays in your PostgreSQL on your network, including in an isolated enclave. You get the shared-dashboard experience with the same data-residency guarantee as scanner-only.

Where the data lives, at a glance

Next steps

• Quickstart — install, register a target, run your first scan.
• CLI reference — every command and flag (scan, targets, diff, sbom, …).
• Configuration — what lives in ~/.obexum/config.yaml.
• REST API — the portal endpoints, including /api/v1/scans.