FORGE · MANAGED GITLAB SELF-MANAGED
Managed GitLab Self-Managed. Inside your trust boundary. Hardened, governed, Reign-ready.
GitLab Ultimate or GitLab Self-Managed Premium deployed inside the customer's authorization boundary. Forge runs the substrate. Reign governs every AI coding tool that touches the code. Continuous assurance of every read and every write.
DEPLOYMENT OPTIONS
Three deployment shapes. Sovereign-friendly by default.
GitLab Self-Managed leads with the air-gapped and sovereign-friendly posture. Forge runs the substrate in the topology your data residency and authorization boundary require.
GitLab Self-Managed in Customer Cloud
Your AWS, Azure, or GCP account. Your VPC. Forge operates the substrate. GitLab Ultimate or Premium configured to your group and sub-group inheritance pattern. Default posture for organizations standardizing on a single hyperscaler.
GitLab Self-Managed in sovereign on-prem or hybrid
On-prem in the customer's data center, or hybrid topology spanning on-prem and cloud. Forge operates inside the customer's authorization boundary. For organizations with data residency, sovereign cloud, or in-country processing mandates.
GitLab Self-Managed in air-gapped FIPS 140-2 Level 3 deployment
Defense, classified, and sovereign-national programs. Fully air-gapped. ITAR, NIST 800-171, and CMMC alignment. No outbound calls to gitlab.com. The substrate stays entirely inside the customer's authorization boundary.
THE HARDENING SHEET
What Forge applies on day one.
Twelve named controls, GitLab-specific. Each is policy-as-code, not manual configuration. The full deliverable lives in the gated hardening sheet PDF.
- 01SAML or SCIM identity boundary, group and sub-group inheritance enforced.
- 02IP restrictions at the GitLab Ultimate group level and at the Forge edge.
- 03GitLab Runners isolated per environment, short-lived JWT tokens, no long-lived runner registration tokens.
- 04Secure Code Scanning (SAST, DAST, IaC scanning) enabled by default. Dependency Scanning. Container Scanning.
- 05Push rules and protected branches enforced via policy-as-code.
- 06Audit Events streamed to the customer's SIEM and to the Reign Audit Ledger (CAVR).
- 07GitLab Duo and any third-party AI coding tools governed through the Reign AI Gateway.
- 08Approved-model registry for the coding-agent LLM fleet.
- 09Project and group classification labels propagated to Reign for policy enforcement.
- 10Private network egress only. No vendor-side telemetry without explicit customer approval.
- 11Backup and DR posture documented and audit-grade.
- 12Quarterly FDE-pod hardening review. Continuous-remediation SLA on findings (P0 within 7 days, P1 within 21 days, P2 within 60 days).
REIGN-READY · AI CODING TOOL LAYER
The AI coding tools. Governed at the call layer.
GitLab Duo, Cursor, Claude Code, Cortex, Copilot are productivity multipliers. They are also the largest emerging side-channel for source code and secrets exposure. Reign governs them as first-class call-layer subjects.
- Every AI coding tool call routed through the Reign AI Gateway. Identity-bound. Content-classified. Policy-enforced before the LLM sees the code.
- Tamper-evident audit trail of every coding-agent decision in the Reign Audit Ledger (CAVR).
- Approved-model registry mapped to the customer's AI governance posture (SR 26-2, EU AI Act, FDA PCCP, FINOS AIGF where applicable).
SHARED RESPONSIBILITY
What we run, what you run. Scoped to GitLab.
Forge Automated
Decisions Forge closes inside the GitLab Self-Managed substrate without human intervention.
- Operate GitLab Self-Managed inside the customer's authorization boundary.
- Enforce the customer-bound IdP (SAML, SCIM) at the platform edge.
- Run GitLab Runners isolated per environment, short-lived JWT tokens, no long-lived registration.
- Stream GitLab Audit Events to the customer's SIEM and to the Reign Audit Ledger (CAVR).
- Patch the substrate and runner fleet on a continuous-remediation SLA.
Customer Authored
Decisions the customer owns. The customer is the author, not just the approver.
- Own projects, groups, sub-groups, intellectual property, MR review policy, and protected branches.
- Author the catalog of AI coding tools sanctioned (GitLab Duo, Cursor, Claude Code, Cortex, Copilot).
- Approve evaluators the FDE pod authored during the on-ramp phase against the customer's AI inventory.
- Sign off on examination snapshots (Assurance Pack outputs) before delivery to the regulator.
- Approve new agentic tool integrations and policy exceptions surfaced by the evaluator fleet.
FDE Intervention
Decisions where iTmethods Forward Deployed Engineers run the work. Authoring on-ramp plus continuous-remediation SLA.
- Stand up the initial hardening configuration on the GitLab Self-Managed substrate.
- Author the first 10 to 15 evaluators against the customer's GitLab surface (Duo use, project access patterns, secret exposure, pipeline drift).
- Operate the continuous-remediation SLA on findings the evaluator fleet emits.
- Lead quarterly posture reviews with the customer's CRO, CISO, audit committee, and Independent Assurance function.
- Train the customer's audit and MRM teams to author their own evaluators.
REIGN TIER ALIGNMENT
Which Reign tier do customers typically enroll into?
Most regulated GitLab on Forge customers also enroll in Reign Assurance or Reign Continuous. The coding-agent governance is delivered by Reign at the call layer. The hardening and operations are delivered by Forge. The same FDE pod runs both.
FAQ
Five questions before the scoping call.
How do we choose between GitLab Ultimate and GitLab Self-Managed Premium?
Ultimate is the default for regulated buyers. The Ultimate-only features (Compliance Pipelines, Audit Events with longer retention, Security Dashboards) align with the SR 26-2 / EU AI Act / DORA evidence cadence regulated enterprises need. Premium fits earlier-stage organizations or workloads where the Ultimate feature set is genuinely not needed. FSAI Assess can scope the decision.
How do you migrate from gitlab.com SaaS to GitLab Self-Managed on Forge?
FSAI Assess sizes the migration. Inventory of projects, groups, sub-groups, CI/CD variables, and Runners; gap analysis against your regulatory surface; phased cut-over with the continuous-assurance posture live on the new substrate from day one. Group and sub-group inheritance preserved across the move.
What does GitLab Runner topology look like in restricted environments?
Runners isolated per environment, scoped to short-lived JWT tokens, no long-lived runner registration tokens. Each runner has its own egress controls and audit trail. In sovereign or air-gapped deployments, runners stay entirely inside the customer's authorization boundary. No outbound calls to gitlab.com.
How is GitLab Duo governance handled?
Every GitLab Duo call (Code Suggestions, Chat, Vulnerability Resolution, any future Duo capability) routed through the Reign AI Gateway. Identity bound to your IdP, content classified before the model sees it, project and group classification labels propagated to Reign for policy enforcement. Tamper-evident audit trail in the Audit Ledger (CAVR). Approved-model registry maps to your AI governance posture.
What changes if GitLab the vendor has a security incident?
Your code stays in your trust boundary. Authorization to your projects is independent of GitLab's vendor-side posture. iTmethods leads the patch cadence inside your environment, runs the customer-side impact analysis, and delivers an Assurance Pack snapshot your audit committee can present.
Talk to Forge engineering.
Scope a hardened GitLab Self-Managed deployment inside your trust boundary. Customer Cloud, sovereign on-prem, or air-gapped. Reign-ready for GitLab Duo and the AI coding tool fleet.
Talk to Forge engineeringDownload the GitLab on Forge hardening sheet.
The full 12-control policy-as-code reference, organized by audit framework. Drops into the FSAI Assess scoping conversation.
Get the hardening sheet