Managed GitHub Enterprise, inside your own boundary.
GitHub Enterprise Server deployed inside your authorization boundary and operated as a single-tenant dedicated instance. iTmethods runs the substrate. Reign Gateway governs Copilot and the rest of the coding-agent fleet at the call layer.
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.
Enterprise Server, and who actually operates it.
Most GitHub estates that need to move do not need to change product. They need the same product somewhere else, run by someone whose job it is.
That matters more than it sounds. The usual reason a source-control migration fails is not the migration, it is the retraining that follows it.
Code outside the boundary carries someone else's security posture. Inside it, the posture is yours and it can be audited by your own people.
Isolated per environment, short-lived OIDC tokens, no long-lived registration secrets, and no shared execution surface between environments that should not see each other.
You do not have to remove them. You have to be able to say what they reached, under what policy, and when.
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.
| Shape | What it is | Status |
|---|---|---|
| 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 |
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.
SAML or OIDC at the platform edge, on the protocol you already run, with SCIM where you use it.
At the platform edge and at the runner edge, so the execution surface is bounded as tightly as the console is.
Short-lived OIDC tokens, no long-lived registration secrets, and no shared execution surface between environments.
The GitHub audit log goes to the system your security team already watches rather than staying in a console.
Copilot and the rest of the fleet route through Reign Gateway. The section below is what that means in practice.
Plus a periodic hardening review with your team.
The complete control set, with framework mapping and sample policy excerpts. GitHub on Reign Ops hardening sheet →
Productivity multipliers, and the newest way code leaves.
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.
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 we run, what you run.
Scoped to GitHub Enterprise, and written down before anything is deployed, so the boundary is a document rather than a discovery.
| Who | What they hold |
|---|---|
| Reign Ops, automated | Operate GitHub Enterprise inside your authorization boundary. Enforce your identity provider at the platform edge. Run Actions runners isolated per environment with short-lived OIDC tokens and no long-lived secrets. 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 GitHub Enterprise 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. |
The questions that arrive every time.
How do we move from GitHub.com to Enterprise Server?
Does Copilot still work?
What about Advanced Security?
Which deployment shapes can we have?
What happens to the AI coding tools our engineers already use?
Can we see the controls before committing to anything?
Scope your GitHub Enterprise on Reign Ops.
Tell us where your GitHub runs today, roughly how many organizations and repositories, and what is forcing the question. We will come back with what we would operate and what we would leave alone.