---
title: "Cloud Run"
slug: cloud-run
section: reference
access: public
summary: "Cloud Run is the GCP-managed serverless container surface where 1Context's gateway runs. It became 1Context's primary deploy target on April 21, 2026, replacing a prior VM-and-blue-green plan within three minutes of an honest-pushback exchange. As of April 26, 2026, Cloud Run hos…"
status: published
asset_base: /assets
home_href: /
toc_enabled: true
talk_enabled: false
agent_view_enabled: true
copy_buttons_enabled: true
footer_enabled: true
last_updated: 2026-04-29
categories: [Tools, Infrastructure]
subject-type: tool
last-reinforced: 2026-04-29
fading-since: null
archived: false
---

## Cloud Run

Cloud Run is the GCP-managed serverless container surface where [1Context](/1context)'s gateway runs. It became 1Context's primary deploy target on April 21, 2026, replacing a prior VM-and-blue-green plan within three minutes of an honest-pushback exchange. As of April 26, 2026, Cloud Run hosts the `onectx-gateway` service in a planned three-lane (blue / green / experimental) layout, with Cloud SQL for the data plane, Workload Identity Federation for CI auth, and a runbook of two specific gotchas that bit the build night and were committed to memory.

### Origin

Cloud Run entered 1Context's architecture at 03:56:48 UTC on April 21, 2026, with Paul's *"yup let's replace the vm with the cloud run"*, immediately after the agent's *"honest answer: no, I don't love it. It's textbook-correct for 2016-era DevOps but overbuilt for where we actually are."* The decision killed the prior wiki VM (static IP `34.29.98.16` preserved in `RESERVED`) and sketched the blue/green plus experimental three-lane architecture in `docs/scaffold-plan.md` (801 lines). The choice rode in alongside the same hour's rejection of [BookStack](/bookstack) and the four-principle complexity-discipline doctrine.

### Role in 1Context

Cloud Run is the production hosting layer for `1context-gateway`. The service runs as tagged revisions promoted across blue / green / experimental lanes, with Cloud SQL (`onectx-db-primary`, `db-custom-1-3840`, [Postgres](https://www.postgresql.org/) 16) as the data plane reached via the Auth Proxy and a VPC connector. Artifact Registry stores container images. ID-token authentication via Workload Identity Federation gates CI deploys; the `run.invoker` IAM grant pattern works around the WIF gcloud limitation that prevents `--audiences`-style ID-token generation from a CI environment without a private key.

The choice is paired with [Postgres](https://www.postgresql.org/) over LanceDB-as-cloud-DB, made the same hour. Paul's stated default (Your Context · Engineering philosophy · Complexity discipline) is *"Postgres-shaped, Cloud-Run-shaped, GCP-managed-shaped defaults until Paul names a specific reason to choose otherwise."* Cloud Run is the canonical instance of that disposition.

### Current State

The walking-skeleton ship landed at 06:00 UTC on April 21 — Milestone 02 green at revision `onectx-gateway-00002-zes`, with smoke proofs on `/readyz`, `/version`, and `/api/v1/hello`. The full CI/CD pipeline went green at 07:57 UTC against `prod---onectx-gateway.run.app`. As of April 26, the production lane has been holding green; the experimental lane has not yet been exercised.

Three gotchas are pinned in the runbook (commit `205189f`):

- `DATABASE_URL` with an empty host fails [SQLx](https://github.com/launchbadge/sqlx)'s parser. Fix: `localhost` placeholder + `host=` socket query param.
- **Cloud Run reserves `/healthz` (case-sensitive) as its own internal endpoint**, undocumented as far as the agent could tell. `/HEALTHZ`, `/health`, `/livez`, and `/readyz` all reach the container fine.
- Cloud Run validates ID tokens against the **main service URL**, not tagged URLs, so audience-mismatched tokens silently fail. CI gets the auth-action's own ID-token output rather than asking gcloud to mint one.

### Relationship to Other Subjects

Cloud Run is the hosting layer for [1Context](/1context); it sits above Cloud SQL (Postgres data plane) and Artifact Registry (image store), and depends on Workload Identity Federation for CI auth. It replaced the prior wiki VM that ran [BookStack](/bookstack) / MariaDB. It connects to [hapticainfra](/haptica) as the deployment target the lab-network and homelab services orchestrate against. Adjacent: [Cloudflare Workers](https://workers.cloudflare.com/) for the secret-storage tier — a separate hosting choice for the zero-knowledge passwords path, kept distinct from Cloud Run because the trust boundaries differ.

### Open Questions

The three-lane (blue/green/experimental) architecture is sketched but not exercised under real promotion load — promotion mechanics, traffic-split semantics, and rollback procedures are not yet runbook-grade. Whether `experimental` should serve real demo URLs or stay private is undecided. Cost discipline at Cloud Run scale (idle-instance pricing, cold-start budgets) has not yet had a serious pass; the current gateway is small enough that the question hasn't bitten.