Legal · Security policy

How we protect your data

DBHost is a managed PostgreSQL service. This page is a plain-English summary of the controls that protect your databases, credentials, and customer data. It complements the public security overview and the technical security documentation.

Last updated: May 2026

Authentication and access

Every layer of DBHost has its own authentication mechanism, and they do not share secrets across boundaries:

  • Dashboard sign-in is handled by Clerk, a specialized identity provider, so DBHost never stores user passwords.
  • API access uses scoped API keys with a Bearer header. Keys can be limited to specific databases so automation stays narrow by default.
  • Database connections use per-database credentials issued through PgBouncer, keeping each tenant isolated from the next.

Credential management

  • Database passwords are generated with cryptographically strong randomness (256 bits of entropy).
  • Stored database passwords are encrypted at rest with AES-256-GCM before they are persisted in the control plane.
  • API keys are hashed with SHA-256 before storage. Only a short prefix is kept in plaintext so you can identify a key in your dashboard.
  • Internal service credentials (agent secrets, S3 backup credentials, the PostgreSQL superuser password) are kept on the servers that need them and never exposed to the dashboard or API.

Abuse, rate limiting, and request shaping

Public endpoints have request-body size limits and per-route rate budgets. Authenticated and unauthenticated traffic are limited independently, and sensitive routes — query execution, backup operations, registry sync — each have their own budget.

Repeated authentication failures and obvious abuse patterns are fed into host-level intrusion-prevention rules so misbehaving clients are throttled at the network edge, not at the database.

SQL injection and query guardrails

  • All control-plane database access goes through a type-safe ORM that emits parameterized queries. There is no raw SQL string interpolation in the control plane.
  • The data-plane agent constructs DDL through identifier and literal helpers that escape and quote values safely.
  • The in-dashboard SQL Explorer is owner-only and runs through a dedicated read-only PostgreSQL role. Data-modifying statements, utility statements, and system-schema access are blocked before they reach PostgreSQL.
Note: these guardrails apply only to the in-dashboard explorer. Direct PostgreSQL connections still use your own database credentials and PostgreSQL privileges, exactly like any other Postgres host.

Input validation and isolation

  • Database names submitted through the public API must match a strict pattern before they are used anywhere — file paths, subprocess arguments, or PostgreSQL identifiers.
  • Backup and restore operations invoke subprocesses with explicit argument lists, never shell strings, so command injection is not possible.
  • Filesystem paths used for backups are resolved and validated against a fixed base directory to prevent path traversal.
  • The agent service runs as an unprivileged system user with a restrictive umask and a private temporary directory.

Network boundaries

  • PostgreSQL listens only on localhost. The only public database port is PgBouncer.
  • The internal agent listens only on localhost behind a reverse proxy that handles TLS termination via Let’s Encrypt.
  • All traffic between the dashboard and the database host is over HTTPS.
  • You can attach a per-database IP allowlist from the dashboard to restrict which networks can reach your PgBouncer endpoint.

Tenant boundaries

Customer-facing operations only act on databases that are registered in the managed-database registry. Internal databases used by DBHost itself are explicitly excluded from that surface, so there is no shared path between customer requests and control-plane internals.

Backups

  • Daily automated backups are written off-host to encrypted S3 storage and retained for 30 days.
  • Temporary backup directories on the database host use restrictive permissions (0700 for directories, 0600 for files) and are removed after the backup completes.
  • You can trigger an on-demand backup at any time from the dashboard or the API.

What we recommend

  • Use the per-database IP allowlist for production workloads.
  • Use scoped API keys instead of broad ones, and rotate them periodically.
  • Watch the Activity tab in your dashboard for unexpected access patterns.
  • Take a manual backup before risky migrations, in addition to the automatic daily snapshot.

Honest scope

DBHost runs in a single region on a single VPS today. It is built for small teams that want sane defaults — pooling, daily backups, scoped access — without operating their own database platform. We do not yet offer multi-region replication, automatic failover, or compliance certifications, and we say so plainly.

If your workload requires those guarantees, we’d rather tell you now than oversell.

Reporting a security issue

If you believe you have found a vulnerability, please reach out privately. We’ll triage promptly and credit responsible disclosures.

Contact the team →