> ## 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.

# Security

> How DBHost handles scoped access, guarded SQL exploration, abuse controls, backups, and operational boundaries.

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](https://dbhost.app/security).

## 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](/api-reference/authentication) and [API keys](/dashboard/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.

<Note>
  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.
</Note>

## 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

* Read the [public security overview](https://dbhost.app/security)
* Review [API authentication](/api-reference/authentication)
* Explore [core concepts](/concepts)