SST: running a full-stack app on your own cloud account

What SST actually takes off your plate

Deploying a full-stack app normally splits into two jobs that drift apart. The application code lives in one repository and one language; the infrastructure lives in another set of files, often another tool, and is edited by whoever remembers how. SST's stated purpose is to remove that split: the README describes it as a way to "Build full-stack apps on your own infrastructure." The infrastructure is yours, meaning your AWS account, not a vendor's shared runtime.

The audience is narrower than the tagline suggests. The repository is primarily TypeScript, the platform package is TypeScript, the JS SDK is TypeScript, and the CLI is Go. The getting-started list points at Next.js, Remix, Astro and a plain API, all under an AWS path. If your application is not JavaScript or TypeScript, the README still gives you a global CLI install, but the examples and the platform layer are built around the JS ecosystem. A Python or Go service can be deployed, but it will not be the shape the project is designed around.

The second audience is the one that already has an AWS account and does not want to hand it over. SST's pitch is that you keep the account, the resources and the bill, and get a framework that describes them. That is a real difference from a platform that provisions a runtime you never see.

The Go CLI and the TypeScript platform layer

The repository layout shows two halves. The cmd/ directory holds the CLI entrypoint, written in Go; the platform/ directory holds the TypeScript that describes infrastructure; sdk/js/ holds the JavaScript SDK; www/ holds the documentation site. The package.json workspaces list is exactly those three: www, platform and sdk/js. The Go module is declared as github.com/sst/sst/v3 and requires Go 1.24.7.

That split explains the install instructions. The CLI is a compiled binary, which is why the README offers a curl script for non-JavaScript users and pre-compiled binaries on the releases page. The platform layer is npm-distributed TypeScript, which is why JavaScript projects are told to install SST locally so the CLI version is tracked with the app.

The dependency list in go.mod is a useful signal about what the CLI actually talks to. It pulls in AWS SDK v2 service modules for Lambda, ECS, ECR, S3, CloudFront, CloudFront KeyValueStore, IAM, STS, SSM, Route 53, RDS Data, and AppSync, plus cloudflare-go. Those are the resource families the tooling is built to manage. Pulumi appears as a dependency as well, which is consistent with a framework whose platform layer produces infrastructure rather than calling AWS APIs directly for every resource. The README's own concept list (Live, Linking, Console, Components) is the vocabulary for that layer, and the docs site is where each is defined.

Installing SST and deploying a first app

For a JavaScript project, the README's instruction is to install SST locally so the CLI version travels with the app, then run it with the same package manager. The npm line is the default; pnpm, bun and yarn equivalents are commented in the same block.

npm install sst
# pnpm add sst
# bun add sst
# yarn add sst

If you are not using JavaScript, the CLI installs globally through a shell script. The README also documents pinning a version through the VERSION environment variable, which is the form you would use in a CI image that must not pick up a new release mid-quarter.

curl -fsSL https://sst.dev/install | bash

curl -fsSL https://sst.dev/install | VERSION=0.0.403 bash

There is no third path in the README beyond downloading pre-compiled binaries from the releases page and copying them where you want them. After install, the getting-started links are per framework: Next.js, Remix, Astro, or a bare API, each pointing at an sst.dev/docs/start/aws page. Those pages are where the first app is defined, and the README does not restate their contents, so the concrete config belongs to the docs rather than to this page.

For anyone working on SST itself rather than with it, the repository documents its own setup: run bun run setup, which requires Go and Bun, then run the CLI against one of the example apps.

cd examples/aws-api
go run ../../cmd/sst <command>

Building the binary is bun run build:cli, and the docs build through bun run docs:generate and bun run docs:dev.

Where SST stops helping

The README is a landing page, not a manual, and that shapes what can be said honestly here. It does not document rollback, state migration, drift detection, or what happens when a deploy fails halfway. Those are the questions that decide whether an infrastructure tool survives its second year, and none of them appear in the README. A team evaluating SST should treat the docs site as the source for those answers, and should treat their absence from the README as a gap to close before adopting, not as evidence they are unhandled.

The second limitation is structural. SST deploys into your own account, so you own the IAM policies, the service quotas, the region choices and the bill. That is the point, but it also means SST cannot make an AWS problem go away. If your team has no one who can read a CloudWatch log group or reason about a Lambda concurrency limit, the framework will not substitute for that.

The third is ecosystem shape. The examples directory is overwhelmingly AWS-prefixed, and go.mod's cloud dependencies are AWS plus Cloudflare. If your target is another cloud, the repository as described does not offer a path, and the README does not claim one.

SST against hand-written Terraform

The natural comparison is Terraform, and the difference is where the description lives. Terraform describes infrastructure in HCL, a configuration language separate from the application, applied by a binary that keeps a state file. SST's platform layer is TypeScript in the same repository as the app, and the CLI is a Go binary that reads that layer. Resource references flow into application code through the linking concept the README lists, rather than through outputs pasted into environment variables.

That is a genuine trade. TypeScript gives you loops, types and the same editor tooling as the rest of the app; it also means your infrastructure is only as reviewable as your TypeScript, and a determined engineer can compute resource names at deploy time in ways a reviewer cannot see. HCL is more boring and more legible to a platform team that does not read TypeScript. A team with an existing Terraform estate and a platform group that owns it will find SST's model duplicates that ownership rather than replacing it.

The second difference is scope. Terraform has providers for everything; SST's dependency list covers a specific AWS surface plus Cloudflare. If your infrastructure includes resources outside that surface, you are either mixing tools or waiting for a component that does not exist yet.

Licence, maintenance and the cost of upgrading

SST is MIT licensed. In practice that means you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice travel with copies or substantial portions. It does not grant trademark rights, and it comes with no warranty. This is not legal advice; if your organisation has a policy on licence review, MIT is on the permissive side of it, but the review is still yours to run.

Maintenance is visible in two places. The repository is not archived, and the last push was on 2026-07-12. The releases page shows v4.17.1 on 2026-07-12, v4.17.0 on 2026-06-26 and v4.16.0 on 2026-06-24, so the cadence over that window was roughly a minor release every few weeks with a patch on top. That is a shipping project, not an abandoned one.

Upgrade cost is harder to pin down from the README alone. What is documented is version pinning: JavaScript projects install SST locally so the CLI version is tracked with the app, and the curl installer accepts VERSION to pin. Both exist precisely because a floating CLI version is a risk. The README's own contributing section points at the docs as the place to improve, and the docs are versioned with the site, so the practical upgrade path is to read the release notes for the minor you are moving to and pin until you have.

Editorial conclusion

Adopt SST if you already own an AWS account, your app is JavaScript or TypeScript, and you want the infrastructure described in the same language as the application rather than in a separate configuration tree. Do not adopt it if you want a host that owns the runtime, or if your team has no appetite for cloud accounts, IAM and per-resource cost. Before committing, verify the framework integrations your stack needs on sst.dev/docs/start/aws, confirm the component list covers your datastore and queue choices, and check whether the CLI install path you prefer (npm install sst or the curl script) fits how your CI machines are provisioned.

Frequently asked questions

Official sources

1. anomalyco/sst on GitHub
2. License: MIT
3. Project website
4. README
5. Releases