Self-managed GitLab, without the operational burden.
You keep the control of a self-managed instance. iTmethods carries the upgrades, the runner fleet, the backups and the security posture, and runs it to your change control as a single-tenant dedicated instance.
Keep the control. Hand over the operations.
GitLab SaaS runs in GitLab’s cloud under GitLab’s operational control. Self-managed runs in yours, which is what regulated buyers usually need.
That is the price of control, and it is the reason estates end up two minor versions behind with a runner fleet nobody wants to touch.
Nothing about the control model changes. The instance is provisioned for one customer and serves that customer only.
Version currency becomes our work rather than a ticket waiting for a quiet week. Upgrades are scheduled through your change process, at a time you agree.
Compliance pipelines, longer audit-event retention and the security dashboards are the Ultimate-only features that tend to decide it. We will scope the decision rather than assume it.
What Reign Ops applies on day one.
SAML and SCIM at the platform edge, with group and sub-group inheritance enforced rather than reimplemented.
At the GitLab edge and at the edge of the runners, so what can execute is bounded as tightly as who can sign in.
Short-lived tokens and no long-lived registration secrets. CI/CD variables managed under the same identity boundary as the platform.
To the system your security team already watches, rather than held in a console they would need a seat in.
GitLab Duo and the rest of the fleet route through Reign Gateway.
All twelve GitLab controls, with topology diagrams and sample policy excerpts. GitLab on Reign Ops hardening sheet →
Productivity multipliers, and the newest way code leaves.
GitLab Duo, Copilot, Cursor, Claude Code and the rest of the coding-agent fleet read and write your GitLab code at machine pace. Reign Gateway governs them at the call layer.
The same instance, with work arriving in it.
Reign Ops for GitLab Self-Managed is sold and operated on its own terms. Reign Factory works with GitLab, so a customer who adopts it has Factory open its pull requests on this instance, each carrying its checks and findings, with your reviewers approving every merge. What it is, and what it will not do →
What we run, what you run.
Scoped to GitLab Self-Managed, its runners and its CI/CD variables, and written down before anything is deployed.
| Who | What they hold |
|---|---|
| Reign Ops (iTmethods engineers, 24×7) | Operate GitLab Self-Managed inside your authorization boundary. Enforce your identity provider at the platform edge. Run runners isolated per environment with short-lived tokens and no long-lived registration secrets, and manage CI/CD variables under the same identity boundary as the platform. Stream the audit log to your SIEM. Patch GitLab Self-Managed and its runners on a cadence matched to GitLab’s releases. |
| Your team | Your GitLab repositories and the intellectual property in them. Code review, branch protection and push policy. The catalog of sanctioned AI coding tools, GitLab Duo among them, and approval of new integrations and policy exceptions. |
| iTmethods onboarding and review team | Stand up the initial GitLab hardening configuration, runners and CI/CD variables included. Lead the periodic posture review with your risk, security and audit functions, and operate the remediation path on what it finds. |
Questions buyers ask
What is the difference between managed and self-managed GitLab?
How does migration work?
Do you support the Ultimate tier?
Does GitLab Duo still work?
Scope your GitLab Self-Managed on Reign Ops.
Tell us where your GitLab runs today, roughly which version, and what is forcing the question. We will come back with what we would operate and what we would leave alone.