Hangar: on-demand remote GitLab environments join the platform
Hangar is now a Theseus platform component. It closes a gap every modular team hits: local Caproni gives you a production-like GitLab that only you can reach, and anything remote meant hand-rolling infrastructure that nobody cleaned up. Hangar provides the layer Caproni does not own. Caproni deploys GitLab; Hangar provides an isolated place on a shared GKE host to deploy it into, keeps one tenant’s work clear of another’s, and ends the environment when its time is up. Phase 1 was delivered by Tiffany Rea, Jay McCure and Sofia Vistas.
What you get today
- Your own vcluster on the shared host. One command from a Hangar clone,
./scripts/gitlab-env.sh up <name>, creates a namespace stamped with your identity, deploys GitLab into a vcluster there, and waits until it answers. A Kyverno ownership policy keeps every other tenant out, and inside the vcluster you are cluster-admin. GitLab serves within 10 to 15 minutes. - GitLab at a stable hostname over TLS. Every environment serves
https://gitlab.<namespace>.<baseDomain>behind one shared front. The front and every API server accept only the NordLayer dedicated gateways, which is the reach model AppSec approved. There is no public endpoint. - A person or an agent, same instance. A human opens the UI; an agent calls the REST or GraphQL API. The Hangar repo ships an agent skill that drives the same script, so an agent can stand up, check and tear down an environment on request.
- An end by default. The reaper destroys an environment 24 hours after it was created. Annotate your namespace to ask for longer, up to 720 hours. Teardown leaves no LoadBalancers, volumes or disks behind.
Follow Get a remote GitLab environment with Hangar to stand one up.
Where the boundary sits
Caproni’s contract starts at “here is a reachable kubeconfig context” and ends at “the app is deployed and hot-reloadable”. Hangar owns everything needed to make that context exist, keep it safe and affordable, and make it disappear.
| Layer | Owner |
|---|---|
| Create the cluster and make it reachable | Hangar |
| Kubeconfig context | Hangar produces, Caproni consumes |
| Bundled infrastructure (cert-manager, CNPG) | Caproni |
| CNG charts and edit mode | Caproni |
| Stop or destroy the cluster | Hangar (Caproni refuses by design) |
| TTL, cleanup, quotas, cost | Hangar |
| Multi-tenant RBAC and network isolation | Hangar |
That boundary was agreed with the Caproni team: Caproni owns the vcluster capability and the rig, Hangar owns provisioning and governing environments on the host. The full reasoning is in the discovery issue.
The path forward
- Phase 1, done: engineer-triggered remote environments ( &450). A governed shared host with per-user identity, the ownership guardrail, the shared TLS front, a 24-hour TTL and reaper, and published runbooks. All five exit criteria are met: an engineer with no prior setup stood one up cold from the runbook on 2026-09-16, and two environments served GitLab behind the front at once.
- Phase 2, in progress through January 2027: fleet governance ( &463). Ownership moves from a person to a team group, so access follows group membership with no manual step. One namespace is one environment, named with the team’s prefix and capped per team in count and TTL. The fleet becomes visible: an environment registry, an orphan report when a team disbands, and cost per team. Alongside it, the AppSec guardrails: no tenant-created LoadBalancer or NodePort, a pod security baseline, resource quotas, and alerting on compute. The first modular team onboards once group ownership lands.
- Phase 3, written down and not scheduled: review environments from a merge request ( &464). A shareable, logged-in GitLab produced from an MR on request, not on every MR. CI authenticates keylessly through Workload Identity Federation, and sharing stays within the owning team.
Three honest caveats for anyone trying it this week. Access is granted by hand through an access request issue; Phase 2 removes that step. Certificates come from Let’s Encrypt staging until a team onboards, so browsers warn. And anyone on NordLayer can reach any environment, so treat yours as shared with the company, not private to you.
Start here
- Get a remote GitLab environment with Hangar: access, bring-up, the checks that matter, TTL and teardown.
- Hangar component page: the one-paragraph summary and its place on the roadmap.
- Hangar’s own docs: deploying GitLab to a remote vcluster, and the tenancy model.
- Hangar feedback: tell us how it went: one place for what confused you, what broke, and what just worked.