Skip web app deployment during `sst deploy`

[kieranm]

Sometimes we just want to deploy our backend quickly without deploying our Next/Tanstack start apps which take a few minutes each to build.

Is it possible to request a feature like --skip-sites or something, or perhaps a more fine grained --exclude to exclude deploying certain components?

Apologies if I missed something already!

Thanks

[nurulhudaapon]

I've been using --target for only deploying other things but Sites but our 3 Next.js app was still being built which takes pretty long. So have been using the following patch.

https://gist.github.com/nurulhudaapon/dbcadd93acc5109dc49681b0c9cd8a43

I guess the best would be to respect the '--target' and only build, buildable components if they are in the target.

[juxuanu]

You can always SKIP_SITES=1 sst deploy and just wrap the component with an if.

[EthanShoeDev]

I really like the Group approach mentioned here: https://github.com/sst/sst/issues/4738#issuecomment-2427575895

[EthanShoeDev]

@juxuanu Is SKIP_SITES=1 documented anywhere? I cannot find any reference to it.

If we wrap a component in an if, won't it be removed if the if is evaluated to false? I think we are just looking for a way to skip the deploy.

[vimtor]

thankfully Pulumi now has a --exclude flag: https://www.pulumi.com/blog/excluding-targets-from-stack-operations/

we need to update the Pulumi version to be able to use it: #5944

we'll need to add the flag to the CLI after that PR gets merged, should be easy

[EthanShoeDev]

Awesome @vimtor. Would love to see this feature land. Always having to deploy my web app whenever I do any infra change has been a real pain.

[juxuanu]

@juxuanu Is SKIP_SITES=1 documented anywhere? I cannot find any reference to it.

I just made that up, anything to check in your if.

If we wrap a component in an if, won't it be removed if the if is evaluated to false? I think we are just looking for a way to skip the deploy.

That is true. You can also use the env var to decide if you want to destroy resources or not (like you probably do for prod). But yeah, a built in solution would be nicer.

[nurulhudaapon]

You can always SKIP_SITES=1 sst deploy and just wrap the component with an if.

Won't it delete the component?

[vimtor]

Won't it delete the component?

yes, it would

[shmuelhizmi]

@nurulhudaapon @vimtor I think you can always add }, {retainOnDelete: false}); as 3rd argument to any resource

[anatolzak]

To avoid rebuilding the static sites when they haven't changed, we use Turborepo for automatic build caching. It is designed for monorepos with dependency-aware task execution and caching.

Using Turborepo, your static site definition would look like this:

new sst.aws.StaticSite('my-site', {
  path: '.',
  dev: { directory: 'apps/my-site', command: 'pnpm dev' },
  build: {
    command: `pnpm turbo run build --filter @org/your-site`,
    output: 'apps/my-site/dist',
  },
});

If there is a cache hit, the static site won't be rebuilt. Instead, the build output will be retrieved from the cache and placed in the output directory.

You can use the Vercel cache for Turborepo as a fully managed solution, or you can host the cache with a simple AWS Lambda function and S3 bucket. Here is an example repository demonstrating the self-hosted version. It's quite straightforward.

https://github.com/anatolzak/sst-static-site-caching/blob/main/sst.config.ts#L29-L43

https://github.com/user-attachments/assets/59b5ee34-362b-4b54-9412-d1166a6df395