Hi y’all! I could use some thoughts on best practices for stacks and projects. My project consists of DynamoDB, Lambda, an S3 bucket, and a few other tidbits. While they are part of the same overall project, they will be versioned independently and might be worked on by different teams. Ideally I don’t want to deploy the entire project if a simple change is made to the S3 bucket (or more commonly to Lambda). The project also needs to exist in several environments (dev, staging, prod). So how should I create my project(s)? • Do I create a project for each group of resources and stacks for the environments (like lambda/dev and s3/prod) • Do I create a project for the overall project and name my stacks based on resource type and environment (like project acmeserverless and stacks lambda-dev and s3-prod) • Something else that I haven’t thought of

projects are just namespaces for stacks, so your first option seems to make the most sense. That's what we've been doing, and also doing 1 repo per project/stack. That gives good isolation by team for deploy permissions and secrets access.

Pulumi stacks can be used in several different ways, which is the reason why the official docs don't settle on a single best practice. It depends on your needs and constraints. We organize it like this (since the project grew into several hundred aws resources in total): • One project per group of resources / resources managed by the same Dev-team • One stack per project for each env • Currently we configure stack dependencies via pulumi config, but you could easily depend allways on the same stack but named like the current env. - in our case we use config because we can mix dev and staging stacks for new features..

That’s awesome feedback! Thanks all!!