Skip to main content
    Meet us at Open Source in Finance Forum (OSFF) New York, Convene Brookfield Place, November 4 to 5.Book a meeting
    Book a briefing

    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.

    The tradeoff

    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.

    01What self-managed usually costs you
    Operating it yourself.

    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.

    Lands on your platform team
    UpgradesRunner fleetBackupsSecurity postureAudit trail
    Reign Ops Operated by iTmethods, inside your boundary
    02What you keep
    A single-tenant dedicated instance, your identity provider, your repositories, your policy.

    Nothing about the control model changes. The instance is provisioned for one customer and serves that customer only.

    03What we carry
    Patch cadence, backup and disaster recovery, runner isolation, and the security posture of the substrate.

    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.

    04Which license tier
    Ultimate is the usual answer for regulated buyers; Premium fits where the Ultimate feature set is not needed.

    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.

    Deployment
    One dedicated GitLab Self-Managed instance. Groups, sub-groups and runners sit on it, in infrastructure iTmethods operates or in your own AWS or Azure account. Deployment options →
    The hardening sheet

    What Reign Ops applies on day one.

    Identity boundary bound to your provider.

    SAML and SCIM at the platform edge, with group and sub-group inheritance enforced rather than reimplemented.

    Allow-listing at both edges.

    At the GitLab edge and at the edge of the runners, so what can execute is bounded as tightly as who can sign in.

    Runners isolated per environment.

    Short-lived tokens and no long-lived registration secrets. CI/CD variables managed under the same identity boundary as the platform.

    Audit log streamed to your SIEM.

    To the system your security team already watches, rather than held in a console they would need a seat in.

    AI coding tools governed at the call layer.

    GitLab Duo and the rest of the fleet route through Reign Gateway.

    And six more.
    Code scanningBranch protectionApproved-model registryData classificationEgress controlsBackup and disaster recovery

    All twelve GitLab controls, with topology diagrams and sample policy excerpts. GitLab on Reign Ops hardening sheet →

    The AI coding tools

    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 part worth being precise about. This governs the coding tools your own engineers run against GitLab, GitLab Duo included, for calls sent through Reign Gateway. It is not a claim that those tools are safe, and it does not make an unapproved model approved. Beyond SOC 2 Type II for Reign Ops, no other certification or accreditation is claimed. What the boundary records → · How the boundary works → · Regulatory alignment →
    Where Reign Factory fits

    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 →

    Shared responsibility

    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.

    WhoWhat 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.
    FAQ

    Questions buyers ask

    What is the difference between managed and self-managed GitLab?
    GitLab SaaS runs in GitLab’s cloud under GitLab’s operational control. Self-managed runs as a single-tenant dedicated instance, which is what regulated buyers usually need, and it normally means carrying the operations yourself. Reign Ops removes that tradeoff: the instance is self-managed and yours, and we operate the substrate, the runners, the upgrades, the backups and the security.
    How does migration work?
    A scoped readiness assessment sizes it: an inventory of projects, groups, sub-groups, CI/CD variables and runners, then a gap analysis against your regulatory surface, then a phased cut-over with the governed posture live on the new substrate from day one. Group and sub-group inheritance is preserved across the move and pipelines are not rewritten mid-flight.
    Do you support the Ultimate tier?
    Yes, and it is the usual answer for regulated buyers. The Ultimate-only features (compliance pipelines, longer audit-event retention, the security dashboards) line up with the evidence cadence regulated enterprises need. Premium fits earlier-stage organizations or workloads where that feature set is not needed.
    Does GitLab Duo still work?
    Yes. GitLab Duo and the other AI coding tools your engineers already use keep working, and they route through Reign Gateway at the call layer. You author the catalog of what is sanctioned; the boundary enforces it and records what each call asked for, what applied to it and what came back. Nothing here requires your engineers to change tools.
    Next step

    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.