Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.dbhost.app/llms.txt

Use this file to discover all available pages before exploring further.

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