Platform bindings

This page summarises section 4 of the Theseus Platform Vision design document, which remains the authoritative source.

Theseus delivers a single platform through which application services reach GitLab.com, Cells, Dedicated, Dedicated for Government, and Self-Managed. Rather than one backend that targets every environment, each deployment target gets a Platform Binding: a backend that translates the platform’s common abstraction into the concrete provisioning, packaging, and orchestration of that target.

One interface, many bindings

Every service declares its needs once, in a Fairway manifest (see The core contract). The manifest names abstract dependencies — postgresql, redis, object_storage_bucket — and each binding decides how to satisfy them. In one environment a logical database lands in a shared physical instance; in another it becomes a dedicated RDS instance. Application teams write the same code for every binding.

The planned bindings:

See the target matrix for the complete tenancy and orchestration breakdown.

The Enterprise Platform Binding

The Enterprise binding hosts services that don’t belong to any single tenant or Cell. It is intended primarily for GitLab Inc operational services — for example customers.gitlab.com, license generation, billing aggregation, and internal data pipelines that span all tenants. These services exist alongside the product rather than inside it, and the binding is never shipped to customers: there is no Self-Managed counterpart by design.

Like every binding, Enterprise services declare a Fairway manifest with abstract dependencies; the binding resolves them against GitLab-Inc-operated infrastructure such as CloudSQL, GCS, and Memorystore. Teams writing for the Enterprise binding write the same code they would write for any other.

Operating above the tenant carries one hard architectural requirement:

Enterprise-binding services must have no synchronous dependency on the GitLab application, or on other modular components running in Cells.

Calling the GitLab API on the hot path, or relying on application authorization to make decisions at request time, disqualifies a service from this binding. The guideline: any single Cell could go offline for an extended period — days, conceivably longer — and Enterprise-deployed components must remain available. Regional infrastructure at even the largest cloud providers can be degraded for weeks; a component on the Enterprise binding that hard-depends on a single Cell inherits that Cell’s blast radius. Operating above the tenant means surviving above the tenant.

Isolation boundaries

Cells are the building block of all regional deployments of the GitLab.com SAAS — a Cell may contain a copy of a modular component, a GitLab instance, or both. To decide between the Enterprise binding and a Cellular deployment:

If the service has synchronous dependencies on Cell infrastructure, or could go down when one Cell goes down, it isn’t an Enterprise service.

The Cell is the primary isolation boundary for all modular services. Components in the same Cell can be tightly coupled; components in different Cells should be loosely coupled and communicate asynchronously, so a Cell-level failure stays contained inside that Cell. With the exception of a small number of global services (Auth being the canonical example), modules rely on the Cell as their isolation boundary rather than forming arbitrary networks of inter-Cell dependencies.

A useful side effect: single-tenant environments stop being a special case. A service built for one Cell inside the SAAS bundle deploys unchanged to an environment where that Cell is the customer. The full pattern will be covered in Cellular architecture.