Clone production in two minutes
Stand up a clean staging environment from your live data, ready to break safely.
You launched. Users showed up. And somewhere between your last commit and your first 1am bug, you noticed your dev database and your production database had been the same database all along. Stack2X spins up a clean staging clone in a couple of minutes, keeps it fresh from prod when you want, and lets the next fix land on a copy, not on your users.
Built for the post-launch founder
Each tile opens up. Click into any of them for a closer look at how it works, what's covered, and what it does not touch.
Stand up a clean staging environment from your live data, ready to break safely.
Schedule a refresh from prod whenever your local data starts to drift.
Verifiable snapshots, retained on your terms, restored in one click.
Full project migration across hosts or regions, without rewriting your app.
TLS in transit, Vault at rest, source data never modified.
Why founders pick Stack2X
We did not set out to build a migration tool. We kept getting the same call from founders the night before a launch, so we wrote it down.
What used to take a senior developer two days of careful manual SQL, scripts, and triple-checking, Stack2X handles in under fifteen minutes. Nineteen Supabase components migrated automatically. You do not babysit a terminal.
Migrations are additive only. Stack2X reads from your source database and writes to your destination. The original is never altered, deleted, or locked. If anything looks wrong, you cancel and the source is exactly where you left it.
Sign in, pick what to move, hit Migrate. The interface is built for the founder who shipped the product, not the database administrator you do not have. If you can connect a Stripe account, you can run a Stack2X migration.
Auth users migrate with their password hashes intact, exactly as Supabase stored them. No forced resets, no broken sessions, no support tickets. People sign in tomorrow with the same credentials they used yesterday.
Every connection runs TLS 1.3. Credentials live in Supabase Vault with pgsodium encryption and never appear in logs or in plaintext. Built by a European cybersecurity company that has been doing this for fifteen years.
Owner, admin, member, and viewer roles, with invitations and an audit log on every migration. Bring your CTO, your contractor, and the friend who knows Postgres. Everyone sees what they need to see and nothing they should not.
Three steps. No terminal.
Most users finish before their coffee cools. The interface stays out of your way; Stack2X does the work below the surface.
Sign in with Supabase OAuth or paste a connection string. The keys never leave your project; we write them to Vault and forget the plaintext.
Choose components — schema, users, storage, functions, config — or take the whole thing. Sensible defaults; nothing surprising.
Real-time progress per component. If anything fails, you get a real error, not a spinner. Source stays untouched throughout.
Everything we move
Stack2X migrates the whole project, not just the database. Here is the full list, so you can see exactly what is in scope before a single byte moves.
5 components
Schema, row data, Row Level Security policies, materialised views, and Postgres extensions. Stack2X reads via Supabase's managed connection and writes via the destination's standard interfaces. No raw pg_dump archives left on disk.
4 components
Auth users with bcrypt-compatible password hashes, identities (Google, GitHub, email), Auth configuration including email templates, and the JWT signing secret if you want to migrate active sessions.
3 components
Storage buckets, every object inside them, and bucket-level configuration: public/private flag, file size limits, MIME allowlists. Streamed in chunks so a 200 GB bucket does not blow up your laptop.
2 components
Edge functions and the secrets they read at runtime. Functions move with their imports; environment variables move encrypted into the destination's secrets store, never written in plaintext.
5 components
PostgREST settings, Realtime channel config, network restrictions, custom SSL certificates, and custom domain bindings. The unsexy stuff that breaks the app if you forget it.
Built secure by default
Stack2X handles your production database. Here is what is true on every migration we run, whether you are on the free tier or the Pro plan.
Every byte that crosses a network is encrypted with TLS 1.3 and certificate-pinned to the Supabase API and database endpoints. Plaintext never crosses the wire, not even on internal hops.
Source and destination credentials are stored in Supabase Vault using pgsodium symmetric encryption. They are decrypted only inside the migration worker for the duration of one job, then dropped from memory.
Stack2X opens read-only connections against your source. The runner cannot delete, mutate, or lock your production database, even if asked. Migrations are reversible by definition: the source is exactly what it was before you started.
Built by Wise Cloud SAS, a French cybersecurity company. Default migration workers run in EU regions. Data residency, DPA, and processing agreements available on request to anyone on the Pro plan.
Pricing
Skip the tier comparison spreadsheet. The Pro plan includes every Stack2X feature with no usage caps. Free plan still covers occasional moves.
Common questions
If your question isn't here, drop us a line — we read everything and reply same-day on weekdays.
No. Stack2X reads your production database; it never writes back to source. Connections are pooled and rate-limited so the work does not show up as load on your live app. Your users keep using the product like nothing happened, because nothing did.
As fresh as you want. Run a refresh manually from the dashboard whenever you need new data, or schedule recurring refreshes: nightly, weekdays only, weekly before sprint review, your call. Each refresh syncs the latest production state without touching prod.
Yes, in either direction. Cloud to self-hosted, self-hosted to Cloud, or between two Cloud projects across regions. The migration runner does not care where source or destination lives, only that it can authenticate to both. Same flow, same components, same security.
Zero on the source. Stack2X reads from production while it is serving traffic. The destination is built up alongside it, then you cut over by switching your app's connection string. Most teams cut over in under thirty seconds.
The migration is non-destructive on both ends: source is read-only, destination is built additively. If the runner crashes, the destination is partially populated and the source is untouched. You retry from the dashboard and pick up from the last completed component.
Yes. Re-running an already-completed migration refreshes the destination from the latest source state. Re-running a failed migration resumes from the failed component. We track per-component checksums so we do not re-copy what is already there.
Today the clone contains the same data as prod, so treat it with the same care. PII obfuscation, automatic redaction or hashing of sensitive columns at refresh time, is on the roadmap and ships in beta this quarter. If you need it sooner, let us know which columns and we'll prioritise.
Free tier covers a handful of clones per month, which is enough for most early-stage teams. The Pro plan is €49/month for unlimited clones, scheduled refreshes, daily backups, and team seats. If you only need a single migration, one-time passes start at €15. No per-row, per-byte, or per-user fees.