Skip to main content
    Reign OpsSecure source control

    Keep source control inside the boundary you choose.

    Reign Ops operates approved self-managed source-control platforms as dedicated single-tenant instances within the agreed deployment boundary. Repositories, secrets and pipeline artifacts remain governed by that boundary while iTmethods assumes the agreed operating responsibilities, leaving your engineering team more capacity for delivery. Where Reign Gateway is included, AI coding-tool calls routed through it are evaluated against policy and recorded.

    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 deployment are supported.

    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 agreed destinations
    Gateway sits at the boundary for coding-tool interactions routed through it.
    GitHub EnterpriseServer and Cloud, operated by iTmethods GitLab Self-ManagedUltimate or Premium, operated by iTmethods Bitbucket Data CenterOperated by iTmethods
    Where your code and delivery controls run

    Deployment is one part of the source-control decision.

    Feature requirements, existing licenses, engineer familiarity and deployment needs all shape the choice. iTmethods operates supported source-control platforms as dedicated single-tenant instances in your cloud account or in infrastructure we operate, including air-gapped and sovereign deployments.

    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 reach 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.
    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.

    Platforms supported today

    We operate and support three source-control platforms.

    GitHub Enterprise, GitLab Self-Managed and Bitbucket Data Center are supported today. Scope and responsibilities are agreed for each engagement.

    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.

    Who it suits. Teams already on GitHub who need the estate inside their own boundary.
    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.

    Who it suits. Teams who want the pipeline, the registry and the scanning in one product.
    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. 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.

    Running something else? Bring the platform, version, deployment model and support requirement. iTmethods will confirm whether it fits the current service or needs a separate implementation scope. Tell us what it is →

    What Reign Ops applies on day one

    Named controls, applied at deployment.

    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.

    Audit and operational telemetry are routed to the destinations agreed for the deployment.

    Those destinations may include iTmethods operations tooling and customer systems.

    Patching runs on a cadence.

    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. The named controls, with deployment topology diagrams and sample policy excerpts. A selection is 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

    The question is not which tools. It is what they can reach.

    Copilot, Cursor, Claude Code, GitLab Duo and Atlassian Intelligence can be routed through Reign Gateway. Reign Gateway applies policy and records the model and tool interactions sent through it.

    What the boundary adds
    For each model or tool interaction sent through Gateway: 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 →

    FAQ

    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?
    Not wholesale. 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. Where platform-specific syntax or integrations differ, the assessment names what needs rework before the cut-over.
    What happens to the AI coding tools our engineers already use?
    They keep working. Where they are routed through Reign Gateway, you author the catalog of what is sanctioned, the boundary enforces it, and it records what each interaction 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 deployment are supported. 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 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 →

    Your repositories and intellectual property, your code review, branch protection and push policy, and the catalog of AI coding tools your organization sanctions are customer decisions.