AlgorithmShift

Foundation

Environments
one pipeline, many targets.

Each environment — dev, staging, prod — gets its own database, its own credentials, and its own migration mode. The agents and the delivery graph stay the same; only the target changes.
Dev / staging / prodPer-env migration modeCross-env status
Book a demoStart free
acme / ops-tools / environments

Environments

devmanaged
stagingexport_only
prodexport_only

The problem

Dev teams want automation. Ops teams want their existing CI. Both can be right — on the same app, at the same time. AlgorithmShift treats each environment as a separate target with its own migration mode, so platform behaviour matches the trust level of each database.
[01]

Three migration modes, one per environment.

Pick the mode that matches your trust contract with each target. Dev can be fully automated while prod stays locked down behind the pipeline it had last year.
  • managed — platform applies + tracks. Default for dev.
  • export_only — platform generates SQL bundles; your CI applies. Default for staging/prod.
  • reconcile_only — platform reads your existing ledger. Writes nothing.
managed

Platform applies and records. Default for dev.

allows: writes

export_only

SQL bundle out. Your CI in. Default for prod.

allows: reads · writes to customer DB: never

reconcile_only

Read your existing ledger. Platform never writes.

allows: reads only

[02]

One database per environment.

Each environment points at its own workspace database with its own credentials. Rotating prod creds doesn't touch dev. Pointing dev at a new provider doesn't ripple through prod.
  • Credentials live on the environment, not the app
  • Connections routed through the platform's secrets layer
  • Per-env schema override on shared-DB setups
acme / env vars
Variabledevstagingprod
DB_HOSTdev-rds…staging-rds…prod-rds…
DB_NAMEops_devops_stagingops_prod
API_KEY•••••••••••••••
[03]

Cross-environment status in one view.

See every migration's state across every environment in one matrix. Drift detection, pending lists, and release-scoped apply progress — all answerable with one query.
  • "Applied in dev, pending in prod" — single matrix cell
  • Drift alerts when a file changed after apply
  • Exportable audit trail for compliance
acme / ops-tools / migrations
Migrationdevstagingprod
20260418_001_usersappliedappliedapplied
20260420_001_ticketsappliedappliedpending
20260422_001_deletion_logappliedappliedpending
20260424_001_add_trashappliedpending—
20260424_002_audit_idxdrifted——
[04]

Release-aware promotion.

A release bundles its migrations along with its code + stories. Promoting the release to the next environment promotes its migration bundle too — no cherry-picking from a wiki.
  • Release detail surfaces the exact SQL bundle
  • Promote button previews the bundle before export
  • Rollback reverse-applies the same bundle
acme / releases / v2.4.0

v2.4.0 — Admin Tools Pack

4 migrations · 6 pages · 2 integrations

dev

4 / 4 applied

staging

2 / 4 applied

prod

0 / 4 applied

[05]

Safe-by-default on staging + prod.

New environments named staging or prod are created in export_only mode. The platform literally cannot write to them unless an admin flips the mode — a single-click decision with a visible audit trail.
  • Auto-detection by environment name
  • Mode changes logged in the audit trail
  • Per-env access control for the mode switcher

Detected “prod”.

Migration mode set to export_only.

Platform will never write to this database. Export SQL and apply it via your existing pipeline, or flip to managed if you want automation.
Mode changes recorded in audit log

3

Migration modes

per environment

4+

Ledgers reconciled

Flyway, Liquibase, Rails, ours

Hash

Drift detection

content SHA at apply time

∞

Envs per app

dev / staging / prod / …

FAQ

Common questions

What if we use a custom migration runner?
Use export_only mode — we generate the SQL bundle, your runner applies. Or use reconcile_only if your runner writes its own ledger in a known shape (Flyway, Liquibase, Rails, Django, Phoenix, or our own _migrations format).
Can we mix modes across environments for one app?
Yes — that's the common case. Dev on managed, staging on export_only, prod on export_only or reconcile_only. Same app, three modes.
What happens when a file changes after apply?
Drift detection flags it. The apply ledger stores the content SHA at apply time; the next read compares to the current file hash. Drift is surfaced as a warning on the migrations panel and in the audit log.
Can we connect a non-Postgres database?
Postgres (and Postgres-compatible: AWS RDS, Neon, Supabase, Vercel Postgres, Render, Railway) is what we support today. Mysql is on the roadmap for Enterprise.

See the full platform in action.

Bring a real requirement. Watch it become a running app you can ship.

Start freeBook a demo