What Modulo Does With GitLab

Governance that only speaks GitHub is governance that excludes half the market, and plenty of enterprise teams run GitLab, self-managed or on GitLab.com. Modulo's GitLab connector covers the same governed-run model as GitHub.

Connect with a project token

A GitLab connector instance holds a token, a project ID, and a base branch. Write operations verify that the token actually carries the required scope before the write proceeds, so a read-only token fails with a clear scope error rather than a half-applied change. See Connectors and Secrets.

What it reads and writes

Reads cover projects, files and tree, merge requests and their changes, issues and their notes and discussions, branches, tags, and CI pipelines and jobs.

Writes cover files and batched file operations, merge requests (create, comment, approve, request approval, label, merge), and issues. Pipeline and job reads give the run visibility into what GitLab CI did with the change.

Trigger GitLab CI, read the result

A GitLab CI runner connector starts a pipeline, reads its status, and reads job logs. Wiring a pipeline node to dispatch to GitLab CI is in development.

Self-managed

The connector probes the instance version, so a self-managed GitLab deployment is a supported target. That matters for teams whose governance posture requires the whole toolchain, not just the control plane, to sit inside the estate.

Govern GitLab work from outside GitLab

In October 2026 GitLab launched what it calls the foundation for a governed software factory: agentic workflows, policy, Artifact Central, a Dependency Firewall, a scoped Secrets Manager, and an evidence chain it generates itself, all under GitLab's shared identity. GitLab governs inside GitLab, and that is a real story for a lifecycle that lives entirely inside GitLab.

A change rarely does. It touches a tracker, a second forge, a model gateway, and a deployment system besides GitLab, and each keeps its own log. The connector here is how GitLab work enters a record that spans those tools without GitLab's own controls being put in charge of anything outside GitLab: GitLab stays authoritative for GitLab, while the record of what the change actually did is cross-tool and offline-verifiable - a party holding only the export and a pre-published verification key can verify authorship, re-verify the embedded audit chain, and re-derive every derived value, without GitLab's help. A self-managed GitLab shop gets the same thing: its own GitLab instance and its own Modulo instance, both on its own infrastructure, neither depending on the other's vendor.

The argument in full - why a record generated by the platform that ran the work cannot be checked without that platform - is in Platform-generated events vs offline-verifiable evidence. For the head-to-head, see Modulo vs GitLab's governed software factory.

Where to go next

• Modulo vs GitLab's governed software factory: ecosystem-scoped vs cross-tool governance
• Platform-generated events vs offline-verifiable evidence: what the record has to satisfy to be checked without the vendor
• Connectors: GitLab and CI-runner configuration
• Govern Coding Agents Across Teams: cross-tool policy and RBAC
• Modulo With Your Existing Agent Runtimes: connecting to the CI you already run