Vision

The problem

Shipping a new modular feature at GitLab today takes weeks before a team writes a single line of business logic.

Before any code ships to production, a team must:

• Create and configure a GitLab project
• Wire up CI/CD pipelines that meet platform standards
• Register the service with Runway and generate a Helm chart
• Instrument the service with logging, metrics, and tracing that match GitLab’s observability stack
• Pass a Platform Readiness Enablement Process (PREP) assessment covering service architecture, observability, operational lifecycle, build & release, security, and more
• Set up local development with Caproni

Most of this work is identical across every service. It is invisible to customers, produces no product value, and blocks every new modular service team at the same choke points.

Mean time to production for a new modular service is measured in weeks. The goal of Theseus is to make it hours.

The north star

A developer runs bench new. They get a production-deployable service — already instrumented, already compliant, already wired into every GitLab platform concern — in the time it takes to make a coffee.

Theseus is the paved path that compresses the bootstrapping tax to near-zero. It is not a new platform. It is the glue that makes the existing platform frictionless.

How Theseus eliminates the bootstrapping tax

Bootstrapping is delivered by bench, the CLI from the LabBench project. Every service it creates starts from common-template-copier. The template encodes GitLab’s years of production learnings and ships the following on day one:

Observability (PREP: Observability category)

LabKit v2 is wired in from the first commit. Every service immediately has:

• Structured logging in the format GitLab’s ClickHouse pipeline expects
• Prometheus metrics on a standard /metrics endpoint
• Distributed tracing via OpenTelemetry, connected to the Runway OTel sidecar

An observability setup that previously required days of research and coordination is present before the team writes a line of domain code.

Deployment pipeline (PREP: Build & Release, Deployment)

runway.yml is generated with sensible defaults. The Runway provisioner MR is opened automatically. When it merges, the service is registered with the Release Platform and deployments flow through CI without manual intervention.

The CI pipeline, built on common-ci-tasks, includes:

• Container image build and signing
• goreleaser binary releases
• Chart generation via Fairway
• Security scanning
• Dependency management via Renovate

Architecture (PREP: Service Architecture)

The three-layer structure (transport → domain → store) is enforced at scaffolding time. Every service is internally consistent with every other Theseus-managed service. Reviewers can navigate any service without onboarding.

Local development (PREP: Operational Lifecycle)

caproni.yaml is included. mise run tasks cover build, test, lint, and local cluster bring-up. A new engineer can run the service locally against the same Kubernetes environment used in production on their first day.

The PREP connection

PREP (Platform Readiness Enablement Process) is GitLab’s framework for evaluating whether a service is ready for production across gitlab.com, Dedicated, and Self-Managed. It covers eleven assessment categories and has historically been a significant overhead for new service teams.

Theseus makes PREP easier by giving teams evidence rather than checklists.

A team that uses Theseus arrives at their first PREP review with most of the evidence already in place. The review becomes confirmation rather than construction.

What Theseus does not replace

Theseus handles the structural, repeatable, platform-compliance work. It does not replace:

• Product thinking — deciding what to build and for whom
• Domain design — the business logic, data model, and API contract
• Security review — threat modelling and AppSec review are service-specific
• PREP sign-off — Theseus provides evidence; platform stakeholders still review and approve

What Theseus does not operate

Theseus’s scope runs from the developer’s laptop to a deployed, operable artifact: libraries, tooling, and development environments; production-like testing locally and in CI; and, for Self-Managed customers, installation and day-2 operations automation through the GitLab Operator, Crete, and OAK.

Fleet management of GitLab’s SaaS is not part of Theseus. GitLab.com and Cells are operated by Tenant Scale; Dedicated environments by the Dedicated team. Rollout policy — rings, progressive and A/B rollouts, maintenance windows, customer upgrade groupings — is theirs. These teams orchestrate the artifacts Theseus produces; Theseus’s job is to make those artifacts uniform and safe to orchestrate. See Separation of concerns between Theseus and Cells for the full boundary.

The longer horizon

The CLI for Theseus is bench, developed in the LabBench project. It starts with scaffolding and GitLab project registration, and the roadmap extends to cover the full service lifecycle:

The north star is a world where a team spends their first day on business logic, not infrastructure ceremony.