Hello Has anyone used pulumi in a monorepo? (Think turborepo)

Not with turbo repo or in a front end project but yeah with cargo workspaces and other projects. I tend to mono repo on related projects

I use it with Yarn(4) workspaces.

I used with pnpm monorepo

How do you folks release only affected parts of your monorepo? Not re-releasing the whole stack?

my concern is how to organize my IaC code in a concise manner (how to split things)

I

cd

into the appropriate workspace and run

pulumi up

.

so no commands for diff stacks? npm run iac:api npm run iac:web Etc

I can, I choose not to. But yes, that would totally work.

do you also abstract away your pulumi code? Lets say you have a workspace that contains all of your own pulumi classes You then import these classes onto your other workspaces? (Web,api, etc) Have you had a scenario where you have pulumi dependents on different workspaces?

Yes, in most cases the app workspaces have no components in it, just the config, build and app code. The resource workspaces contain only component resources. There is at least one case where an app defines its own component resource because I haven't had a need to make it reusable yet.

Thank you so much for your input, I’m about to refactor all my IaC code using turborepo

Bit late to the chat but we’ve had success with Nx for our monorepo. Most of our projects are in C# but Nx is flexible and has really helped move to microstacks and simplify our CI

how do you manage your deploys? Do you have commands to run stacks?

We didn’t go down the route of defining commands for each stack, like

deploy-dev

and

deploy-prod

, as we found not all projects used the same conventions and we need to know ahead of time which env/secrets to set up before running the command. For preview/up we have targets defined like so:

"ci-up": {
      "executor": "nx:run-commands",
      "options": {
        "command": "pulumi up --yes --skip-preview -s  {args.stack}",
        "cwd": "{workspaceRoot}/dist/{projectRoot}/net8.0/publish"
      },
      "dependsOn": ["publish"]
    },

dependsOn: publish

is required due to the way Pulumi and .net interact, and we want to benefit from caching rather than just have Pulumi build the project + dependencies itself. We run this as

nx run ${{ inputs.project }}:ci-up --stack ${{ inputs.stack }} --output-style static

For running commands against an entire env we have

<task>-env

commands, e.g.

preview-env

. This is really useful for checking all projects against a single environment.

"preview-env": {
      "executor": "nx:run-commands",
      "options": {
        "command": "pnpm tsx scripts/ci/pulumi-preview.ts --env={args.env}",
      }
    },

pulumi-preview.ts

does the magic of running nx affected + working out which stacks map to a given env, and then previewing all of them. So our overall CI pseudocode workflow is:

nx affected lint build publish test

foreach env:
 - nx affected -t preview-env --env=env ... -> previews all affected projects/stacks that match the given env

if PR:
  set status check OK

if main:
  foreach affected project:
    - gh workflow dispatch deploy project/stack -> calls a new GH action running ci-preview/ci-up with approval steps

It’s quite new and will likely evolve some more, and the stack -> env mapping is awkward, but overall has really simplified our GH Actions and meant we benefit from nx affected + caching