Add Artifact Registry ADR-024: Infrastructure for GitLab.com Beta Delivery
Adds ADR-024: Infrastructure for GitLab.com Beta Delivery and links it from the Artifact Registry design-document index.
What the ADR says
The ADR decides how the Artifact Registry's infrastructure is delivered, using Artifact Registry and Auth as the thinnest viable platform for building out Theseus — the platform teams pave the path just ahead of the application teams, who integrate continuously through Caproni and a weekly demo.
Phase 1 — GitLab.com closed beta. Artifact Registry runs as a single global, multi-tenant service on Runway for GKE v2 (the Enterprise, non-Cellular instance), with tenants isolated by namespace partitioning. Three components ship: Artifact Registry (Go), IAM Data Access (Go), and GLAZ (Rust authorization sidecar), built non-FIPS with GoReleaser (FIPS and TUBE are off the critical path).
Provisioning. Postgres/CloudSQL, Memorystore Redis, and object storage are provisioned through COM modules in the Runway v2 provisioner and consumed via Fairway-generated service bindings (with LabKit v2 for observability). Cloud CDN and Yugabyte are delivered directly as external COM modules rather than through Runway (Cloud CDN owned by the Container Registry team; Yugabyte reached over Private Service Connect). Database migrations are owned by the application.
Phase 2 — Cellular target (deferred). Once the Theseus Cells & Dedicated Platform Binding is ready, the registry is deployed into Cells via Instrumentor, reusing GitLab's existing Cells/Dedicated investment rather than a parallel cellular fabric; customers are migrated transparently and slug authority moves to the Anchor Topology service.
Why
Supersedes the bespoke cell-based approach in !19657 (closed), building instead on Theseus and Modular Components, and references the Theseus Platform Vision (!19702 (merged), not yet merged).