Which strategy should I use for Cloud Run Go 1.22 to Go 1.24 Migration Before July 28,?

Decide whether to move Cloud Run Go services off the managed Go 1.22 runtime to a newer managed runtime or switch to custom containers before Go 1.22 is decommissioned.

Upgrade to managed Go 1.24 by default; use custom containers only if native deps, base-image control, or nonstandard build/toolchain needs block managed runtimes.

Blockers

Who this is for

Candidates

Upgrade to a newer managed Cloud Run Go runtime, with Go 1.24 as the practical floor

Cloud Run's runtime lifecycle page shows Go 1.22 (`go122`) deprecates on 2026-01-28 and is decommissioned on 2026-07-28. As of 2026-04-01, Go 1.23 is already deprecated, with decommission scheduled for 2026-08-21, so it is a weak interim target. Go 1.24 (`go124`) is on the managed `google-22` and `google-22-full` stacks, with deprecation on 2026-09-02 and decommission on 2027-03-02, which gives materially more runway than staying on 1.22. As of 2026-04-01, Cloud Run bills source deployments as normal Cloud Run services; the extra cost surface is build and image storage, because source deployments use Cloud Build and Artifact Registry, which are priced separately.

When to choose

Use this when you want the lowest-ops path and your service can stay within Cloud Run's managed runtime model. It is the default choice when the blocker is only the Go 1.22 lifecycle deadline, because it avoids taking on Dockerfile ownership while extending support well past July 28, 2026.

Tradeoffs

Pros: managed runtime base images, less platform maintenance, and longer support runway than Go 1.22 or already-deprecated Go 1.23. Cons: deploy-from-source is a convenience path with limited build customization, and source builds can add Cloud Build and Artifact Registry charges outside core Cloud Run runtime pricing.

Cautions

Do not treat Go 1.23 as a long-term bridge: as of 2026-04-01, it is already deprecated. If you use deploy-from-source, verify Cloud Build permissions and watch Artifact Registry storage usage, because those costs are separate from Cloud Run service billing.

Move to custom containers on Cloud Run

Cloud Run lets you deploy your own container image and use any language version or base image, as long as the image follows the Cloud Run container runtime contract. The main technical requirements are that executables are compiled for Linux 64-bit with `linux/amd64` support, and the ingress container listens on `0.0.0.0` on the configured port, with `PORT` injected by Cloud Run and `8080` as the default. This path avoids managed-runtime lifecycle coupling for Go 1.22 specifically, but it shifts responsibility for the image, base OS, and runtime patching to your team. As of 2026-04-01, runtime billing is still Cloud Run billing; the difference is operational ownership of the image pipeline rather than a cheaper serving price.

When to choose

Use this when managed runtimes are blocked by native dependencies, base-image requirements, unusual build steps, or a need to pin a Go toolchain outside the managed runtime path. It is the right choice when control over the container is more important than keeping Google-managed runtime updates.

Tradeoffs

Pros: full control over Go version, base image, system packages, entrypoint, and hardening choices. Cons: you now own Dockerfile maintenance, runtime patch cadence, image build pipeline, and Cloud Run contract compliance.

Cautions

A custom image does not remove Cloud Run constraints: the service must still listen on `0.0.0.0`, honor the injected `PORT`, and include `linux/amd64` in a multi-arch image. If you store images in Artifact Registry or use remote repositories, account for registry setup and access controls separately from Cloud Run service configuration.

Facts updated: 2026-04-01
Published: 2026-04-03

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Which strategy should I use for Cloud Run Go 1.22 to Go 1.24 Migration Before July 28,?"
Missing something? Request coverage