@cfxlabsinc/nx-pulumi

Workspace-internal Nx plugin that contributes Pulumi targets to any project that has a pulumi/Pulumi.yaml.

Inferred targets

The plugin's createNodes watches for **/pulumi/Pulumi.yaml. When it finds one alongside the project's project.json, it contributes:

• deploy, the apply; deploy-pulumi on a project that also has an SST app, whose deploy (from @cfxlabsinc/nx-sst) composes the two halves. It depends on the bundle build (build-lambda, or build for the Rust lambdas), on db:migrate (every project but aurora, whose stack the migration runs against), and on a Next app's deploy-sst unless metadata.deploy.pulumiFirst reverses that edge. metadata.deploy.after lists projects whose deploy it waits on (the API authorizer waits on every API stack that sets the requiredPermission it reads)
• pulumi-preview (dependsOn: ["build-lambda"] for a lambda, nothing otherwise)
• pulumi-preview-dev / pulumi-preview-prod, one per Pulumi.<stack>.yaml, on every project but the Next apps (whose stacks deploy with their SST app). They depend on the bundle build, so one nx affected -t pulumi-preview-dev pulumi-preview-prod builds each bundle once and previews both stacks
• pulumi-cancel
• pulumi-refresh
• pulumi-destroy
• pulumi-stack-init

deploy, pulumi-cancel and pulumi-refresh have one configuration per Pulumi.<stack>.yaml and no default: nx runs a missing configuration as the default, so a default would turn -c prod on a dev-only stack into a dev apply. Without -c they refuse. deploy also has a no-op configuration for a stage the project has no stack in, so another project's metadata.deploy.after can name a single-stage project. The others have dev and prod with defaultConfiguration: "dev". Every project gets the tags deploy and stack:<stack> per stack file, which is how a deploy run selects.

nx run <p>:deploy -c dev also runs db's migration. To apply one stack alone from a laptop, add --excludeTaskDependencies (and build a lambda's bundle first).

On a runner

deploy, the previews, pulumi-refresh and pulumi-cancel switch on GITHUB_ACTIONS. Off a runner they are the laptop command above. On one they run src/ci.sh, which:

• uses the OIDC credentials already in the environment — no AWS profile;
• sets PULUMI_BACKEND_URL rather than pulumi login, because many run at once and concurrent logins race on ~/.pulumi/credentials.json;
• upserts the stack (pulumi stack select --create) for an apply or preview, then runs up --yes --skip-preview, preview --diff, refresh --yes --run-program (PULUMI_CLEAR_PENDING_CREATES=true adds --clear-pending-creates) or cancel --yes;
• retries once, only on text file busy (two tasks materialising the same bridged Terraform provider);
• keeps the log in $RUNNER_TEMP/pulumi-logs/<project>-<stack>.log;
• with CFX_CI_AWS_PROFILE_PREFIX set, sets AWS_PROFILE=<prefix>-<stack> and unsets ambient keys, so a job holding both accounts hands each stack its own.

deploy.yml calls nx run-many -t deploy deploy-schedules -c <stack> over the selected stacks, and the Next apps in a second call with deploy-sst deploy-pulumi; the task graph runs each deploy after db:migrate and its lambda build. pr.yml's Previews calls nx affected -t pulumi-preview-dev pulumi-preview-prod.

The full executor and command live in this plugin — no targetDefaults indirection. To change the Pulumi command shape, edit src/plugin.ts.

Registration

Plugin is registered in workspace nx.json under plugins:

{
  "plugin": "@cfxlabsinc/nx-pulumi",
  "options": {}
}
Copy

Resolves through the workspace dependency in the root package.json:

"@cfxlabsinc/nx-pulumi": "workspace:*"
Copy