Security model

Where the trust boundary actually sits

Sproobo holds as little of your data as it can get away with, and is built so the platform can never lock you out of a box you own. This page covers the mechanics behind that: identity, data ownership, builds, network exposure, and audit.

Trust boundaries

The control plane is the brain: it compiles desired state into plans and decides what should happen. The agent is a thin executor: it only runs the typed steps it's handed and reports back — it never freelances shell commands.

The agent's identity is an mTLS client certificate, issued once a single-use enroll token is redeemed. That certificate is short-lived and auto-rotated before expiry: the control plane issues a new cert, the agent adopts it, and only then is the old one revoked — an overlap window means there is never a moment with zero valid credentials. Every connection is checked against the current certificate fingerprint; a revoked or unrecognized certificate is rejected and the server is flagged for re-enrollment.

Data ownership: bind mounts, not volumes

Durable data — app uploads, database files, anything that has to survive a container restart — lives on bind-mounted host directories under /var/lib/sproobo/..., never in Docker named volumes.

  • It survives docker compose down -v and docker volume prune — those commands can't touch a bind mount.
  • It's excluded from any prune or cleanup sweep, and soft-deleted before actual removal.
  • It's inspectable and recoverable with plain tools: ls, tar, rsync — no Sproobo client needed. If Sproobo disappeared tomorrow, the directory tree is still yours.
  • An off-box backup is mandatory before any destructive or upgrade operation touches a stateful service's data.

Builds never run on your box

Every image is built off-box, in a control-plane builder with capped CPU, RAM, and disk — never as a docker build on the customer server. A runaway build can't OOM your box or fill the disk out from under a database's data directory, because it was never running there in the first place. The agent only ever pulls a finished, tagged image from the Sproobo-managed registry.

No exposed service ports, by construction

Backing services — Postgres, MySQL, MariaDB, Redis, and the rest — are never published to 0.0.0.0. Apps reach them, and the proxy reaches apps, over an internal Docker network by container DNS name. There is nothing listening on a public port for an attacker to find, and the firewall never has to be trusted to compensate for a port that shouldn't have been open.

The audit trail

Every mutating operation checks the caller's org role (OWNER, ADMIN, MEMBER, VIEWER) and writes an immutable audit record — actor, action, and the before/after state. AI-driven actions are tagged distinctly from human ones in that same record, because AI rides the identical audited API a human uses: no separate, more powerful path, and destructive operations are plan-first and approval-gated either way.

Payments never touch Sproobo either.

Billing runs through Stripe as our Merchant of Record — Stripe collects and handles payment details directly, so your card data never touches Sproobo's systems.

What Sproobo stores vs. what stays on your box

Sproobo's Postgres holds intent, configuration, and audit history:

  • Org/server/app/service records, desired-state configuration, and secrets (encrypted).
  • Deploy and task history, and the audit log described above.

It does not hold your application's logs or metrics. Those stay on the box and are read live, on demand, straight from the agent — see Security & ownership for how that sovereign-telemetry model shows up in the dashboard.

Next