What CI does in this design is shell out. `nx affected -t deploy` runs each affected project's own deploy target, and that target's `dependsOn: ["build"]` puts the build ahead of it [6][5]. The verb itself sits in `apps/web/project.json` as one `nx:run-commands` string chaining a `docker build --platform linux/amd64`, a push to `gcr.io/$PROJECT/web:latest`, and `gcloud run deploy web --region us-central1 --allow-unauthenticated` [5].
Read that string for what it needs from outside itself. It needs `$PROJECT` set, a Docker daemon that can produce linux/amd64, and credentials `gcloud` will pick up [15]. Those three inputs vary by environment even when the command's text does not: in CI the identity is a keyless federated service account [10][11], on a laptop it is whatever you last logged into, and a stale `$PROJECT` in your shell sends the same image to the wrong project, so "same command, same flags, same memory limits" [6] describes the string, not the run it produces. One copy of the command does beat the two copies the post blames for drift, where a hand-tuned memory limit ships by hand and CI overwrites it for a month [2][3]. The local run and the CI run still differ in identity and environment even when the command string matches.
Nothing checks that string, either. Change `us-central1` to a region you have no quota in and the failure arrives at deploy time on main. `--allow-unauthenticated` rides in the same line, so whether the service answers the public internet is now a one-line diff in a project file [18]. If `apps/*/project.json` is not in a CODEOWNERS path, that is the gap to close before the pattern is worth adopting.
The identity side is the part I would copy without changes. It replaces a service-account JSON key pasted into a repo secret, which is a permanent deploy credential that nothing rotates and nobody revokes [9], with an exchange of GitHub's per-run OIDC token narrowed by provider condition to a single repository [10][13]. Standing it up is eight one-time gcloud calls: one service account, five role bindings, one pool, one provider [14]. Of the five roles the post explains one, `roles/iam.serviceAccountUser`, and the explanation earns its space: deploying a service that runs as another account is impersonation, and the permission error names the runtime account rather than the deployer, which the author prices at twenty minutes [12]. `roles/storage.admin` and `roles/secretmanager.viewer` arrive without a stated reason [17]. storage.admin is a broad grant for something whose described job is pushing images.
Two things would have to be true for the "deploy what changed" half to transfer. First, each app's deploy has to be one idempotent command with no ordering between services. Cloud Run fits that [1]; a schema migration that must land before the new revision does not. Second, `affected` has to be right about inputs, and that is the section the supplied text stops before [16]. If the graph does not count the Dockerfile or the lockfile as inputs to `web`, then "deploy what changed" quietly means "deploy what changed in application code".
Keep the registry note in view regardless of the rest. Container Registry stopped accepting writes on 18 March 2025, and `gcr.io` now proxies to Artifact Registry only for repositories that already exist, so a new project's first push returns 404 until one is created [7]. The post's own advice for new projects is to skip the mirror and push to `us-docker.pkg.dev/$PROJECT/gcr.io/web:latest` [8]. That is the line I would take, because a mirror you created by hand to satisfy a hostname is one more thing in the deploy path with no owner.
