Skip to main content

Going to Production

Once you are ready to deploy your SST app to production and go live with real users, you should double check a couple of things.

  • Make sure the default removal policy is NOT set to DESTROY for production environments.
  • Make sure the secrets are not stored in the code and committed to Git. Store the secrets with the CI provider or use AWS SSM.
  • Review the log retention setting for Lambda function logs and API access logs. Ensure that the number of days the logs are kept in CloudWatch Logs fits your budget.
  • If you'd like extra visibility on your Lambda functions, consider using a monitoring service for your functions.
  • It's recommended that you and your team do NOT have permission to deploy to production environments from your local machines. Deployments to production environments should be done from a consistent and secure environment like a CI server.

Deployment options​

It's a good idea to create a CI/CD pipeline to deploy your SST apps to production. Here are a couple of ways to do so.

The easiest way to deploy SST to production is to use Seed. Seed is a fully-managed CI/CD pipeline for serverless apps on AWS. It was built by the creators of SST.

There are a couple of other reasons why Seed is a good fit for SST apps.

  1. Speed

    It's the fastest way to deploy CDK apps. Seed automatically caches dependencies to speed up your builds.

  2. Free

    Seed also directly plugs into the SST deployment process. So when an SST app is waiting for CloudFormation to update your stacks, Seed pauses the build process and does this asynchronously. This allows Seed to make SST deployments very efficient and offer it to you for free!

Getting started​

If you haven’t already done so, push your SST app to a Git provider of your choice: GitHub, GitLab, or BitBucket. Your repository can be private or public.

Then, follow these steps in the Seed docs to Add your SST app.

Pull Request workflow​

By enabling the Pull Request workflow, when a PR is opened, Seed will build, test, and deploy the pull request commits automatically into a new stage. The new pull request stage will be an independent clone of your production environment.

Using the PR workflow allows you to share deployment previews with your team. This, in addition to doing code reviews allows you to have a consistent process around how code gets pushed to production.

Other providers​

In addition to Seed, there are other general purpose CI providers that you can use to deploy your SST apps:

  1. Github Actions
  2. Travis CI
  3. CircleCI

Here's what you'll need to add to your CI build scripts. Assuming your production stage is called prod.

$ npm install
$ npx sst deploy --stage prod

# With Yarn

$ yarn
$ yarn sst deploy --stage prod