Skip to content
stack
Get started
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 by setting up the destination first, then attempting aliases and local cleanup of the source. It does not delete the old upstream resource or provide an atomic whole-swap guarantee. Inspect partial failures and remaining configuration or secrets.

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:

  1. Stack checks that from is configured in .stack.toml.
  2. Stack runs provider setup for to; authentication and resource operations depend on that adapter and its configured credentials.
  3. Unless --keep-from is set, Stack attempts Phantom secret cleanup and removes the local from service/MCP entry. The old upstream resource is kept; secrets can remain when terminal confirmation is unavailable or refused.
  4. Local configuration updates can be partial. A source-cleanup failure does not revert the destination setup; review warnings and finish cleanup manually.

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 attempts to mirror DATABASE_URL into SUPABASE_URL in Phantom. Stored-value access or a write can be refused, so an alias is not guaranteed; inspect warnings and configure the required value yourself through Phantom's trusted-terminal flow.

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 Accepted by this source, but not used or forwarded by the swap implementation. It does not disable the destination add workflow's failure cleanup.

Rollback on failure

If destination setup fails after creating a resource, the add workflow attempts cleanup, including upstream teardown only when the provider supports it. Vault removal and teardown can fail or leave secrets stored; inspect the reported partial failure. Source removal begins only after destination setup succeeds, and later cleanup failure does not undo that success. See Transactional rollback for the full failure-handling model.

Inspect available options

# Inspect the options supported by your installed CLI
stack swap --help