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 today and executes approved operations locally. Its authority is scoped to that single node and the databases on it.
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.
- Single-use, short-lived agent registration tokens
- 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, security headers, and health/readiness probes
- Automatic HTTPS, with the API reachable only through the proxy
- Production mode that refuses to boot with default secrets
Current limitations
- The dashboard stores its session token in
localStorage, which is exposed to XSS. Deploy behind TLS on a trusted network. - SSO/OIDC and 2FA are on the roadmap, not yet available.
- The agent runs as root via systemd today.
- 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.