CLI

Provider swap

Migrate a project from one provider to an equivalent in the same category — auth, database, email, analytics, and more — in a single command.

What it does

stack swap <from> <to> replaces one provider with another in the same category. It runs the full deprovision → provision sequence atomically: if any step fails, Stack rolls back and your project is left in its original state.

38 preset pairs are built in across six categories:

Category	Supported pairs (bidirectional)
Auth	clerk ↔ auth0, clerk ↔ workos, auth0 ↔ workos
Database	supabase ↔ neon, supabase ↔ turso, neon ↔ turso
Email	resend ↔ sendgrid, resend ↔ mailgun, resend ↔ postmark, sendgrid ↔ mailgun, sendgrid ↔ postmark, mailgun ↔ postmark
Analytics	posthog ↔ mixpanel, posthog ↔ plausible, mixpanel ↔ plausible
Observability	datadog ↔ grafana
Deploy	vercel ↔ netlify, vercel ↔ cloudflare, netlify ↔ cloudflare

Basic usage

# Migrate from Clerk to Auth0
stack swap clerk auth0

# Preview the plan without executing
stack swap clerk auth0 --dry-run

What happens under the hood:

Stack checks that from is configured in .stack.toml.
Stack provisions to (OAuth, API calls, secrets into Phantom). The OAuth callback listens on http://127.0.0.1:8787/callback — register that URI in your provider app for a clean single redirect URI.
Stack removes the from service — deprovisioning upstream resources and deleting its Phantom secrets.
.stack.toml and .mcp.json are rewritten.

Env-key aliases

Some pairs use different env variable names for the same concept. For example, Supabase writes SUPABASE_URL while Neon writes DATABASE_URL. After a supabase → neon swap, Stack automatically aliases DATABASE_URL back to SUPABASE_URL in Phantom so existing code references keep working without a source change.

Aliases are a compatibility shim, not a permanent solution. Update your code to reference the new provider's canonical key when you have a moment.

Flags

Flag	Behaviour
`--dry-run`	Print every step that would run without making any upstream API calls or writing any files.
`--keep-from`	Provision `to` without removing `from`. Useful for a side-by-side migration where you want to validate the new provider before cutting over.
`--no-rollback`	On failure, leave partial state in place instead of rolling back. Use only when debugging a broken provisioner — the default rollback is almost always what you want.

Rollback on failure

If provisioning to fails partway through, Stack calls deprovision on the partially-created upstream resource and removes any Phantom secrets that were written. Your original from service is left intact. See Transactional rollback for the full failure-handling model.

Discover available swaps

# See which providers your current project can swap to
stack swap --suggest

# Or list all 38 built-in pairs
stack swap --list