how it works

What happens between “sign up” and “shipped.”

A 90-second walkthrough of the cold-start flow. No video. Just the actual steps your agent runs through.

01 — select or build

Select a stack. Or build your own.

Pick a stack we'd use ourselves, or assemble your own from 23 services we believe in. The combinations are short and opinionated on purpose. Infinite-menu paralysis is an anti-pattern we've all suffered through.

  • Combinations short enough to read in one glance
  • Swap any service for an equivalent. Keep the same key.
  • Click a card and you walk the real onboarding

↳ click any card to pick a tier and start at /get-started

Connect Resend1 / 4

Paste your Resend API key. We validate it against the live API before we store anything.

re_…
idle
02 — connect once

Connect once. We validate live.

We test every credential against the real provider API before we keep it. The provision step three weeks from now isn't where we want to find out the token was bad. So we catch it here.

  • OAuth providers (Neon, Sentry, Vercel, PostHog) authorize you in their own consent flow, the normal one
  • API-key providers (Clerk, Resend, Render, Upstash) deep-link to the exact page in the dashboard where the token lives
  • Validated, encrypted on disk, scoped to your workspace. Plaintext never touches a log.
03 — resolve

Resolve. One call, the whole env.

Your agent calls /api/keys/resolve with the master key. Back comes every env var your stack needs, plus an agent_briefexplaining what each one is. It's the briefing the agent never got, finally written down.

  • No dashboard hopping. No copy-paste rosary.
  • Env var names match what each provider calls them, so the agent recognizes them on sight
resolve · 200 OK
agent_brief · expanded
"agent_brief": {
  "stack": {
    "name": "demo",
    "env": "production",
    "region": "iad1"
  },
  "providers": [
    {
      "id": "neon",
      "role": "Postgres, primary store",
      "owns": ["DATABASE_URL"]
    },
    {
      "id": "clerk",
      "role": "Auth, sessions, users, orgs",
      "owns": ["CLERK_SECRET_KEY", "CLERK_PUBLISHABLE_KEY"]
    },
    {
      "id": "resend",
      "role": "Transactional mail",
      "owns": ["RESEND_API_KEY"]
    }
    …
  ]
}
04 — agent context

A bundle, plus a brief.

The brief tells the agent what each provider is, not just the variable name. An agent that's never seen CLERK_SECRET_KEYbefore now knows it's the server-side auth key for sessions, users, and orgs. The agent stops guessing. You stop pasting the README into the chat.

  • Stack name, environment, and region
  • Each provider's role + which env vars it owns
  • Recommended enhancers, open-source tools the agent can install, with install prompts
05 — three places it lands

Same key. Three places it lands.

One master key, the same everywhere your code runs. Editor, CI, or a local file. It resolves the same way.

  • Cursor or Claude Code: paste into .env.local or wire the MCP server
  • CI / GitHub Actions: one repo secret, every job
  • Local: npx stackstart pull --env writes the file
cursor · app.ts
// import resolves on first call
import { stack } from "@stackstart/sdk";
// your code uses env vars normally
const db = new Pool({ connectionString: process.env.DATABASE_URL });
.github/workflows/deploy.yml
env:
  STACKSTART_KEY: ${{ secrets.STACKSTART_KEY }}
  STACKSTART_ENV: production
local · .env
# generated by `stackstart pull --env development`
STACKSTART_KEY=ss_4f9c…
DATABASE_URL=postgres://…

Stop reading. Start minting.

One master key, every service, every environment. About 90 seconds from here.

Mint a master key →