Every pull request gets its own production-like database.
Masked, subsetted clones of PostgreSQL, MySQL and MongoDB for every PR, preview environment and test run.
Ready in seconds, cleaned up automatically, and no change to your infrastructure.
$ baseshift server-clone start --dub my-app $ npm run migrate && npm test $ baseshift server-clone stopGitHub Actions, GitLab CI and Jenkins examples →
Trusted by world class organizations
Your tests pass on staging because staging isn't production.
Testing every PR against production-like data is the obvious answer. Copying production for every PR is the reason nobody does it.
Full restores take tens of minutes
Restoring a dump per environment doesn't fit a team opening PRs all day, so it gets skipped.
One staging DB, many pipelines
Parallel runs overwrite each other's data, migrations collide, and teams queue for the environment.
Fixtures miss real data shapes
Seed data hides the NULLs, skew and oversized rows behind constraint violations, lock timeouts and slow backfills in production.
Real data means real PII
Copying production into CI runners, logs and preview URLs is a compliance problem waiting to happen.
A fresh clone per PR, from a masked snapshot of your data.
Snapshot your source, masked
Connect production, a read replica or staging with a read-only role. Use full copy to snapshot on a schedule or on demand, or logical replication to stream changes continuously and mask them as they arrive.
Clone when the PR opens
One CLI step in any pipeline. Spin up any number of clones from the same snapshot. They're copy-on-write, so each is ready in seconds whether the database is 1 GB or 1 TB.
Run migrations against real shapes
Your app connects over the native protocol. Write, run DDL, delete rows: nothing touches production, the snapshot or any other PR.
Clean up automatically
Clones stop when the PR merges or closes. If a pipeline dies halfway, abandoned clones are removed on their own.
One step in the pipeline you already have.
Baseshift is a CLI, not a plugin. Log in with a system user, start a clone before your tests and stop it in your cleanup step.
env:
BASESHIFT_USER_EMAIL: ${{ secrets.BASESHIFT_USER_EMAIL }}
BASESHIFT_USER_PASSWORD: ${{ secrets.BASESHIFT_USER_PASSWORD }}
steps:
- run: pipx install baseshift
- run: |
baseshift auth login --method=direct \
--email "$BASESHIFT_USER_EMAIL" \
--password "$BASESHIFT_USER_PASSWORD"
- run: baseshift server-clone start --dub my-app
- run: npm run migrate && npm test
- if: always()
run: baseshift server-clone stop# BASESHIFT_USER_EMAIL and BASESHIFT_USER_PASSWORD
# set as CI/CD variables
test:
before_script:
- pipx install baseshift
- >
baseshift auth login --method=direct
--email "$BASESHIFT_USER_EMAIL"
--password "$BASESHIFT_USER_PASSWORD"
- baseshift server-clone start --dub my-app
script:
- npm run migrate && npm test
after_script:
- baseshift server-clone stopenvironment {
BASESHIFT_USER = credentials('baseshift-system-user')
}
stages {
stage('Test') {
steps {
sh 'pipx install baseshift'
sh '''baseshift auth login --method=direct \
--email "$BASESHIFT_USER_USR" \
--password "$BASESHIFT_USER_PSW"'''
sh 'baseshift server-clone start --dub my-app'
sh 'npm run migrate && npm test'
}
}
}
post {
always { sh 'baseshift server-clone stop' }
}You don’t need to change databases to do this
Branching usually means moving production onto a new database that supports it. Baseshift gives you instant prod-like clones of the databases you already run, where they already run.
Keep the database you have
No migration and no new provider. Baseshift connects to your managed or self-managed databases with a read-only role.
Every database in the stack
PostgreSQL, MySQL, MariaDB, MongoDB and DocumentDB. One step clones all of a service's databases together.
Runs inside your infrastructure
Deploy into your own Kubernetes and VPC. Production data never leaves your network.
Snapshots ship as Docker images
Push a masked snapshot to your registry. CI runners in another account or region pull it and plug it into their cluster.
Masked before CI sees it
PII is masked at the source, consistently across databases, so a customer ID in Postgres still matches its document in MongoDB.
Subsetted to what tests need
Define subset policies to keep just the data your tests need, like one tenant, a few tables or the last 90 days.
Fast enough for every commit. Cheap enough for every PR.
Clones start in under 2 seconds and share storage and compute, so per-PR databases don't multiply your infrastructure bill.
| Shared staging | A database that branches | Baseshift | |
|---|---|---|---|
| Isolated per PR | No | Yes | Yes |
| Databases supported | Whatever you run | Usually one engine | Postgres, MySQL, MariaDB, MongoDB, DocumentDB |
| Requires changing your infrastructure | No | Yes, migrate or replicate prod to it | No |
| Runs in your VPC | Yes | Rarely | Yes, or hosted |
| Portable to other accounts | No | No | Yes, as Docker images |
| Built-in masking | DIY | DIY | Yes, consistent across databases |
| Subsetting | DIY | No | Yes |
Production stays out of your pipeline.
CI runners get realistic data, never real customers. Security and compliance teams get a trail they can audit.
Read-only on the source
Baseshift copies with a read-only role and never needs write access to production.
Masked at the source
Anonymization happens before a snapshot exists, so no clone ever holds raw PII.
Private by deployment
Run in your VPC and keep snapshots, clones and CI traffic on your own network.
Every query audited
See the actual SQL each pipeline sent, whatever ORM it came from.
The same clones work for coding agents.
Give each agent task its own clone over MCP. Agents run migrations and write data in parallel without touching production or each other. Review the result, or throw the clone away.
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
No. Built-in branching only helps if production already runs on a database that has it, usually one engine on one provider. Baseshift gives you the same per-PR workflow on the databases you already run, across engines, with masking and subsetting built in.
No. Point Baseshift at production, a read replica or staging with a read-only role. Snapshots are taken from there, either as full copies on a schedule or on demand, or continuously through logical replication.
A read-only role on the source. Baseshift never needs write access to production.
Yes. Deploy it in your own cloud or on-prem and your data never leaves your network. Hosted is available too.
Yes. Package the masked snapshot as a Docker image, push it to a registry the runners can reach, and start clones from it inside their own cluster.
Any of them: GitHub Actions, GitLab CI, Jenkins, CircleCI, Buildkite or a plain shell. Baseshift is a CLI: install it, log in, start a clone, and stop it in your cleanup step. No vendor-specific plugin.
Yes. Multi-database environments are snapshotted together with consistent masking, so cross-service tests line up.
Abandoned clones are torn down automatically, so nothing lingers and storage stays flat.
Give every agent and PR its own database
Free plan includes 150 GB snapshotted data a month. Pro from $30/month.