Skip to content
stack
Get started
CLI

stack add

Provision a service, store its secrets in Phantom, and optionally install its SDK — with transactional rollback if anything goes wrong.

Basic usage

stack add supabase
stack add clerk
stack add resend

For the full flag reference, see the CLI reference. This page covers the three behaviours that aren't obvious from the synopsis: SDK auto-install, transactional rollback, and env export.

SDK auto-install

After provisioning and persisting a service's secrets, Stack checks whether the provider ships an SDK package (e.g. @supabase/supabase-js, @clerk/nextjs). If it does, Stack detects your project's package manager and prompts once: 

◇  Install @supabase/supabase-js? (detected: bun)
│  Yes / No / Never for this project

Detection order: bun.lock → pnpm-lock.yaml → yarn.lock → package-lock.json → package.json. Falls back to npm if none are found.

Override the prompt with the --install flag:

# Always install without asking
stack add supabase --install=always

# Never install (useful in CI or monorepos where you manage deps separately)
stack add supabase --install=never

# Default: prompt once (same as omitting the flag)
stack add supabase --install=ask

Transactional rollback

stack add runs a multi-step pipeline: OAuth/API auth → upstream resource creation → secret storage in Phantom → config write → MCP wire. If any step fails after an upstream resource was already created, Stack automatically calls deprovision on that resource and removes any Phantom secrets that were written in the same run. 

┌  stack add neon
│
◆  Provisioning neon...
│  ✓ Created project "my-app" (ep-quiet-frost-a1b2c3d4)
│  ✗ Failed to write DATABASE_URL to Phantom: vault locked
│
◆  Rolling back...
│  ✓ Deleted neon project ep-quiet-frost-a1b2c3d4
│
└  ✗ neon was not added. Phantom vault must be unlocked.

Rollback is implemented for Supabase, Neon, Turso, and Vercel. For providers that don't implement deprovision, Stack surfaces both the original error and a warning that the upstream resource may still exist — so you know to clean it up manually.

Pass --no-rollback only when debugging a broken provisioner. The default rollback is almost always what you want — partial state is worse than a clean failure.

The same rollback model applies to stack swap. See Provider swap for details.

Generating .env.example

After adding services, generate a committable .env.example that lists every secret key (never values) for teammates and CI: 

stack env export --example
# .env.example — generated by Stack, safe to commit
# Values are placeholders only. Run `stack add <service>` to provision.

SUPABASE_URL=
SUPABASE_ANON_KEY=
SUPABASE_SERVICE_ROLE_KEY=
CLERK_SECRET_KEY=
CLERK_PUBLISHABLE_KEY=

The file is written relative to .stack.toml. Pass --output <path> to write elsewhere. Secret values are never included — stack env export --example reads key names from the catalog, not from Phantom.