SST

An active resource is any resource created by SST in your cloud provider. This includes:

• Resources from SST built-in components (e.g., Function, Nextjs, Bucket).
• Resources created by any other Terraform or Pulumi provider.

Note: Complex components like Nextjs or StaticSite may create multiple resources.

Criteria for being 'Active'

• A resource is active if the stage it belongs to has been updated during the billing cycle.
• If the only update to a stage was to remove it, those resources are not counted as active.
• PR/Ephemeral Stages: A stage must exist for at least 2 weeks before its resources are counted as active. If a PR stage is created and removed within 2 weeks, it does not count toward your billing.

Autodeploy is a deployment workflow designed specifically for SST apps. Unlike generic CI/CD tools like GitHub Actions or CircleCI, Autodeploy offers several SST-native advantages:

1. Native Workflow Support: It supports branch and Pull Request (PR) workflows out of the box.
2. SST Configuration: You customize your deployment workflow directly within your sst.config.ts.
3. AWS Account Integration: Builds run directly within your own AWS account, allowing them to utilize your VPC and other AWS resources.

It integrates seamlessly with the rest of the SST Console for monitoring and management.

SST is a framework for building full-stack applications where the entire application—including databases, buckets, queues, and frontends—is defined in code within a single sst.config.ts file.

SST uses Components to represent application features. These components automate the creation of infrastructure in your cloud provider (like AWS or Cloudflare) without requiring manual configuration in a web console. SST is built on top of Pulumi and supports over 150 providers, including Vercel and Stripe.

Ion is the code name for a new deployment engine for SST applications. Unlike previous versions of SST that were based on AWS CDK and CloudFormation (CFN), Ion uses Terraform providers to define constructs (components) and Pulumi for deployment.

Key Differences for Developers:

• No CDK Support: You cannot use existing CDK constructs in Ion; components must be migrated to the new engine.
• Component Parity: While the underlying engine is different, the way components look and feel is intended to remain similar to the current SST experience.
• Open Source: Ion will remain completely open source.
• Future Versioning: Once Ion reaches stability, it will be released as SST v3.

SST maintains a state of your app, which is a tree of all resources and their properties. This state is stored locally and backed up to a bucket in your cloud provider account.

Important Safety Rules:

• Do not delete the state bucket: If you lose your state, SST can no longer manage your resources and you will have to manually re-import them.
• Do not manually modify low-level resources: Making manual changes in the AWS/Cloudflare console causes your infrastructure to go 'out of sync' with your SST state. You can attempt to fix this with sst refresh, but manual changes should be avoided.

By default, SST creates one instance of each provider using default settings. You can create additional instances of a provider using the new <provider>.Provider() constructor. This is essential for multi-region or multi-account deployments where specific resources must reside in a different location than your default stack.

// Create a specific instance for us-east-1
const useast1 = new aws.Provider("useast1", { region: "us-east-1" });

// Deploy a resource to that specific provider instance
new aws.acm.Certificate("cert", {
  domainName: "foo.com",
  validationMethod: "EMAIL",
}, { provider: useast1 });