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 on Pro and Business 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
  • rate limiting on public API routes
  • auth-failure and abuse logging at the edge
  • host firewall rules around the data plane
These controls are designed to slow probing and noisy abuse without changing the public API contract.

​
Temporary blocks after repeated failed logins

If one IP address sends 30 or more failed logins to a database connection (port 6432) within 10 minutes, DBHost blocks that address on port 6432 only. Nothing else is affected: the dashboard, the API and every other port stay reachable from that address.
  • The first block lasts 5 minutes and lifts by itself. A repeat block within a day lasts 15 minutes, which is the longest block there is.
  • Common cause: you rotated a database password, and an app instance or retry loop still uses the old one. Update every client to the new password. Connections work again as soon as the block lifts.
  • Addresses shared by many apps (serverless platforms such as Vercel) can be blocked by failures from another app on the same address. The block is short, and it clears without any action from you.
  • Successful logins are never counted, and a block never removes data or changes your database.
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 application connection goes through PgBouncer on port 6432 with required TLS (connect with sslmode=verify-full); the only direct path is a short-lived, IP-restricted migration lease on migrate.dbhost.app:5432
  • per-database IP allowlists are enforced at the pool layer
  • SQL roles and a per-database PgBouncer server cap limit access and pooled connections; shared CPU, memory, and disk are not hard-isolated per customer
  • production databases always receive daily logical backups kept for 30 days; staging, development, other and preview databases follow their backup choice (details)
  • on-demand backups can be triggered before risky changes
  • tenant database passwords are encrypted at rest in the control plane
  • destructive operations require a managed-registry binding, a matching operation ID and database ID/name binding, an explicit capability, and a target outside the permanent protected list
  • dbhost, postgres, template0, template1, and the agent auth/registry databases are permanently protected from drop, rename, restore, swap, and purge operations; there is no override
The repository’s destructive test coverage uses isolated local containers with synthetic data. Production hosts and addresses are denied test targets.

​
Honest limits

DBHost is a strong fit for:
  • small SaaS apps
  • internal tools
  • staging environments
  • agencies managing several app databases
DBHost does not offer:
  • point-in-time recovery (PITR)
  • high availability, failover or read replicas
  • a service level agreement (SLA)
  • multi-region hosting
  • restore of uploaded dumps; you import them yourself with psql or pg_restore
  • cloning of databases that have additional roles
  • extensions other than citext, pg_trgm and pgcrypto
  • a compliance certification
See Limits for plan and per-database limits. That matters because security claims are only useful when they match the actual product surface.

​
Next steps