Security
It reads. It doesn't take over.
Wharfbase holds the keys to your databases and sits next to Docker, so it is built to give away as little as possible if something goes wrong.
No Docker socket
Wharfbase talks to Docker through socket-guard, a small proxy that forwards only an allowlist: reading containers, networks and volumes, joining a network for Wharfbase itself, and helper containers from official database images without host access. Even a compromised Wharfbase can’t start a privileged container.
Locked-down containers
Non-root, every capability dropped, a read-only filesystem, no-new-privileges. Images are signed, scanned and shipped with an SBOM.
Your passwords stay yours
Database passwords are stored only if you ask, encrypted with AES-256-GCM under a master key kept outside the data volume. Secret values in containers are read only when you ask for them, and that is audited.
Read-only means read-only
Production databases open read-only. Read-only connections are enforced by the database where it can be (PostgreSQL and MySQL sessions, ClickHouse, Neo4j), and every statement is checked the way the server will read it.
Who did what
Roles, per-database permissions, two-factor sign-in that admins can require, SSO on Team, and a hash-chained audit log.
Nothing leaves
No telemetry unless you turn it on, and then you see the report first. No analytics on this site either. The update check asks for a version number and sends nothing. A paid license checks in once a day with three counts, never anything from your databases.
How it is checked
- An OWASP ASVS Level 2 review, with every finding and its fix.
- Property-based fuzzing of the query compilers, the read-only checks and the socket-guard, nightly.
- Dependency audits and govulncheck in every build, and Renovate for updates.
Found a problem? Please report it privately, as the security policy describes. The details are in the security model.