Production-like Postgres branches in seconds for coding agents, tests, CI and migrations.
Connect production once. Agents, CI and pull requests branch from it on demand.
Twenty agents on one staging database means colliding migrations, tests that step on each other and state nobody can trust. Give every agent its own Postgres instead.
Every agent writes into the same database.
Claude Code ─┐ Codex ─┼→ staging GitHub Actions ─┘
Every agent gets a branch of its own.
Connect production once. pgrun creates isolated, disposable branches for agents, CI and pull requests.
Each agent, PR or CI job triggers the same loop — automatically.
Connect your existing Postgres — production stays put.
Spin up an isolated Postgres branch in seconds.
Get a normal DATABASE_URL. No custom API.
Delete it when the job's done. No cleanup.
CLI, API, and structured output for agents.
Every branch hands back an ordinary connection string. Nothing in your app has to know.
Your app reads the same variable it always has — the branch is just another Postgres.
DATABASE_URL=postgresql://agent:x8Kq2vLm@br-7f3a9c.us.db.pgrun.dev:5432/postgres?sslmode=require
Frameworks and clients connect as they always have; agents and CI create the branches.
ClientsAgents need a real database to try things on. It shouldn't be shared staging, a dump on someone's laptop, or a reason to move your production somewhere new.
Connect RDS, Aurora, Cloud SQL, Supabase, Neon or your own server. Nothing to migrate, and no new host to trust with production.
instead ofmoving to a new Postgres host
pgrun reads production once to build a Safe Copy, masking sensitive columns under a policy a person approves. Agents only ever see the copy.
instead ofpg_dump onto laptops
Branches are copy-on-write clones of the Safe Copy, ready in about 3 seconds whatever the size of your data.
instead ofrestoring a dump for every run
Every agent, pull request and CI job gets its own isolated Postgres in parallel. Nobody waits, and no one's migration lands on anyone else.
instead ofqueueing on shared staging
A CLI with JSON output and real exit codes, an MCP server, a Claude Code skill and an HTTP API. Approvals stay with people.
instead ofa dashboard someone has to click
Every branch can carry a TTL, --delete-after cleans up even when the job fails, and compute is billed by the second only while a branch runs.
instead ofcleanup scripts and forgotten databases
Engineers, platform teams and CI pipelines that stopped sharing one staging database and gave every agent its own.
"Three agents, three databases, zero collisions. That was the entire problem, solved in an afternoon."
"Our CI used to queue on a single staging database. Now every job branches, runs, and deletes its own."
"First time I've let an agent run migrations without watching the terminal the whole way through."
"It's a DATABASE_URL. Nothing in our Rails app noticed anything had changed."
"Branch in a few seconds, drop it when the PR merges. Cleanup stopped being a job someone owns."
"We stopped copying production dumps onto laptops. That alone paid for it."
"My agent opens a branch, breaks it in four ways, and production never hears about it."
"Masking meant we could finally hand contractors data shaped like the real thing."
"Onboarding is one command now. The new hire had a database before their coffee landed."
"Twenty parallel test runs, twenty databases. The flaky ones turned out to be shared state all along."
"Postgres, not a Postgres-shaped thing. psql, pg_dump and our extensions all just worked."
"The agents create more databases in a day than we used to create in a year. Nobody files a ticket."
No credit card required. Create real Postgres branches, connect your agents, and test the workflow before paying.
Start free with $10 credits · Keep production where it is. Or create branches directly through the API.