Skip to content
LabBench

LabBench

Why LabBench

Every new standalone service at GitLab today reinvents the same undifferentiated plumbing: request handling, TLS, auth, health checks, connection pooling, feature flags, and observability. This slows teams down and produces inconsistent results across services.

LabBench is the composition layer that makes standing up a new modular service the easy, paved-path default. It owns the opinion and structure — the “if” — and wires together the best-in-class platform components so a developer writes business logic and gets the rest by default. LabBench does not reimplement those components.

Strategic fit

LabBench is one component of Theseus, GitLab’s initiative to modernize its production platform. It composes LabKit, Runway/Fairway, and Caproni rather than reimplementing them; see ARCHITECTURE.md for each component’s role.

The end-to-end flow:

  1. Scaffold: the bench CLI generates a working, observable service skeleton with CI, a Runway manifest, and LabKit wiring. (The Theseus CLI’s scaffolding is being merged into the bench CLI — see Roadmap.)
  2. Develop: engineers run Caproni locally against the same Kubernetes substrate and Helm charts that ship to customers.
  3. Declare: the service declares what it needs (databases, caches, storage) in a Runway manifest. No infrastructure specifics.
  4. Generate: Runway/Fairway produce per-environment Helm charts from a single definition.
  5. Ship: the same artifacts that pass CI deploy to production. Self-Managed customers receive the same charts GitLab uses internally.

The design principles, the bench/assembly/domain terminology, and the code architecture live in ARCHITECTURE.md.

Non-goals

  • Hosting, delivering, or running LabBench-built binaries in production (that is the Modular Production stream)
  • Replacing Runway (LabBench produces OCI images; Runway delivers them)
  • Replacing GDK for monolith development (Caproni replaces GDK for module development)
  • Reimplementing LabKit library features inside the chassis
  • Extracting existing Ruby from the monolith — LabBench targets new modular services (GKG, Artifact Registry, Secret Manager)
  • Building a service mesh
  • Forcing existing services to rewrite onto LabBench (migrate, then mandate)

Roadmap

LabBench’s near-term work is the service chassis (M1 in the Theseus Milestones & Metrics). Detailed milestones are tracked as work items under the Phase 1 epic.

StageFocus
Now (M1 — chassis)Per-language chassis that composes native LabKit; bench build produces a deployable OCI image; Theseus CLI scaffolding merges into the bench CLI
LaterPolyglot single-binary assembly (deferred; Panoptic’s control plane and build system are the foundation, its FFI bridges are not in M1), Rust language support parity, Self-Managed delivery path, advanced security hardening

Design documents

Design specs produced by each design milestone are stored in docs/design/.

Processes

Operational runbooks live in docs/processes/.

Decision records

Architectural decisions are recorded in docs/decisions/ as they are closed. See the decision index for the list and the record format. The full Decision Index lives in the LabBench SOA Architecture doc and is tracked in the Phase 1 epic.

Last updated on