## What Serve the GitLab.com Artifact Registry on a custom domain (for example `artifact-registry.gitlab.com`) instead of the Runway-issued `artifact-registry-gke.svc.gitlab.net`. ## Why Clients pin the registry host in their configs (`.npmrc`, Maven `settings.xml`, `docker login`), so changing the domain after onboarding breaks every configured user. The host we onboard closed-beta users on is effectively permanent, so this decision gates onboarding. Update 2026-09-02: Runway supports this — asked in [#f_runway](https://gitlab.slack.com/archives/C05G970PHSA/p1788183639756999) and the Runway team documented it the same day: [custom hostnames](https://docs.runway.gitlab.com/runtimes/kubernetes/custom-hostnames/). ## How Self-serve, three phases per the doc: 1. Provisioner MR adding `cloudflare.custom_hostnames` (one hostname per environment) to our workload in `config/runtimes/gke/workloads.yml`; Runway approves, Atlantis creates the Cloudflare registration with TXT validation challenges. 1. Add the two TXT challenge records plus a CNAME in the owning zone via `config-mgmt`. 1. Direct access to `artifact-registry-gke.svc.gitlab.net` then returns 403 by default (can be disabled). No `.runway/` service-config changes needed. ## Status - [provisioner!1835](https://gitlab.com/gitlab-com/gl-infra/platform/runway/provisioner/-/merge_requests/1835) — registration, merged; validation tokens filled by the Runway team. - [config-mgmt!15264](https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/merge_requests/15264) — DNS records, merged and applied. - Both hostnames validated live 2026-09-03: `artifact-registry[.staging].gitlab.com` answer the service over Cloudflare with valid TLS. - [provisioner!1836](https://gitlab.com/gitlab-com/gl-infra/platform/runway/provisioner/-/merge_requests/1836) — direct-access blocking disabled during config migration (the default blocking 403'd the svc hostnames while `npm.public_registry_url` and the monolith `artifact_registry_url` still pointed at them). - Team heads-up posted in `#artifact_registry_engteam` 2026-09-03: svc hostnames keep answering during the migration and return 403 once blocking is re-enabled; switch hardcoded references to the custom domain. ## Posture (per ADR-024) ADR-024's Phase 1 architecture routes all Rails traffic to the registry through the Cloudflare edge (DDoS/WAF/rate limiting), so the monolith migrates to the custom domain too — no standing carve-out for the svc hostnames. Cloudflare `rate_limits` protect only custom-domain traffic, which is another reason the svc hostnames get blocked once nothing references them. ## Migration plan (least staging disruption: both hostnames serve until the final step) 1. [x] Staging Vault `ar-config`: `npm.public_registry_url` → `artifact-registry.staging.gitlab.com`. Verified 2026-09-03 on v1.477.0: packument `dist.tarball` URLs carry the custom domain. 1. [x] Staging monolith `artifact_registry_url` → the new hostname. MR: [k8s-workloads/gitlab-com!5805](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com/-/merge_requests/5805), merged 2026-09-07; verified end to end (all monolith calls on the custom host, zero stragglers on the svc host). 1. [x] Production twins: - npm URL: production Vault `ar-config` updated 2026-09-04 to `https://artifact-registry.gitlab.com`. The value mounts at pod boot and the then-current pod predates the write, so it is live after the next production rollout. Production has served no npm traffic yet, so there is no packument to verify against until a first package exists; nothing references the old value meanwhile. - Monolith: split per the create-then-consume advisory — [k8s-workloads/gitlab-com!5824](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com/-/merge_requests/5824) (ExternalSecret, merged) then the appConfig. The first appConfig attempt ([k8s-workloads/gitlab-com!5814](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com/-/merge_requests/5814), merged 2026-09-08) was reverted the same day ([!5826](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com/-/merge_requests/5826), [incident 13964](https://gitlab.com/gitlab-com/gl-infra/production/-/work_items/22884)): the ExternalSecret's Vault lookup failed, so ESO deleted the target secret and gprd-cny deployments wedged on it. The root cause was the ExternalSecret's key pointing at a Vault path one level off; [!5831](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com/-/merge_requests/5831) fixed the key and added `refreshPolicy: OnChange`. The reapply ([k8s-workloads/gitlab-com!5827](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com/-/merge_requests/5827)) merged 2026-09-10 after the secret was verified present in gprd-cny and gprd. 1. [x] Docs and Bruno environment references. MR: [!2290](https://gitlab.com/gitlab-org/ops/artifact-registry/-/merge_requests/2290), merged. 1. [ ] Revert !1836: [provisioner!1860](https://gitlab.com/gitlab-com/gl-infra/platform/runway/provisioner/-/merge_requests/1860) (draft) re-enables blocking in both environments; merges once the upload-limit question settles (the monolith appConfig landed 2026-09-10). The 50 GB limit reached only the workload zone — custom-hostname traffic ingresses at `gitlab.com`/`staging.gitlab.com` and stays capped at 5 GB — so the hostnames move to dedicated Cloudflare zones ([provisioner!1866](https://gitlab.com/gitlab-com/gl-infra/platform/runway/provisioner/-/merge_requests/1866) adds the mechanism; decision trail in [#1162](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/1162)). While the svc hostname is the only path taking uploads above 5 GB, blocking it would close that path; !1860 waits for the zone migration. `cloudflare.rate_limits` shipped separately ([provisioner!1861](https://gitlab.com/gitlab-com/gl-infra/platform/runway/provisioner/-/merge_requests/1861), merged) and must be re-targeted to the new zones before cutover. ## Out of scope - Per-customer subdomains; this is one canonical service domain.