> [!NOTE] > This Description can change, use caution when reading > Latest update 2026-06-26 after https://gitlab.com/gitlab-com/gl-infra/delivery/-/work_items/22155#note_3498774545 ## Introduction GitLab is breaking its monolithic architecture into independently deployable Modular Components. Theseus and the [Component Ownership Model (COM)](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/production/component-ownership-model/) defines the paved path for building those components and required infrastructure today: versioned infrastructure-as-code, production readiness, and GitLab.com deployment via Runway. COM's current guidance covers GitLab.com deployment. The handbook [acknowledges that Cells, Dedicated, and Self-Managed require further work](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/production/component-ownership-model/#next-steps), and Theseus is designed to address all deployment targets simultaneously rather than sequentially. The challenge is that Theseus is still being built, and teams building modular services today need a deployment path before that work is complete. The [Theseus Platform Vision](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/19702) proposes extending COM through Instrumentor and per-environment Platform Bindings, and has opened important conversations about how the Cells and Dedicated deployment mechanisms should work. This issue captures those conversations, proposes a concrete path forward, and calls for alignment from the teams who need to build it. One further note worth establishing upfront: a solution that works for Dedicated inherently solves for Self-Managed, as both share the same delivery model. ## The Gap Both Theseus and COM acknowledge Cells, Dedicated, and Self-Managed as required targets for modular services. Neither currently describes how a module gets there. Theseus identifies Instrumentor and Platform Bindings as the mechanism, COM asks teams to design for forward compatibility as a review requirement, but no concrete implementation path exists for a service team to follow today. Two gaps in our current stack need to be addressed before that path can be built. The tenant model schema has no support for per-module versioning, which independent module releases require. The service deployment mechanism for Cells is also unresolved: Instrumentor and ringctl handle infrastructure provisioning, but what deploys the service itself into a Cell remains an open question. ## Proposal ### GitLab.com No change. Runway and Fairway handle this today and serve as the baseline the other environments should aim toward. ### Cells A service team builds a COM module defining what their service needs. Instrumentor provisions that infrastructure within the cell, orchestrated through ringctl and tissue as they operate today. The service deployment itself goes through `ringctl` using a new set of procedures and command for this specific purpose. To provide a bit of visibility, we'd leverage the Deployments API to write back to the project as the deployment progresses. This requires the tenant model schema to support versioning per COM module and application version, so each module can be tracked and updated independently within a cell. This also enables Instrumentor to do the heavy lifting on the Infrastructure side. ```json "modules": [ "foo": { "application_version": "1.2.3", "com_version": "3.2.1" } ] ``` ### Dedicated Dedicated deployments remain on the monolith cadence. The version of each module a Dedicated tenant runs is defined by the Release Manifest for the GitLab release they are on. Service teams do not get an independent application deployment path into Dedicated tenants. Infrastructure and Application modules are updating their associate Release Manifest which is later leveraged for the output version that Instrumentor consumes for deploying. ## Open Comments/Questions - I dislike this because now `ringctl` now has 2 distinct operational goals, I'm not sure what to do with this. - Whatcha think? ## What We Are Not Proposing - Building parallel or alternative Cells infrastructure. Instrumentor, `ringctl`, and tissue remain the provisioning and orchestration layer. This proposal works with what exists. - An independent application deployment path for service teams into Dedicated. The Release Manifest governs what Dedicated tenants run. - A replacement for Theseus. This issue addresses a specific deployment path gap while Theseus is being built, not an alternative to it. - A decision on Self-Managed. SM customers provision their own infrastructure. The application delivery model is handled through the release process and is out of scope here. ## Stakeholders The following teams need to participate in this discussion: - **Runway** - general feedback - **Cells Infrastructure** - general feedback - **Dedicated / Instrumentor / Tenant Model** - to validate the Dedicated path and confirm the tenant model schema applies equally - **Delivery / Release Platform** - filing this issue and looking to coordinate the outcome ## References - [Component Ownership Model](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/production/component-ownership-model/) - [COM: Next Steps](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/production/component-ownership-model/#next-steps) - [Theseus Platform Vision (MR !19702)](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/19702) - [Runway Phase 5: Dedicated Integration (Epic #38)](https://gitlab.com/groups/gitlab-com/gl-infra/platform/runway/-/epics/38)