Documentation

One primitive: the database cellCopy Anchor Link

Every project runs in its own database cell - an isolated Postgres runtime with a dedicated process, storage, credentials, network boundary, and CPU/RAM limits. Not a schema on a shared server. The API manages the cell lifecycle; you use normal Postgres URLs. How the cell works →

What you actually getCopy Anchor Link

• Standard postgres:// connections for direct and pooled access, with Postgres 16, 17, or 18 selected per database (17 by default)
• One isolated database cell per project, grouped under organizations
• Disposable preview databases with empty or clone modes and TTL cleanup
• Ephemeral databases: a throwaway Postgres with no account, destroyed after 72 hours unless you claim it into a project
• On-demand and scheduled backups, point-in-time restores, and pinned restore points
• Imports from any reachable Postgres, with a preflight that tells you up front whether the import will work
• 28 allowlisted Postgres extensions - pgvector and PostGIS included - manageable per database from the dashboard, API, and CLI
• Usage threshold alerts on storage and connections, delivered to the dashboard, webhooks, and email
• Deployment integrations for Vercel and Netlify, user sync from Clerk, Auth0, or Better Auth into your own database, and a GitHub Action for preview databases per PR
• Outbound webhooks, org and project-scoped API keys, an audit log, Studio (SQL runner and table browser), and live metrics
• A CLI, a TypeScript SDK, a Terraform provider, and an OpenAPI-documented HTTP API

Built for agents tooCopy Anchor Link

A coding agent can set a project up without anyone opening the dashboard, and the guardrails are the same ones people get.

• Set up with an AI assistant: one prompt sends the agent to a hosted runbook; you approve access once in a browser tab
• The MCP server: tools calling the same API the dashboard calls - remote at mcp.capydb.dev for Claude with a browser sign-in, or local over stdio for Claude Code, Cursor, or any MCP client
• Browser tools: the dashboard registers tools for an agent in a WebMCP-capable browser, on the session you are already signed in with
• The agent safety loop: an UPDATE or DELETE with no WHERE is refused before it runs, a failed change restores into a preview, and overwriting production is not an agent tool on any surface
• Ephemeral databases: a real cell with no account, so an agent that is only exploring never has to stop and ask you to sign up

Why the surface stays smallCopy Anchor Link

CapyDB is intentionally boring in the best way. You get Postgres plus the few workflows that keep shipping teams out of trouble.

The goal is to let you keep your existing stack and swap infrastructure, not force a new way of writing apps. Everything in these docs works against plain Postgres connections and a plain HTTP API.

How operations runCopy Anchor Link

Lifecycle actions - provisioning, backups, restores, imports, preview create/reset/delete, credential rotation - are asynchronous jobs. The API answers 202 Accepted with a job object you can poll until it reaches completed or failed. The dashboard, CLI (--wait), SDK, and GitHub Action all wrap this for you.

Current deployment modelCopy Anchor Link

The current v1 layout runs customer Postgres on dedicated-vCPU servers in the EU, and the control plane, worker, and metadata database on a separate EU server. Human authentication is handled by Clerk; programmatic access uses API keys. Plans (Vibe, Ship, Business) are billed per organization through Polar.