Database infrastructure requires more than a login screen.
Fleetdock holds the keys to your database fleet, so its security model is documented in the open — including the boundaries it does not yet cover.
Know what each component can do.
Understanding where trust lives is the first step to deploying Fleetdock safely.
Manager privileges
The Manager stores encrypted credentials for the whole fleet and can enqueue operations on every node. It is the highest-value component — protect it accordingly.
Agent privileges
Each agent runs as root on its node — Docker provisioning requires it — inside a sandboxed systemd unit. Its authority is scoped to that single node, and its token can be revoked or rotated at any time.
Docker socket access
Provisioning uses Docker on the node, so the agent can create and remove database containers and their data volumes on that host.
External database access
For external instances, the control plane connects directly to the database host and port using stored admin credentials. Prefer private network paths.
Public database endpoints
Exposing a database to the internet is off by default and enabled per database. Traffic passes through the gateway on a dedicated port with a CIDR allowlist enforced at the proxy — never by publishing the database port directly.
Application credentials
External apps connect with scoped users (readonly, readwrite, or admin on one database), created and revoked from the dashboard. Instance root credentials are never exposed for public use.
Plan for the bad day, honestly.
We document the impact of each failure mode instead of hiding it. This is what to reason about before exposing the control plane.
Manager compromise
The largest blast radius: an attacker could reach every stored credential and command every agent. Keep it behind TLS, restrict access, and monitor the operations log.
Agent compromise
Limited to that node's databases and Docker host, but the data on that node is exposed. Isolate nodes and use least-privilege database users.
Database credential exposure
Store least-privilege admin users so a leaked credential cannot do more than its grants allow. Rotate the credential and re-test the connection.
Backup credential exposure
Storage keys are encrypted at rest on the Manager and never handed to agents; presigned URLs are time-limited. Rotate keys and keep buckets private.
What the current release already does.
- HttpOnly, SameSite=Strict session cookies with CSRF protection — script cannot read the session
- Single-use, short-lived agent registration tokens
- Per-server agent token revocation and rotation, with one-time re-enroll commands
- Agent runs inside a sandboxed systemd unit (no new privileges, read-only system paths)
- Envelope-encrypted secrets with operator-controlled key rotation
- Changing a password invalidates that user's existing sessions everywhere
- SSRF-resistant outbound HTTP — webhooks cannot reach loopback or cloud metadata
- Public database access off by default, with CIDR allowlists at the proxy
- Presigned-URL backups — agents never receive storage credentials
- Role-based access control and scoped, revocable API tokens
- Login rate limiting, Content-Security-Policy and security headers, and health/readiness probes
- Multiple replicas can share one metadata database — jobs and housekeeping are locked in Postgres
- Automatic HTTPS, with the API reachable only through the proxy
- Production mode that refuses to boot with default secrets
Current limitations
- SSO/OIDC and 2FA are on the roadmap, not yet available.
- The agent runs as root (required to drive Docker), inside a sandboxed systemd unit.
- Audit events are recorded but not yet exposed through the API or dashboard.
- Gateway TLS is passthrough only, with one public port per database.
- Closed-port access to external databases (Cloudflare Tunnel / TCP proxy) is on the roadmap, not in the current release.
Stop managing databases one server at a time.
Connect your infrastructure, standardize database operations, and manage every instance from one control plane.