A fresh database, up-to-date, for every PR
Test migrations on real masked data before they bite. Source from production, a read replica, or staging.
Trusted by world class organizations
From your pipeline to a prod-like database in three steps
Connect your source once
Production, a read replica, or staging: a connection string is all Baseshift needs. Masking happens during the copy, so CI never sees a real customer record.
Add one step to your pipeline
No plugin to install and no vendor lock on your CI provider. It is a CLI: pip install, auth login, clone start. Works in GitHub Actions, GitLab CI, Jenkins, or anything else that runs a shell.
Every PR gets its own database
Migrations and tests run against a writable, prod-like clone that nobody else is touching. Stop it in after_script and it is gone.
Your migrations pass on staging because staging is not production
Real distributions, real NULLs, real tenant skew. That is what your schema change meets in production, so meet it in CI first.
Migrations tested on real data
A stale, thinly populated staging database approves almost any migration. A clone with production distributions catches the NULL that violates your new constraint, the lock that times out, and the backfill that takes an hour.
Isolated per PR
Every pipeline gets its own writable clone. No shared staging queue, no test pollution from the branch next door, no waiting for someone else's job to finish.
Cheap enough for every commit
Clones are copy-on-write. A pipeline does not pay for a full database copy, so running one per PR is an engineering decision, not a budget decision.
Real clones. Not seed data on a fresh port.
PostgreSQL, MySQL, MongoDB, or DocumentDB, provisioned by your pipeline and destroyed by it.
The engines you already run. Your migration tool, ORM, and clients behave exactly as they do in production.
Seconds per clone. Fast enough to sit inside the pipeline instead of before it.
Spin up as many clones as the pipeline demands. Built to keep pace with your team and your agents.
Abandoned clones are torn down automatically, so a crashed runner never leaks an environment.
Anonymization happens during the copy from your database. CI logs, test output, and artifacts never contain a real customer value.
Baseshift copies from your source with a read-only role. Your pipeline never holds credentials that can write to production.
Start free. Stay free until it's useful.
The free tier includes 150 clone credits every month, enough to put a real database under your test suite and find out what it catches. Pro from $30/month when you need more.
Get started for freeSee pricing →FAQ
Can I host Baseshift on prem/BYOC?
Yes, and the data never leaves your network.
How fast does a clone start?
6 to 8 seconds in SaaS today. On-prem deployments typically come in under 2 seconds.
Does every pipeline copy the whole database?
No. Clones are copy-on-write against a shared snapshot. Starting a clone does not copy your data, and ten concurrent clones do not cost ten databases.
What happens when the PR closes?
The recommended pattern is baseshift clone stop in your after_script, which destroys the clone the moment the job ends. If a runner dies mid-job, abandoned clones are torn down automatically.
How do I integrate it with GitHub Actions or GitLab CI?
It is a CLI, so it drops into any runner: pip install baseshift, baseshift auth login, baseshift clone start. There is no plugin to adopt and nothing specific to one CI vendor.
Can my tests write to the clone?
Yes. Clones take real writes: DDL, migrations, deletes, whatever the test suite does. Each clone is isolated, so nothing leaks between pipelines.
Is production data exposed to CI?
No. Masking happens while data is copied from your source, before any clone exists. What CI touches was anonymized from the start.
What permissions does Baseshift need on my database?
A read-only role on your source. Baseshift never needs write access to production.