Monorepo guidance - Multiple Configs / Multiple SST apps / what do I do?

[slavaboiko]

Hi SST team!

I’m reaching out because I’m a bit confused about the best way to orchestrate a large, microservice-based AWS infrastructure with SST v3. A bit of background on my situation:

• I currently manage 300+ AWS resources that I originally exported to Terraform and then imported into Pulumi, where I’ve achieved a clean, no-op state with everything working correctly.
• With a single Pulumi stack, every deploy now takes a very long time as it diffs all 300+ resources—even when I’ve only changed one small Lambda.
• To speed things up, I split my Pulumi setup into multiple stacks: one per microservice (each with its own environments) plus a “shared-infra” stack for VPCs, Route 53 zones, cross-account connectors, etc.
• That helped, but the stack boilerplate for small functions grew tedious, so I’ve been looking at SST v3 for a more streamlined developer experience.

With SST, I’m trying to figure out the optimal pattern for:

1. Per-service SST apps

   • Can I give each microservice its own sst.config.ts (and therefore its own state)?
   • If so, what’s the best way to reuse shared resources (e.g. a VPC or RDS cluster defined in another SST app)?

2. Single “root” SST config

   • Your monorepo example shows auto-discovering multiple sst.config.ts files under one root config—everything ends up in one big state.
   • Is there a way to still deploy individual services independently, e.g.

     npx sst deploy my-service-one my-service-two

     without touching the rest?

3. Hybrid approach

   • Or is there a recommended hybrid: multiple independent SST apps that can optionally reference and import constructs from a “shared-infra” SST app?

I’d love any guidance or patterns from the SST team on how best to structure a large, multi-service codebase so that:

• Small changes don’t trigger full-repo deployments
• Shared infra lives in one place, but services can still be deployed independently
• I can maintain fast feedback loops (i.e. sst dev and sst deploy per service)

Thanks so much for your time and the awesome SST work!

[claridgicus]

Just generally interested in this ticket as my own stack is now 300+ resources

[jayair]

A couple of questions.

• How many resources do you have per service?
• It wasn't clear from your post if you are planning to use SST for the whole setup or still have previously created resources managed by TF or Pulumi?

At first glance, I'd recommend one app with the shared infra. And one app for all the services. You can reference the shared resources through the ARNs or by doing a lookup using the Pulumi AWS components. https://sst.dev/docs/reference-resources/

[thdxr]

i'm also surprised it's slow - we have 300+ resources and it's not that slow

maybe worth trying SST - we have some performance improvements on top of the generic pulumi s3 backend

haven't had too many complaints about deploy speed for updates

[slavaboiko]

Thanks, everyone, for your responses - appreciate it!

In short, we have around 10-30 resources per service (it goes very low-level with Pulumi, so after all the roles, policies, aliases, versions, configs) - the numbers go high.

Obviously, we are not changing all of them every time, mostly what changes is configs or app bundles.

It wasn't clear from your post if you are planning to use SST for the whole setup or still have previously created resources managed by TF or Pulumi?

We have lots of resources that were created with Serverless framework automatically and lots of resources created manually - then I have generated a bad Pulumi code for these resources, so I have a template for what to do.

Now I am in the process of refactoring all this and organising the mess, for now I have ditched Serverless and adopted a structure of one Pulumi stack per service per environment

e.g.

• service: api-one, env: prod => my-org/service-api-one/prod
• service: api-two, env: prod => my-org/service-api-two/prod
• service.api-one, env: test => my-org/service-api-one/test

etc

this allows me to isolate stacks from each other and also add bunch of tooling on top.

but lately I felt like I am creating my whole SST and that's when I decided to ask a question.

I think most important is for me to deploy services independently, as I might have bunch of changes to entire repo, without wanting to deploy services all at once.

in current nx stack I can now do nx run api-one:deploy and nx run api-two:deploy which kicks-off separate pulumi stacks.

is there a way to deploy only selected services with SST?

[jayair]

We do have some support for it, but it's definitely not the recommended approach currently. Try doing it through a single SST app. If you really do find it becomes big then split the apps so that "hard" resources go in one and lighter ones like Lambdas go in another.