The core contract
Theseus enforces one architectural boundary: the separation of what software needs from how infrastructure provides it.
Developers declare requirements. A service says “I need a PostgreSQL-compatible database, a key-value store, and object storage.” It never specifies which instance, where it runs, or how to connect.
Operators satisfy requirements. They define the infrastructure that exists and how services bind to it. Whether six services share one database or each gets its own is an operator decision, not an application decision.
This separation holds across every environment. A developer’s laptop and GitLab.com production consume the same service declarations and differ only in how dependencies are satisfied.
Where the scope ends
The same boundary defines what Theseus is responsible for. In scope is everything from the developer’s laptop to a deployed, operable artifact:
- Libraries, tooling, and development environments — LabKit, the
benchCLI, project scaffolding, and Caproni. - Production-like testing — the same environment shape locally and in CI, so services are exercised the way they run.
- Self-Managed installation and day-2 operations — the GitLab Operator, Crete, and OAK install and operate Theseus artifacts on customer infrastructure.
Out of scope is fleet management of GitLab’s SaaS. Rollout rings, progressive and A/B rollouts, maintenance windows, and decisions about which customers upgrade when belong to the teams that operate the fleet — Tenant Scale for GitLab.com and Cells, the Dedicated team for Dedicated. Those teams orchestrate the artifacts Theseus produces; the artifacts themselves are identical however the fleet is walked.
How each environment satisfies those declarations is the subject of Platform bindings.