Forge is deployed inside an environment with no external network egress. There are no outbound calls to gitlab.com and no external runtime dependencies. Updates, packages, and runner images arrive through a controlled inbound path you own rather than over the public internet.
FORGE · SOVEREIGN DEVOPS
Air-Gapped GitLab for CUI and Sovereign Engineering
Air-gapped and customer-cloud deployments for engineering work with handling constraints attached. Self-hosted GitLab operated with audit-grade controls, inside your trust boundary.
SOC 2 Type II · Linux Foundation · FINOS · 21 years regulated · AWS Advanced TierThe Linux Foundation, FINOS, and the Agentic AI Foundation.
ProofSOC 2 Type II since 2018·21 years of regulated infrastructure·AWS Advanced Tier and Validated MSP·Linux Foundation member participating in FINOS
Built on open foundations
Member and contributor in the open standards behind governed AI. The Linux Foundation, FINOS, and the Agentic AI Foundation.
THE CONSTRAINT
The platform has to come to the boundary, not the other way around
Most managed DevOps offerings assume outbound internet, a vendor-run control plane, and telemetry leaving your environment. For programmes handling controlled unclassified information, export-controlled work, or sovereign data, those assumptions are the disqualifier rather than a detail to negotiate. The usual fallback is to self-host and absorb the entire operational burden internally.
Self-host and absorb it
Your platform team carries the upgrades, the runner fleet, the backups, and the audit trail, on top of the mission work they were hired for.
Operated inside the boundary
Forge engineers run the substrate where it sits, under your identity boundary and your egress rules, with the evidence streamed to your SIEM.
DEPLOYMENT POSTURES
Two postures for sovereign work
The control plane, audit trail, and policy enforcement do not change between them. Only the boundary does, which means changing posture later is not a rebuild of your controls.
Air-gapped
No external network egress
Deployed inside an environment with no outbound path to the public internet. No calls to gitlab.com, no external runtime dependencies. Updates and runner images arrive through a controlled inbound path you own.
- ·Runs entirely on your infrastructure
- ·Complete data sovereignty
- ·No external dependencies at runtime
- ·Full audit trail retained inside the boundary
Customer cloud
Your AWS, Azure, or GCP account
Deployed inside your own cloud account, in your VPC or VNet, under your billing and contracts. Data never leaves your account. Forge operates the substrate inside that boundary.
- ·Deployed in your VPC or VNet
- ·Your cloud billing and contracts
- ·Data never leaves your account
- ·Custom networking and security controls
AUDIT-GRADE CONTROLS
What Forge applies inside the boundary
Applied as policy-as-code from day one rather than configured by hand per environment.
- 01SAML and SCIM identity boundary, with group and sub-group inheritance enforced.
- 02IP allow-listing at the platform edge and the runner edge.
- 03Runners isolated per environment. Short-lived tokens. No long-lived registration.
- 04Platform audit log streamed to the customer's SIEM, and to the Reign Audit Ledger (CAVR) where Reign is in use.
- 05Patch cadence, backup and disaster recovery, and substrate security run on a continuous-remediation SLA.
Scope a sovereign deployment
A working session with Forge engineering on your egress rules, your handling obligations, and the deployment posture that fits them.
Request a Sovereign Deployment BriefingFAQ
Frequently asked questions
BRIEFING
Request a Sovereign Deployment Briefing
Talk to Forge engineering.
Tell us the constraints you are operating under and we will scope the deployment posture that fits.
Your information is handled per the iTmethods Privacy Policy.