Skip to main content
    Reign OpsSecure source control

    Your source code stays in the instance. So does everything that reads it.

    Reign Ops runs GitHub Enterprise, GitLab Self-Managed and Bitbucket Data Center as a single-tenant dedicated instance. The code, the secrets and the pipeline artifacts stay yours, and every AI coding tool that touches them passes a boundary you control.

    Available today Talk to Reign Ops engineering Deployment options →

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

    What is held in boundary
    Inside your boundary Repositories and history Secrets Pipeline artifacts None of it moves Gateway Cursor Copilot Claude Code Codex Open-weights models Recorded to your SIEM
    Everything that reads the code comes to the boundary. The code never leaves it.
    GitHub EnterpriseServer and Cloud, operated by iTmethods GitLab Self-ManagedUltimate or Premium, operated by iTmethods Bitbucket Data CenterOperated by iTmethods
    The decision you are actually making

    Where the code lives matters more than the feature set.

    Every source-control platform in this market has the features. The question underneath the evaluation is a different one, and it is answered by the deployment model rather than the product.

    01What the repository holds
    Every secret, every architecture decision, every business rule, and every prompt a coding assistant has ever been issued.

    A breach at that layer is not a breach of a tool. Hardening the substrate stopped being an engineering decision when it became the operating context of the institution.

    02What reads it now
    EngineersCoding agentsCI pipelinesSecurity scannersDependency bots
    All of them read and write the same substrate, at machine pace.

    Each one is a distinct identity that has to be accounted for.

    03Whose posture it carries
    Outside your authorization boundary it is exposed by the platform vendor’s security posture rather than by yours, and you cannot audit what you cannot reach.

    Hardening inside the boundary is the only version of this that survives a bad quarter at a vendor you do not control.

    04The usual price of that control
    Operating it yourself.

    That is the tradeoff this page exists to remove. You keep the control of a self-managed instance; iTmethods carries the operations.

    Lands on your platform team
    UpgradesRunner fleetBackupsSecurity postureAudit trail
    Reign Ops Operated by iTmethods, inside your boundary

    iTmethods does not custody customer code, secrets or pipeline artifacts. The substrate is operated by iTmethods. The artifacts are owned by the customer.

    Pick your platform

    Three supported platforms. One operating model.

    The operating posture does not change with the platform. What changes is what your engineers already know and what your licenses already cover.

    GitHub

    GitHub Enterprise

    GitHub Enterprise Server, operated as a single-tenant dedicated instance inside your authorization boundary. Actions runners isolated per environment with short-lived OIDC tokens, and branch protection applied as policy-as-code rather than as settings somebody remembered to tick.

    Who it suits. Teams already on GitHub who need the estate inside their own boundary without retraining anybody.
    Available today Managed GitHub Enterprise →
    GitLab

    GitLab Self-Managed

    GitLab Ultimate or Premium, operated as a single-tenant dedicated instance against your own identity provider. Runners isolated per environment, CI/CD variables under the same identity boundary as the platform, and branch and push controls as policy-as-code.

    Who it suits. Buyers who want the pipeline, the registry and the scanning in one product, and whose risk function wants compliance pipelines.
    Available today Managed GitLab →
    Bitbucket

    Bitbucket Data Center

    Bitbucket Data Center, operated as a single-tenant dedicated instance alongside the rest of an Atlassian estate under one operating model. Atlassian preserved Bitbucket Data Center in its published Data Center plans while other products moved.

    Who it suits. Atlassian estates staying self-hosted, and teams who want source control to sit next to the tracker rather than away from it.
    Available today Managed Bitbucket Data Center →

    One operating model across all three: your identity provider at the platform edge, runners isolated per environment, the audit log streamed to your SIEM, and patching on a cadence matched to upstream releases. Running something else? Tell us what it is →

    What Reign Ops applies on day one

    Policy as code, not manual setup.

    These are applied at deployment rather than negotiated afterwards, and each one is configuration under version control rather than a setting somebody remembered to tick.

    The identity boundary is yours.

    Your identity provider at the platform edge, on the protocol you already run. Group and sub-group inheritance enforced rather than reimplemented.

    Runners are isolated per environment.

    Short-lived tokens, no long-lived registration secrets, and no shared execution surface between environments that are not supposed to see each other.

    The audit log goes to your SIEM.

    Streamed to the system your security team already watches, rather than held in a console they would have to be given a seat in.

    Patching is a cadence, not a ticket.

    Substrate, runner fleet and dependencies, on a cadence matched to upstream releases. Version currency is our work rather than something waiting for a quiet week.

    The full control set is published. Twelve named controls, each policy-as-code, with framework mapping, deployment topology diagrams and sample policy excerpts. Five are summarized on each platform page; the complete deliverable is the hardening sheet. How we handle security questionnaires →

    iTmethods makes no compliance, certification or accreditation claim under any framework. What each framework asks for, and the limits on what any supplier can tell you about your own position, is set out on regulatory alignment.

    The AI coding tools

    Your engineers already adopted them. The question is what they can reach.

    Copilot, Cursor, Claude Code, GitLab Duo, Atlassian Intelligence and whatever ships next all read and write the same substrate. 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
    For each call: the identity that made it, the policy that applied, the decision taken, the model that answered, and the time it happened. Applied at the point the call is made rather than asserted in a document beside it. 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. It means a reviewer can reconstruct what an agent asked for, what it was allowed, and what came back — on the same substrate as the code it touched. How the boundary works →
    Where Reign Factory fits

    The same substrate, 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 on this page. But the two were designed to meet here, and this is where that is most concrete.

    What Factory does against a governed source-control instance. It works an item you assign in an isolated environment, with Reign Gateway on the model path, and opens a merge request in your repository 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 →

    The Factory relationship is stated in the present tense here because the merge request lands in the platform this page is about. That is the test the band has to pass on any Reign Ops page, and it is the only thing that earns the present tense.

    Shared responsibility

    What we run, what you run.

    Written down before anything is deployed, so the boundary is a document rather than a discovery.

    WhoWhat they holdExamples
    Reign Ops, automated Decisions closed inside the substrate without human intervention: the runtime, the identity boundary, the network policy and the audit logging. Operate the substrate inside your authorization boundary. Enforce your identity provider at the platform edge. Isolate runners per environment. Stream audit logs to your SIEM. Apply hardening as policy-as-code. Patch on an upstream-matched cadence.
    Customer authored Decisions you own under the shared-responsibility model. You are the author here rather than the approver. Your repositories and intellectual property. Code review policy, branch protection and push policy. The catalog of AI coding tools the organization sanctions. Which evaluators apply to which population.
    Operating partner engagement The work that needs a named engineer rather than a runbook, done with your team rather than to it. Migration scoping and phased cut-over. Authoring the first set of evaluators. The periodic hardening review. The decisions that change the design rather than the configuration.
    Before the scoping call

    The questions that arrive every time.

    Where does the code actually live?
    In a single-tenant dedicated instance inside your authorization boundary — your own AWS or Azure cloud account, or infrastructure iTmethods operates. iTmethods operates that substrate and does not custody your code, your secrets or your pipeline artifacts. There is no multi-tenant or shared option, and there is no tier of this where your code sits alongside somebody else's.
    Does moving platform mean re-platforming the pipelines?
    No. A scoped readiness assessment inventories projects, groups, variables and runners and sizes the migration, then a phased cut-over lands the estate on the new substrate. Group and sub-group inheritance is preserved across the move, and pipelines are not rewritten mid-flight.
    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.
    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. Deployment options states which is which without softening any of them.
    Can we see the controls before we commit to anything?
    Yes. Each platform page carries five of the twelve controls in full, and the hardening sheet for that platform 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 SOC 2 Type II on Reign Ops
    AWS Advanced Tier Services Partner and Validated Managed Service Provider. Twenty-one years operating critical infrastructure for regulated enterprises.
    Next step

    Tell us where your source control runs today.

    Which platform, roughly which version, and what is forcing the question. We will come back with what we would operate, what stays with your team, and what we would leave alone.

    Talk to Reign Ops engineering Back to Reign Ops →