Skip to main content

Frequently Asked Questions

Some common questions we get about SST.

If there's something that we are not addressing here, feel free to hop on to our Discord and let us know.


Would SST work for my use case?

A key aspect of SST is that you are not locked into using our constructs. You can always drop down to CDK and deploy any AWS service with it.

That said, if you hit a limitation, feel free to hop on our Discord and tell us about it.


Do we need another framework for serverless?

While Serverless Framework and SAM have been around for a while, the local development experience for them isn't great. And they require you to define your resources using the really verbose CloudFormation YAML (or JSON).

In comparison, SST features:

  • A Live Lambda Development environment, that introduces a completely new local development experience for serverless.
  • And it uses AWS CDK, allowing you to define your resources using regular programming languages.

We think this makes SST the best way to build serverless applications.


Can I use all the CDK constructs in SST?

Yes. The only caveats are:


Why not just use CDK directly?

If you happen to be familiar with AWS CDK, you might be wondering why not just use CDK directly? There are a couple of reasons but it all revolves around the fact that:

  • CDK is a framework for defining the infrastructure of your application.
  • While SST is a full-stack application framework, similar to Rails or Django, that happens to use CDK to define your infrastructure.

SST, an application framework

What this means in practise is that SST gives you the following:

  1. Types, secrets, and environment variables are shared across your application.
  2. Built-in support for writing database migrations, unit tests, and integration tests for your application code.
  3. Support for deploying to separate environments, allowing for a PR workflow.
  4. Higher-level constructs for common use cases like APIs, databases, cron jobs, etc.
  5. Type-safe libraries for your Lambda functions.

First-class local development environment

SST features the Live Lambda Dev environment that gives you a first-class local development environment for building your applications.

CDK does have the CDK Watch command but it's too slow. It takes a few seconds to redeploy your functions when you make a change. And you can't set breakpoints locally.

TypeScript-first design

CDK is designed to support multiple programming languages. While, SST is designed from the group up for TypeScript. This means that SST code is more readable, less verbose, and far more pleasant to work with. Read more about the design of SST's constructs.


How often is SST's version of CDK updated?

SST internally includes CDK, so you don't have to. We update this version fairly frequently. But if you need the latest version right away, open an issue and we'll push out an update.


Why doesn't SST use CDK's built-in way to build Node.js functions?

CDK has a construct for building Lambda functions, aws-cdk-lib/aws-lambda-nodejs. But SST does not use it, here's why:

SST's Live Lambda Development environment allows you to test your Lambda functions live. To do this, it watches your file changes and transpiles your functions. While they are being transpiled, it blocks any requests that are made to them. To ensure a great experience, it needs to do this process as fast as possible. So we decided to use esbuild, since it's the fastest option. We also maintain an esbuild service internally and call it programmatically to make rebuilds as fast as possible.

It also makes sense to build the Lambda functions in a similar way while running sst deploy.

In addition, we also decided to use esbuild to transpile your CDK code, so you can use the same flavor of JS as your Lambda functions.


How does SST make money?

While SST is open source and free to use, we also run a service that helps you deploy your serverless applications, called Seed. It is a SaaS service and many of the teams using SST use Seed as well.