Operate the engineering platform your teams depend on.
iTmethods operates engineering tools and open-source platforms as a dedicated service under the customer’s identity, access and change requirements. Reign Ops takes on the planned maintenance, monitoring, incident response and lifecycle work in scope, separating platform operations from the customer’s product-delivery backlog.
Keep platform work from competing with software delivery.
Reign Ops handles planned maintenance, monitoring, incident response and lifecycle work across your tools, under agreed responsibilities and service levels.
What the work changed for each customer.
Build capacity the bank’s own teams can use
Apple-silicon build capacity on AWS had been stood up by hand whenever it was needed. The engagement turned that one-off setup into a repeatable, automated framework on the bank’s existing CloudBees CI. Its own teams now use the framework without a specialist in the room.
Four tools, one service level and one trail
Four engineering tools had meant four upgrade cycles, four access models and four places to look when something failed. CloudBees CI, GitLab, SonarQube and JFrog now run on one managed AWS EKS runtime, with workloads separated and one service level and one trail across all four. Production continued throughout the migration.
Both accounts are anonymised and describe one engagement each. What changed in those environments is specific to them.
The work Reign Ops takes on, and the decisions customers keep.
Operating scope is agreed per platform. Reign Ops runs the service work in scope; the customer retains the repositories, priorities, approvals and delivery decisions.
| Service area | Reign Ops operating scope | Customer decision and control |
|---|---|---|
| Source control and build | Operate GitHub Enterprise Server, GitLab Self-Managed or Bitbucket Data Center as a single-tenant dedicated instance. Maintain the baseline, authentication, permissions, runners and network exposure. | Repositories, branching, review and where builds run. The comparison and baseline → |
| Lifecycle and open source | Maintain the record of components and versions in use, plan patches and upgrades, and handle operating questions when a change affects behavior. | Priority, schedule and acceptance for each change. |
| Availability and recovery | Run monitoring, incident response, escalation, backup and recovery against the coverage and service measures agreed for the platform. | Business priorities, recovery requirements and escalation authority. |
| AI platform | Operate agent runtimes, MCP and tool connections, and the model-access layer engineers build on. The AI substrate → | Which agents run and what they may reach. Reign Gateway applies policy at the model boundary. |
| Cost and capacity | Attribute cloud and model spend, review capacity, implement approved actions and track their effect against the agreed baseline. No savings figure is promised before the work is measured. | Priorities, acceptable tradeoffs and approval of cost or capacity changes. |
| Change and record | Prepare the proposal, schedule and change record, including privileged access, incidents and exceptions in the agreed system of record. | Approval through the customer’s existing change process. |
Source control and code
The AI substrate
Platform, cost and change
FAQ
What is Reign Ops?
Reign Ops is the Operate motion of Reign. Available today. iTmethods runs the delivery toolchain for regulated enterprises, including source control, build, artifact management and code quality, as one managed environment with change control, access control and a recorded history of who did what and when. Deployment is a single-tenant dedicated instance. Governance of model access sits in a separate motion, Reign Gateway, which is also available today. Reign Ops is an operating service, not a compliance outcome. Whether your obligations are met is a determination for your own risk and quality functions.
Do the four Reign motions work together?
Yes, and each one stands on its own. Reign Ops operates the delivery platform and is Available today. Reign Gateway governs what crosses to a model and is Available today. Reign Factory builds, is Available · Beta Release, and is not generally available; beta access is agreed with us. Reign Assurance is in Co-design development, on scope agreed per engagement. Where more than one motion is in place the records line up: the Gateway records the model boundary crossing, Ops records the change and the approval, and one population of work can be followed from request to merge. Adopting one motion does not commit you to another, and no motion is available because another one is.
Where can Reign Ops run?
A Reign Ops instance is single-tenant and can run in infrastructure iTmethods operates, in your AWS or Azure account, as an air-gapped deployment, or under sovereign deployment requirements. Each instance has its own application tier, database and workload plane. Google Cloud is planned for 2027.
Let’s discuss the platforms and tools your engineers depend on.
Bring the priorities, tools and operating issues you want to discuss. We can compare them with the Reign Ops scope and decide whether a deeper working session makes sense.