Skip to main content
DBHost is built for developers who want safer defaults without turning Postgres into its own side project. For the shorter product-facing overview, see the public security page.

​
Current security model

DBHost separates the control plane from the data plane:
  • The control plane handles auth, dashboard actions, API keys, and metadata
  • The data plane runs PostgreSQL, PgBouncer, backups, and the internal agent that performs database operations
Customer-facing operations stay tenant-scoped. Direct PostgreSQL access still uses the database credentials shown on the database detail page, while the dashboard explorer and public API stay behind tighter product boundaries.

​
Access and authentication

  • Dashboard access uses Clerk authentication
  • REST API access uses DBHost API keys
  • API keys are scoped either to the full account or to selected databases
  • Selected-database keys cannot create databases or operate outside their assigned scope
  • The internal agent is not a customer auth surface; it is called by the control plane with separate internal credentials
For user-facing setup details, see API authentication and API keys.

​
Guarded SQL exploration

The in-dashboard SQL Explorer is intentionally tighter than a normal database client:
  • owner-only
  • read-only
  • limited to the public schema
  • executed through a dedicated explorer role
  • validated before queries run
This keeps the explorer useful for inspection and one-off reads without turning it into a broad write surface.

​
Abuse resistance

DBHost now adds basic server-side abuse controls for curl, scripts, bots, and direct HTTP clients:
  • request-size limits on public API routes and on the internal agent
  • rate limiting on public API routes and agent endpoints
  • auth-failure and abuse logging at the edge
  • Caddy access logging plus fail2ban on the VPS
  • host firewall rules around the data plane
These controls are designed to slow probing and noisy abuse without changing the public API contract.
CORS is not treated as a security boundary. Browser origin checks help with browser behavior, but direct HTTP clients still need proper authentication and server-side controls.

​
Operational safeguards

  • every database sits behind PgBouncer on port 6432
  • per-database IP allowlists are enforced at the pool layer
  • daily automated backups run with 30-day retention
  • on-demand backups can be triggered before risky changes
  • tenant database passwords are encrypted at rest in the control plane

​
Honest limits

DBHost is a strong fit for:
  • small SaaS apps
  • internal tools
  • staging environments
  • agencies managing several app databases
DBHost does not currently position itself as:
  • a multi-region database platform
  • a read-replica or PITR-heavy platform
  • a compliance certification product
That matters because security claims are only useful when they match the actual product surface.

​
Next steps