Skip to main content
    Reign OpsSource controlGitLab

    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.

    Available today Talk to Reign Ops engineering The hardening sheet →

    Delivered as a single-tenant dedicated instance, in your own AWS or Azure cloud account or in infrastructure iTmethods operates. Both are available today. Google Cloud is planned for 2027. Air-gapped and sovereign are in development.

    The tradeoff

    The choice you should not have to make.

    GitLab SaaS runs in GitLab's cloud under GitLab's operational control. Self-managed runs in yours, which is what regulated buyers usually need — and it normally means carrying the operations yourself.

    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

    Two shapes. One operating posture.

    The governed posture does not change when the shape does. What changes is where the substrate sits, and only one of the two is something you can have today.

    ShapeWhat it isStatus
    Single-tenant dedicated instance, in our environment Provisioned for one customer and serving that customer only, in infrastructure iTmethods operates. Your identity provider, your repositories, your policy, our operations. Available today
    Single-tenant dedicated instance, in your own cloud account The same instance, provisioned in your own AWS or Azure account. The account is yours and the billing relationship with the cloud provider is yours. Google Cloud is planned for 2027. Available today
    Air-gapped and sovereign Air-gapped deployment and sovereign deployment. Two shapes, in development together. In development
    Neither of the two in development is available, neither is being sold, and we are not offering a date. There is no multi-tenant or shared option at any tier. Deployment options states which is which →
    The hardening sheet

    What Reign Ops applies on day one.

    Twelve named controls, each policy-as-code rather than manual configuration. Five are below. The full deliverable, with framework mapping, topology diagrams and sample policy excerpts, is the hardening sheet.

    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 platform edge and at the runner edge, so the execution surface is bounded as tightly as the console is.

    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. The section below is what that means in practice.

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

    Plus a periodic hardening review with your team.

    The complete control set, with framework mapping 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 source code at machine pace. Reign Gateway governs them at the call layer, which is the one place a policy can apply to all of them at once, whoever built them.

    What the boundary adds
    Every call routed through Reign Gateway: identity-bound, content-classified, and policy-enforced before the model sees the code. For each one the record carries the identity that made it, the policy that applied, the decision taken, the model that answered and the time it happened. You author the catalog of tools the organization sanctions; the boundary enforces it.
    The part worth being precise about. This governs the coding tools your own engineers run. It is not a claim that those tools are safe, and it does not make an unapproved model approved. iTmethods makes no compliance, certification or accreditation claim under any framework. How the boundary works → · Regulatory alignment →
    Where Reign Factory fits

    The same instance, with work arriving in it.

    Reign Ops is sold and operated on its own terms, and a customer who never adopts Reign Factory loses nothing here. But this is the platform Factory hands work to.

    What Factory does against a governed GitLab Self-Managed. It works an item you assign in an isolated environment, with Reign Gateway on the model path, and opens a merge request in your GitLab project carrying its checks and findings. Your pipeline, your reviewers and your release process are unchanged and still decide what ships.
    What it does not do. It does not merge and it does not release. Autonomy is off by default and is turned on per population, by you, in writing. Reign Factory is being productized toward commercial availability rather than generally available today. What it is, and what it will not do →
    Shared responsibility

    What we run, what you run.

    Scoped to GitLab Self-Managed, and written down before anything is deployed, so the boundary is a document rather than a discovery.

    WhoWhat they hold
    Reign Ops, automated 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. Apply hardening as policy-as-code. Patch the substrate and the runner fleet on a cadence matched to upstream releases.
    Customer authored Your repositories and intellectual property. Code review policy, branch protection and push policy. The catalog of AI coding tools the organization sanctions. Approval of the evaluators authored during the on-ramp, and of new tool integrations and policy exceptions as they are surfaced.
    Operating partner engagement Stand up the initial hardening configuration. Author the first set of evaluators against your GitLab Self-Managed surface. Operate the remediation path on what those evaluators find. Lead the periodic posture review with your risk, security and audit functions, and train your teams to author their own evaluators.
    Before the scoping call

    The questions that arrive every time.

    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.
    Which deployment shapes can we have?
    A single-tenant dedicated instance, in your own AWS or Azure cloud account or in infrastructure iTmethods operates. Both are available today and both are single tenant. Google Cloud is planned for 2027. Air-gapped and sovereign are in development. There is no multi-tenant or shared option at any tier.
    What happens to the AI coding tools our engineers already use?
    They 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.
    Can we see the controls before committing to anything?
    Yes. Five of the twelve are on this page in full, and the hardening sheet carries all twelve with framework mapping and sample policy excerpts. Nothing on this page needs a conversation before you can read it.
    AWS Advanced Tier Services Partner
    AWS Advanced Tier Services Partner and Validated Managed Service Provider. Twenty-one years operating critical infrastructure for regulated enterprises.
    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.

    Talk to Reign Ops engineering The hardening sheet →