Give your coding agents prod-like data.
A masked copy of your database for every agent, PR and developer. Ready in seconds, on the infrastructure you already run.
# the CLI returns the clone's connection string $ export DATABASE_URL=$(baseshift server-clone start --dub my-app-pg) $ python manage.py migrate $ pytest --reuse-db ======== 1204 passed in 41.2s ========
Trusted by world class organizations
The bugs agents can’t see coming
It reads well and passes on fixtures. It breaks on production data, usually after the merge.
Surprise N+1 queries
Agents reach for the obvious ORM call. A serializer that walks a reverse FK passes review, then fires a query per row once the table has real cardinality.
Migrations that fail on deploy
unique=True or null=False applies cleanly to a dev database. Against years of duplicates and gaps it raises IntegrityError, and the deploy stops mid-migrate.
Assumptions real rows break
The agent reasons from models.py. Production has NULLs in fields that were never meant to be empty, retired choice values and JSON that predates the current shape.
Prod-like data everywhere Django code gets written.
A clone per agent, per worktree.
Through MCP or the CLI, every coding agent spins up its own writable clone. It can query prod-like data, run migrate and poke around in manage.py shell, with no path to production and nothing shared with other agents.
- Run five agents in parallel, five isolated databases
- Works with any coding agent
- Every query audited, clones thrown away when done
A clone per PR
Every PR gets its own clone, so migrations and tests run on real volume. Stop it when the job ends; idle clones are cleaned up automatically.
# .github/workflows/test.yml
- run: |
baseshift auth login --method=direct
export DATABASE_URL=$(
baseshift server-clone start \
--dub my-app-pg)
python manage.py migrate
pytest --reuse-db
- if: always()
run: baseshift server-clone stopProd-like on every laptop
Snapshots ship as Docker images. runserver shows prod-like data in seconds. No more stale dumps passed around on Slack.
# docker-compose.yml
services:
db:
image: my-app-pg:latest
web:
command: python manage.py runserver"Fails for this one customer"
Clone the latest masked snapshot, reproduce the bug in the shell, fix it and test it. Nobody touches production.
$ export DATABASE_URL=$( baseshift server-clone start \ --dub my-app-pg) $ python manage.py shell >>> Invoice.objects.get(pk=88213).total() TypeError: unsupported operand type(s) for -: 'decimal.Decimal' and 'NoneType' # legacy row: discount is NULL
No infrastructure changes. No code changes. Just a connection string.
Snapshot once, masked
Read-only access to prod, a replica or staging. PII is masked before any snapshot exists.
Clone per agent, PR or developer
Copy-on-write clones in under 2 seconds. Hundreds run in parallel on shared compute.
Use it, break it, throw it away
Writes stay in the clone. Nothing reaches production or other clones.
import dj_database_url DATABASES = { "default": dj_database_url.config( env="DATABASE_URL" ) }
Real shapes. No real people. Safe to put in an agent's context.
Mask auth_user, profiles and anything else with PII, with the same rules across every database. Keep foreign keys, NULLs, skew and the giant rows that break things.
- Subset to one tenant, a few tables, or the last 90 days
- Runs in your own Kubernetes and VPC
- Audit trail of every SQL query against a clone
Masked consistently, so joins and lookups still line up.
Want Git-style branches for your local database, but don't need the data?
brancher snapshots your test database once and gives each parallel worker, agent and worktree its own local branch, so migrations don't rerun every time. Built on Baseshift core.
$ pip install django-baseshift-brancher $ pytest -n 8
Trusted by developers
Before Baseshift, the cost of running multiple environments was a non-starter. Now it’s just part of our workflow - powering demo and CI/CD environments at scale.
Baseshift opened up ways to test our code at scale, with real data; drastically changing the way we fix bugs and build new features.
Baseshift makes it safe for our AI agents to run real workflows on production-like data, removing the barriers to fast agentic development
Before Baseshift, the cost of running multiple environments was a non-starter. Now it’s just part of our workflow - powering demo and CI/CD environments at scale.
Baseshift opened up ways to test our code at scale, with real data; drastically changing the way we fix bugs and build new features.
Baseshift makes it safe for our AI agents to run real workflows on production-like data, removing the barriers to fast agentic development
Before Baseshift, the cost of running multiple environments was a non-starter. Now it’s just part of our workflow - powering demo and CI/CD environments at scale.
Baseshift opened up ways to test our code at scale, with real data; drastically changing the way we fix bugs and build new features.
Baseshift makes it safe for our AI agents to run real workflows on production-like data, removing the barriers to fast agentic development
Before Baseshift, the cost of running multiple environments was a non-starter. Now it’s just part of our workflow - powering demo and CI/CD environments at scale.
Baseshift opened up ways to test our code at scale, with real data; drastically changing the way we fix bugs and build new features.
Baseshift makes it safe for our AI agents to run real workflows on production-like data, removing the barriers to fast agentic development
Before Baseshift, the cost of running multiple environments was a non-starter. Now it’s just part of our workflow - powering demo and CI/CD environments at scale.
Baseshift opened up ways to test our code at scale, with real data; drastically changing the way we fix bugs and build new features.
Baseshift makes it safe for our AI agents to run real workflows on production-like data, removing the barriers to fast agentic development
Before Baseshift, the cost of running multiple environments was a non-starter. Now it’s just part of our workflow - powering demo and CI/CD environments at scale.
FAQs
Yes. The data is masked before any snapshot exists, each clone is isolated, and there is no path from a clone back to production.
Any of them. Claude Code, Cursor, Codex, Copilot or your own: if it can run a command or call an MCP tool, it can get its own clone.
Yes. By default Django creates an empty test database, so point it at the clone instead: set DATABASES["default"]["TEST"]["NAME"] to the clone's database and run with --keepdb (or --reuse-db with pytest-django). Your tests then run on prod-like data, and every test run can get its own clone, so nothing it changes affects anyone else.
No, if your DATABASES already reads a connection URL from the environment. A clone is just another Postgres or MySQL endpoint. To run your tests on the clone too, add one line for the test database name.
Yes, inside your own Kubernetes cluster and VPC.
brancher is a free tool for Git-style branching of the database you already have: snapshot it once, give every test run, agent or worktree its own branch, and keep each branch's state. It doesn't bring any data. Baseshift does: masked, prod-like data from your real databases for every agent, PR, developer and debugging session.
One copy of prod for every agent, PR, laptop and bug.
Free up to 150 GB snapshotted per month. Pro from $30/month.