Decision: AutoFlow onboards to Theseus within today's platform constraints

The AutoFlow team is onboarding to Theseus. Their requirements are among the most demanding the platform has taken on — and the agreement below is about what ships now on today’s platform, versus what waits for the platform to grow.

Context

AutoFlow came to Theseus with one hard requirement:

• Database scale-out. Complex, performance-driven needs around scaling out physical database instances to partition workloads across.

Separately, Artifact Registry depends on AutoFlow for its GA release: lifecycle policies will run as AutoFlow workflows. Artifact Registry’s GA is January 2027 and covers GitLab.com, self-managed CNG and Dedicated together, so AutoFlow has to be in production on all three by then.

The agreement

After conversations with Timo, the initial version of AutoFlow onboards to Theseus on these terms:

• Kubernetes-only is accepted. AutoFlow accepts that Theseus targets the deployment environments outlined in Where components run. Artifact Registry, AutoFlow’s first consumer, is itself Kubernetes-only (AR CTO review, 2026-10-02), so accepting it costs AutoFlow nothing for now.
• Multi-port doesn’t need to land for AutoFlow. The AutoFlow-only Relay fits Fairway’s one main port plus metrics. Multi-port becomes a hard requirement only if the rest of Relay moves to Theseus or AutoFlow adopts remote modules; AutoFlow accepts the current state on the condition that it is delivered eventually (runway/team#1000).
• A single database instance for now. AutoFlow limits its physical database needs to one instance with a single logical database, conforming to the constraints of the Theseus platform as it stands today. This constrains physical instances, not connection shapes: the database keeps both a pooled and a direct (non-pooled) DSN from the infrastructure contract — the direct endpoint exists precisely for paths that transaction pooling breaks, such as migrations holding session advisory locks ( labkit!692).
• Deployment-based scale-out later. When AutoFlow needs another physical database instance, the team provisions it through the Runway provisioner on GitLab.com, then wires it into the application as a named service in the Fairway manifest. The next rollout renders the new instance into the infrastructure contract and rolls the pods. AutoFlow registers the new database live (autocorectl central db add) and pins existing workflows to their current database, so a rollout adds capacity and moves no data.
• Service-to-service auth is Kubernetes identity. Services on the path (Trigger, AutoFlow, Catalog, Artifact Registry) authenticate to each other with their pod identities and carry the acting principal through an auth-owned library (trigger!10). No shared secrets, and Rails is not involved when a workflow runs. What AutoFlow needs from Theseus: pod identity tokens per audience mounted in every pod (fairway#93).
• Observability. Runway does not run Metropolis, so on GitLab.com AutoFlow’s SLIs, dashboards and alerts come from the runbooks metrics catalog like every other Runway service. The same definitions ship in the chart as Metropolis resources for caproni, Dedicated and self-managed CNG.
• Security fixes deploy from Relay’s security mirror. release-tools owns Relay’s version tags, so the Release Framework does not apply. A fix merged in the mirror is built there and deployed to each Relay-hosted Theseus service when its owner chooses, independent of the monolith’s release. What AutoFlow needs from Theseus: the Runway deployment project accepts builds from the security mirror.

Facilitation is under way

Theseus is helping build the single-database-instance support AutoFlow needs. The work is tracked in AutoFlow on Theseus and spans LabKit, Relay and caproni.

What this means

Theseus is not a blocker for AutoFlow getting to production, and so not a blocker for Artifact Registry’s GA.

Everything on AutoFlow’s platform path is agreed and scoped to today’s constraints. Three platform items are open: pod identity tokens (fairway#93), Runway deployments from the security mirror, and Metropolis on caproni (gitlab-caproni!94).