hey friends 👋 we're building some pulumi tooling for early stage startups ( < 10 engs ) and are wondering if they're more mono-repos vs. multi-repos setups 1. Mono-repo (frontend + backends + services + infra [...]) all in 1 repo) 2. Multi-repo (separate out frontend, from backend / each services /) or any other cross-repo structure If you're in the camp which do you follow and how do you structure your pulumi code?

Hey Ala! For my small engineering team customers I generally stick with the Mono Repo but break out the technologies into different files

👍

if cross team collaboration gets to be a challenge (infra vs devs for example) then we can easily break up the code later

Generally working too fast to spend too much time thinking about organization, but I try to keep pulumi config namespaced by area of concern - db, iam, redis, compute, etc. I also separate pure-infrastructure from application layer resources. That allows multiple developers to share physical infrastructure, but separate applications while working. There's also a couple exceptions - admin-type things live in their own stack, and things which are shared between environments also have a stack (currently just artifact management).

@tall-energy-85878 👍 sounds like you place those multiple stack defs in the same repo though? do all the apps live in the same repo or separated out in multiple repos? (and if its the latter, how do they use the shared configs / infra)

They're all in the same repo, yeah - we use esc and stackrefs to share config across stacks, though, which would transfer between either monorepo or non-monorepo projects.

We use #2 quite successfully across microservices, every repository basically looks the same, but can be in a different programming language aligned with the same base level standards for that ecosystem. This is handy if Teams / Frontend / Backend / Components use different languages, and you can still take advantage of Stack References.

@millions-furniture-75402 the eng team is larger than 10 folks right?

No, we started that pattern when it was ~3, and we still have smaller teams self-managing for the most part, but they are overseen by operations teams.