SST Ion is the open-source deployment engine for SST (Serverless Stack Toolkit). It replaces the legacy CDK + CloudFormation pipeline with Pulumi and Terraform, delivering faster deployments, multi-cloud support, and a simpler component model. As of SST v3, Ion is the default and recommended engine for all new projects.

What Is SST Ion?

SST Ion is an open-source infrastructure-as-code engine designed specifically for SST applications. Where the original SST engine compiled your sst.config.ts down to AWS CDK constructs and deployed them via CloudFormation stacks, Ion uses Pulumi as the deployment runtime and Terraform providers under the hood. This gives SST access to thousands of resources beyond AWS – including Cloudflare, Vercel, Stripe, GitHub, and more – while keeping the same TypeScript-first developer experience.

Ion is the engine behind SST v3, which is the current stable major version of SST.

Key facts:

  • Open-source, MIT-licensed (github.com/sst/sst)
  • Default engine in SST v3 (no opt-in flag needed)
  • Built on top of Pulumi automation API + Terraform providers
  • Backwards-incompatible with SST v2 – migration is required
  • Maintained by the SST team (Anomaly Innovations)

Why the Switch from CDK and CloudFormation?

The previous SST engine inherited the limitations of AWS CloudFormation: slow deploys, opaque error messages, hard 500-resource per-stack limits, and a 30+ minute rollback window when something failed. CDK also locked SST into the AWS ecosystem.

Ion solves all four problems:

  1. Faster deploys – Pulumi performs parallel operations and skips no-op resources, typically noticeably faster than equivalent CFN stacks.
  2. Better error messages – failures point to the exact resource and line in sst.config.ts.
  3. No CloudFormation stack limits – large monorepos no longer hit the 500-resource ceiling.
  4. Multi-cloud – deploy AWS + Cloudflare + GitHub resources from a single config.

SST Ion vs SST v2 (CDK) – Side-by-Side

Feature: IaC engine SST v2 (legacy): AWS CDK + CloudFormation SST Ion / SST v3: Pulumi + Terraform providers

Feature: Default version SST v2 (legacy): v2.x (maintenance) SST Ion / SST v3: v3.x (current)

Feature: Deploy speed SST v2 (legacy): Limited by CloudFormation SST Ion / SST v3: Parallel, faster

Feature: Multi-cloud SST v2 (legacy): AWS only SST Ion / SST v3: AWS + Cloudflare + many more

Feature: State storage SST v2 (legacy): CloudFormation stacks SST Ion / SST v3: Pulumi state (S3 bucket)

Feature: Resource limit SST v2 (legacy): 500 per stack (CFN) SST Ion / SST v3: Practically unlimited

Feature: Frontend support SST v2 (legacy): Next.js, Remix, Astro, SvelteKit, Solid SST Ion / SST v3: Next.js, Remix, Astro, SvelteKit, Solid, Nuxt, TanStack Start, static sites

Feature: Migration path SST v2 (legacy): – SST Ion / SST v3: Manual, see migration guide

How SST Ion Works

A typical SST Ion project follows three steps:

  1. Define your frontend. Add a single component to sst.config.ts for your Next.js, Remix, Astro, SvelteKit, or static site.
  2. Configure backend resources. Add components for queues, buckets, cron jobs, databases, and APIs – all in TypeScript, no AWS Console required.
  3. Deploy. Run npx sst deploy and Ion provisions everything in your AWS account via Pulumi.

Each component you write maps to one or more underlying Pulumi/Terraform resources, but Ion hides that complexity behind ergonomic, opinionated wrappers.

Example: Full-stack app in 10 lines

A complete sst.config.ts that deploys a Next.js frontend, a Postgres database, a cron job, a bucket, and a queue:

// sst.config.ts export default $config({ app(input) { return { name: „my-app”, home: „aws” }; }, async run() { const bucket = new sst.aws.Bucket(„MyBucket”); const db = new sst.aws.Postgres(„MyDatabase”); const queue = new sst.aws.Queue(„MyQueue”); queue.subscribe(„src/subscriber.handler”);

new sst.aws.Cron("MyCronJob", {
  job: "src/cron.handler",
  schedule: "rate(1 minute)",
});

new sst.aws.Nextjs("MyWeb", {
  domain: "my-app.com",
  link: [bucket, db, queue],
});

}, });

The link property auto-generates IAM permissions and typed environment variables – no manual policy writing.

Migrating from SST v2 to Ion

SST v2 and Ion are not drop-in compatible. Migration is manual, but the steps are well-defined:

  1. Pin your current SST v2 version in package.json to avoid accidental upgrades.
  2. Create a new branch and install SST v3: npm install sst@latest
  3. Rewrite sst.config.ts using the new $config API (the imports change from named imports to the sst.aws.* namespace).
  4. Deploy to a separate stage (e.g. –stage migration-test) and verify everything works.
  5. Cut over DNS and production stage once tested.

Full migration reference: sst.dev/docs/migrate-from-v2

Tip: if your v2 app uses raw CDK constructs that don’t have an Ion equivalent yet, you can still drop down to Pulumi resources directly – Ion exposes the full Pulumi API.

Is SST Ion Production-Ready?

Yes. SST v3 with Ion has been the stable, recommended version since its release and is actively maintained by the SST team.

That said, two caveats:

  • If you have a large SST v2 codebase, plan the migration before your next major release rather than under deadline pressure.
  • A handful of advanced CDK escape hatches from v2 require rewriting against Pulumi primitives.

When to use SST Ion

SST Ion is a strong fit if you are:

  • Building a new full-stack TypeScript app on AWS
  • Deploying Next.js, Remix, Astro, SvelteKit, or a static site with serverless backend
  • Tired of CloudFormation’s 500-resource limit or slow rollbacks
  • Mixing AWS with Cloudflare, GitHub, or other non-AWS resources

It is less of a fit if your team is already deeply invested in a different IaC tool (Terraform-only shop, raw CDK, etc.) and doesn’t need the SST developer experience layer.

Need help with SST or AWS architecture?

We’ve worked on serverless and AWS-based projects at fireup.pro for years – including Next.js, full-stack TypeScript, and migrations from legacy stacks. If you’re planning an SST v2 → v3 migration or designing a new serverless app, talk to an expert.

Further reading on fireup.pro:

External references:

  • SST documentation → sst.dev/docs/
  • SST on GitHub → github.com/sst/sst
  • Pulumi documentation → pulumi.com/docs/