Theseus v1: Pilot and GA
v1 lands in two milestones: Pilot on 30 October 2026 and GA on 29 January 2027. This page covers what each one includes — the environments components reach, the platform capabilities behind them, and what is out of scope.
How the platform grows
We build what real components need, in the order they need it. Artifact Registry and Orbit are first, so the platform handles the shape they have: one service, one repository, one database, one port. AutoFlow is next in the queue, and it adds requirements for service discovery and multiple concurrent dependencies (like several databases), so what it needs is what we build after AR and Orbit are served.
This is deliberate. We are not guessing at capabilities nobody is trying to use. A gap becomes work when a component requests it, which means every capability below has a named component behind it.
v1 Releases
- Pilot, October 30, 2026. Artifact Registry, which includes GATE, and Orbit run on the platform across every v1 target.
- GA, January 29, 2027. The same paths, standardized behind one configuration surface, extended to reach appliance and Omnibus customers, and grown to carry what AutoFlow needs.
Where components run
| Environment | Pilot (Oct 30, 2026) | GA (Jan 29, 2027) |
|---|---|---|
| GitLab.com | Pilot components serving production traffic | Any new Go or Rust component deploys without a platform-team MR |
| Dedicated | Pilot components deployed to tenants | Same manifest, no Dedicated-specific configuration |
| Self-Managed: OAK | Modular components delivered to Omnibus installs. Customer brings their own Kubernetes. Configuration works, and looks different from the other options | Same configuration surface as every other delivery option |
| Self-Managed: CNG with Helm | Components install as versioned chart dependencies. Each chart exposes its own values shape | Every chart takes the same values shape. Configuring a TLS certificate is identical across components |
| Self-Managed: CNG with Operator | Components managed declaratively through the Operator | A materially better interface, because the charts underneath it are now consistent |
| Self-Managed: Bridge | Not in Pilot | Beta. UI over the Operator to install, upgrade, enable, and disable components without editing YAML |
| Self-Managed: Crete | Not in Pilot | Beta. Single-node appliance install from one bootstrap command |
| Omnibus to CNG or Crete | Not in Pilot | Tested, productized migration path |
Pilot proves it works. GA makes it consistent
At Pilot each delivery option carries its own configuration surface. Artifact Registry deploys from a Fairway-generated chart. Orbit ships Helm charts it maintains itself. OAK has its own configuration. All three work, and none of them look alike, so knowing how to configure one component tells you nothing about the next.
At GA they render from the same manifest schema, and the values input is uniform. That consistency is not cosmetic. It is what makes the Operator interface tractable and Bridge worth building at all, because a UI over components that each configure differently is not a UI anyone would want.
What the platform supports
| Capability | Pilot (Oct 30, 2026) | GA (Jan 29, 2027) |
|---|---|---|
| Capability | Pilot (Oct 30, 2026) | GA (Jan 29, 2027) |
| ———- | ——————– | —————– |
| Workloads per component | One Kubernetes Deployment per generated chart | Multiple Deployments per chart |
| Database migrations | Run in-process at application startup | Dedicated migration step with run-once semantics and access to infrastructure config |
| Observability | Existing centralized metrics catalog | Metrics catalog moves into each component repository, distributed rather than centralized |
| Performance testing | Performance testing available to the pilot components | Expanded coverage |
| Contract testing | Contract tests for the pilot components | Expanded coverage |
| Configuration surface | Each component exposes its own values shape | One values shape across every generated chart |
| Chart validation | Generated charts deploy | Schema embedded in the chart, so an invalid value fails at install rather than at runtime |
| Backing store provisioning | Provisioned manually | Self-provisioned from the manifest, no provisioner MR |
| Languages | Go and Rust | Go and Rust |
Database migrations improve at GA rather than finish there. The migration step becomes a real deploy phase instead of application startup code, and further work continues past GA.
A detailed list of epics can be found on the Infrastructure and Platforms Monetization Roadmap which can be filtered by Initiative Theseus. A Theseus specific roadmap/dashboard will be developed in the future.
Who you can address
At Pilot:
- GitLab.com
- Dedicated tenants
- Self-Managed customers who already run Kubernetes — whether their GitLab install is Omnibus with OAK alongside it, or CNG managed through Helm or the Operator
GA adds:
- Customers who want an appliance instead of a Kubernetes estate, through Crete
- Customers who want to leave Omnibus, through a tested migration to CNG or Crete
- Administrators who would rather use a UI than edit custom resources, through Bridge
Upgrade and migration
Upgrading a component in place. When a customer moves from one GitLab version to the next, a modular component may need to migrate its own schema and data. At Pilot, components handle this themselves, in-process at startup. At GA it becomes a dedicated migration step the platform runs before the component starts, with the component owner supplying only the logic for their own data.
Migrating between install types. Moving from Omnibus to CNG or Crete changes how GitLab itself is deployed. Tested and productized at GA, and optional. OAK exists so that staying on Omnibus does not mean going without modular components.
Not in v1
Each of these is excluded because nothing in v1 depends on it, not because it is impossible.
- Languages beyond Go and Rust — Ruby and Python are deferred. The chassis has no Python backend and none is scoped.
- Extracting capability out of the monolith — Theseus is for new modular components. Legacy extraction is a separate track with its own cohort model, currently paused, and partly gated on Ruby support we have deliberately not built.
- Omnibus as a runtime for modular components — OAK delivers components to Omnibus installs, and the customer brings Kubernetes. Omnibus alone is not a target.
- Multi-node Crete — the appliance targets single node in v1.
- Multiple services in one binary — LabBench ships the language axis. Combining several services into a single assembly is deferred, and the cross-language measurements so far do not justify it.
- Background jobs as a platform primitive — not started, and scoped to a later phase. AutoFlow is the durable workflow engine, and job orchestration likely belongs there rather than in the chassis.