---
source_url: "https://sst.dev/docs/"
title: "What is SST | SST"
mirrored_at: 2026-08-15T03:35:42.006Z
host: sst.dev
cited_in_42a: true
mirror_canonical: "https://index.42a.ai/sst.dev/docs/index"
---

> **Original source:** https://sst.dev/docs/

SST is a framework that makes it easy to build modern full-stack applications on your own infrastructure.

What makes SST different is that your _entire_ app is **defined in code** — in a single `sst.config.ts` file. This includes databases, buckets, queues, Stripe webhooks, or any one of **150+ providers**.

With SST, **everything is automated**.

* * *

## [Components](#components)

You start by defining parts of your app, _**in code**_.

For example, you can add your frontend and set the domain you want to use.

-   [Next.js](#tab-panel-7)
-   [Remix](#tab-panel-8)
-   [Astro](#tab-panel-9)
-   [Svelte](#tab-panel-10)
-   [Solid](#tab-panel-11)

```
new sst.aws.Nextjs("MyWeb", {  domain: "my-app.com"});
```

Just like the frontend, you can configure backend features _in code_.

Like your API deployed in a container. Or any Lambda functions, Postgres databases, S3 Buckets, or cron jobs.

-   [Containers](#tab-panel-12)
-   [Functions](#tab-panel-13)
-   [Postgres](#tab-panel-14)
-   [Bucket](#tab-panel-15)
-   [Cron](#tab-panel-16)

```
const cluster = new sst.aws.Cluster("MyCluster", { vpc });new sst.aws.Service("MyService", {  cluster,  loadBalancer: {    ports: [{ listen: "80/http" }]  }});
```

You can even set up your Stripe products in code.

```
new stripe.Product("MyStripeProduct", {  name: "SST Paid Plan",  description: "This is how SST makes money",});
```

You can check out the full list of components in the sidebar.

* * *

## [Infrastructure](#infrastructure)

The above are called **Components**. They are a way of defining the features of your application in code. You can define any feature of your application with them.

In the above examples, they create the necessary infrastructure in your AWS account. All without using the AWS Console.

Learn more about [Components](https://sst.dev/docs/components/).

* * *

### [Configure](#configure)

SST’s components come with sensible defaults designed to get you started. But they can also be configured completely.

For example, the `sst.aws.Function` can be configured with all the common Lambda function options.

```
new sst.aws.Function("MyFunction", {  handler: "src/lambda.handler",  timeout: "3 minutes",  memory: "1024 MB"});
```

But with SST you can take it a step further and transform how the Function component creates its low level resources. For example, the Function component also creates an IAM Role. You can transform the IAM Role using the `transform` prop.

```
new sst.aws.Function("MyFunction", {  handler: "src/lambda.handler",  transform: {    role: (args) => ({      name: `${args.name}-MyRole`    })  }});
```

Learn more about [transforms](https://sst.dev/docs/components#transforms).

* * *

### [Providers](#providers)

SST has built-in components for AWS and Cloudflare that make these services easier to use.

However it also supports components from any one of the **150+ Pulumi/Terraform providers**. For example, you can use Vercel for your frontends.

```
new vercel.Project("MyFrontend", {  name: "my-nextjs-app"});
```

Learn more about [Providers](https://sst.dev/docs/providers) and check out the full list in the [Directory](https://sst.dev/docs/all-providers#directory).

* * *

## [Link resources](#link-resources)

Once you’ve added a couple of features, SST can help you link them together. This is great because you **won’t need to hardcode** anything in your app.

Let’s say you are deploying an Express app in a container and you want to upload files to an S3 bucket. You can `link` the bucket to your container.

```
const bucket = new sst.aws.Bucket("MyBucket");const cluster = new sst.aws.Cluster("MyCluster", { vpc });new sst.aws.Service("MyService", {  cluster,  link: [bucket],  loadBalancer: {    ports: [{ listen: "80/http" }]  }});
```

You can then use SST’s [SDK](https://sst.dev/docs/reference/sdk/) to access the S3 bucket in your Express app.

```
import { Resource } from "sst";console.log(Resource.MyBucket.name);
```

Learn more about [resource linking](https://sst.dev/docs/linking/).

* * *

## [Project structure](#project-structure)

We’ve looked at a couple of different types of files. Let’s take a step back and see what an SST app looks like in practice.

* * *

### [Drop-in mode](#drop-in-mode)

The simplest way to run SST is to use it as a part of your app. This is called _drop-in mode_. For example, if you are building a Next.js app, you can add a `sst.config.ts` file to the root.

```
my-nextjs-app├─ next.config.js├─ sst.config.ts├─ package.json├─ app├─ lib└─ public
```

View an [example Next.js](https://github.com/anomalyco/sst/tree/dev/examples/aws-nextjs) app using SST in drop-in mode.

* * *

### [Monorepo](#monorepo)

Alternatively, you might use SST in a monorepo. This is useful because most projects have a frontend, a backend, and some functions.

In this case, the `sst.config.ts` is still in the root but you can split it up into parts in the `infra/` directory.

```
my-sst-app├─ sst.config.ts├─ package.json├─ packages│  ├─ functions│  ├─ frontend│  ├─ backend│  └─ core└─ infra
```

Learn more about our [monorepo setup](https://sst.dev/docs/set-up-a-monorepo/).

* * *

## [CLI](#cli)

To make this all work, SST comes with a [CLI](https://sst.dev/docs/reference/cli/). For JavaScript projects, install SST locally in your project so the CLI version is tracked with your app.

-   [npm](#tab-panel-17)
-   [pnpm](#tab-panel-18)
-   [Bun](#tab-panel-19)
-   [Yarn](#tab-panel-20)

```
npm install sst
```

You can then run the CLI with your package manager.

-   [npm](#tab-panel-21)
-   [pnpm](#tab-panel-22)
-   [Bun](#tab-panel-23)
-   [Yarn](#tab-panel-24)

```
npx sst dev
```

If you are not using JavaScript, you can install the CLI globally.

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

Learn more about the [CLI](https://sst.dev/docs/reference/cli/).

* * *

### [Dev](#dev)

The CLI includes a `dev` command that starts a local development environment.

```
sst dev
```

This brings up a _multiplexer_ that:

1.  Starts a watcher that deploys any infrastructure changes.
2.  Runs your functions [_Live_](https://sst.dev/docs/live/), letting you make and test changes without having to redeploy them.
3.  Creates a [_tunnel_](https://sst.dev/docs/reference/cli#tunnel) to connect your local machine to any resources in a VPC.
4.  Starts your frontend and container services in dev mode and links it to your infrastructure.

The `sst dev` CLI makes it so that you won’t have to start your frontend or container applications separately. Learn more about [`sst dev`](https://sst.dev/docs/reference/cli/#dev).

* * *

### [Deploy](#deploy)

When you’re ready to deploy your app, you can use the `deploy` command.

```
sst deploy --stage production
```

* * *

#### [Stages](#stages)

The stage name is used to namespace different environments of your app. So you can create one for dev.

```
sst deploy --stage dev
```

Or for a pull request.

```
sst deploy --stage pr-123
```

Learn more about [stages](https://sst.dev/docs/reference/cli#stage).

* * *

## [Console](#console)

Once you are ready to go to production, you can use the [SST Console](https://sst.dev/docs/console/) to **auto-deploy** your app, create **preview environments**, and **monitor** for any issues.

![SST Console](https://sst.dev/_astro/sst-console-home.-pMOaf_T_hPeMB.webp)

Learn more about the [Console](https://sst.dev/docs/console/).

* * *

## [FAQ](#faq)

Here are some questions that we frequently get.

* * *

**Is SST open-source if it’s based on Pulumi and Terraform?**

SST uses Pulumi behind the scenes for the providers and the deployment engine. And Terraform’s providers are _bridged_ through Pulumi.

SST only relies on the open-source parts of Pulumi and Terraform. It does not require a Pulumi account and all the data about your app and its resources stay on your side.

* * *

**How does SST compare to CDK for Terraform or Pulumi?**

Both CDKTF and Pulumi allow you to define your infrastructure using a programming language like TypeScript. SST is also built on top of Pulumi. So you might wonder how SST compares to them and why you would use SST instead of them.

In a nutshell, SST is for developers, while CDKTF and Pulumi are primarily for DevOps engineers. There are 3 big things SST does for developers:

1.  Higher-level components
    
    SST’s built-in components like [`Nextjs`](https://sst.dev/docs/component/aws/nextjs/) or [`Email`](https://sst.dev/docs/component/aws/email/) make it easy for developers to add features to their app. You can use these without having to figure out how to work with the underlying Terraform resources.
    
2.  Linking resources
    
    SST makes it easy to link your infrastructure to your application and access them at runtime in your code.
    
3.  Dev mode
    
    Finally, SST features a unified local developer environment that deploys your app through a watcher, runs your functions [_Live_](https://sst.dev/docs/live/), creates a [_tunnel_](https://sst.dev/docs/reference/cli#tunnel) to your VPC, starts your frontend and backend, all together.
    

* * *

**How does SST make money?**

While SST is open-source and free to use, we also have the [Console](https://sst.dev/docs/console/) that can auto-deploy your apps and monitor for any issues. It’s optional and includes a free tier but it’s a SaaS service. It’s used by a large number of teams in our community, including ours.

* * *

#### [Next steps](#next-steps)

1.  [Learn the SST basics](https://sst.dev/docs/basics/)
2.  Create your first SST app
    -   [Build a Next.js app in AWS](https://sst.dev/docs/start/aws/nextjs/)
    -   [Deploy Bun in a container to AWS](https://sst.dev/docs/start/aws/bun/)
    -   [Build a Hono API with Cloudflare Workers](https://sst.dev/docs/start/cloudflare/hono/)