GitLab for public sector: air-gapped deployment

Why GitLab for public sector work starts with the network boundary

For a public sector agency, the design question for self-managed GitLab starts before installation: how the instance, runners, updates and scanners work without internet access. Source code, pipeline definitions and build evidence often must stay inside an accredited network, and the agency must be able to show who changed what and where each artifact came from. Every dependency the platform needs, from the Linux package and container images to job images and scanner data, has to reach the enclave through a path the agency controls and records. Decide that path first, because it sets the install method, the runner design and the update rhythm that follow.

GitLab documents self-managed instances running in offline, air-gapped environments, and it publishes separate guidance for running its security scanners and GitLab Duo Self-Hosted offline. Use that guidance as the starting point for the architecture review. Confirm with the vendor which artifacts each scanner needs and how its vulnerability data is refreshed inside the enclave, because a scanner that cannot update its data produces findings nobody can rely on. Also confirm which scanning and compliance features your edition includes, since the pricing page places application security testing and compliance features in the Ultimate tier. Runners need the same treatment: their job images must come from an internal registry, and each runner must be registered and maintained inside the boundary.

Updates are where air-gapped GitLab most often falls behind. GitLab ships a minor release on the third Thursday of each month, patch releases twice a month, and currently maintains 19.5, 19.4 and 19.3. Bug fixes go only to the current stable release, while security fixes also reach the previous two monthly releases, so waiting for a convenient window can leave the instance without security fixes for longer than intended. Required upgrade stops also apply, and since GitLab 17.5 they fall at x.2, x.5, x.8 and x.11, such as 19.2, 19.5, 19.8 and 19.11. Each update therefore means carrying packages across the boundary, verifying them and rehearsing the upgrade path on a staging copy. Agree the transfer, verification and approval steps with your security team before the first install.

Which public sector requirements shape the GitLab build

This table maps each public sector requirement to its source and to what it means for a self-managed GitLab build. Read it as a list of questions to settle with your authorizing official, assessor and compliance lead before design starts. It does not replace agency authorization decisions, which remain with the agency and its assessors.

Requirement	What it asks for	What it means for the GitLab build
NIST SP 800-53 Rev. 5 baselines	Controls selected from the low, moderate or high baseline in SP 800-53B, using the Release 5.2.0 catalog as the current reference	Confirm the impact level of the GitLab system with your authorizing official, then map controls to GitLab settings, gitlab.rb configuration, OS hardening and monitoring evidence
FedRAMP scope under M-24-15	Applies to cloud products that handle federal information for an agency; a system used only for one agency's operations on cloud infrastructure and not offered as a shared service is out of scope	A GitLab instance you run for one agency inside its own cloud or data center is usually not a FedRAMP question, but confirm the scope determination with your agency and document it
CJIS Security Policy v6.1 encryption	FIPS 140-3 certified modules or FIPS 197 AES with 256-bit keys for CJI in transit and at rest outside physically secure locations	Plan TLS, disk and object storage encryption, and backup encryption to these requirements; confirm which FIPS-validated images and modules your build uses
CJIS Security Policy v6.1 vulnerability scanning	Vulnerability scanning at least monthly	Schedule scans of the GitLab hosts, containers and offline scanner databases, and keep dated results as evidence for the assessor
32 CFR 2002.14(h)(2) for CUI	Agencies apply NIST SP 800-171 to protect CUI on non-federal systems unless the CUI category prescribes other safeguards	If a contractor hosts CUI repositories in GitLab, the requirement flows into the contract; confirm the applicable safeguards with the CUI category owner before you choose the architecture
ADA Title II web accessibility	WCAG 2.1 Level A and AA for state and local government web content, including contracted content, from 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts	Include GitLab's web interface and any custom pages or portals you publish in the accessibility review; confirm your entity's deadline under 28 CFR 35.200 and who owns remediation
NIS2 public administration scope	Covers central government entities regardless of size; public administration is a high-criticality sector; Member States may extend it to local administration; it excludes national security, public security, defense and law enforcement	Determine whether your organization is in scope under national transposition before you rely on NIS2 for the design; the exclusions may move systems outside it
Evidence owner and authorization decision	The authorizing official and assessors decide whether controls are met; compliance tooling and documentation do not issue approvals	Agree early which artifacts you will deliver (configuration baselines, scan results, backup test records, change logs) and who signs off on each control

Choosing an install path for an isolated network

In a fully air-gapped network, the instance has no route to the internet, so every package, container image, Runner binary and upgrade bundle must be prepared outside and carried in. GitLab documents running self-managed instances in offline, air-gapped environments, and that guidance should be the starting point for the install plan. The Linux package is usually the most practical method here because it bundles PostgreSQL, Redis and Sidekiq, which means fewer external dependencies to stage. According to the GitLab installation methods page, the Linux package is described as the most mature and scalable method, so it is the default to test against first.

Linux package: Bundles the core services, so the offline bundle is smaller to plan and fewer external components must be mirrored.
Helm chart or Operator: Requires a private container registry and a Kubernetes cluster that is itself built offline, which adds staging work before GitLab is installed.
Docker: Workable for small instances, but the team owns more of the configuration and upgrade sequence.
Stateful services: Under the Cloud Native Hybrid architecture, PostgreSQL and Redis run on VMs or managed services, not inside Kubernetes.

Confirm with your team which method your engineers can patch and roll back without internet access, and test an upgrade from a bundle before the instance goes into production.

Which GitLab modules and settings matter for public sector

Public sector GitLab deployments usually succeed or stall on a handful of decisions: which scanners run offline, which tier carries the compliance features, how people sign in, and how builds are isolated. The cards below cover those decisions in the order most agencies meet them, with the tier and offline questions to confirm before purchase.

Offline security scanners

Air-gapped instances cannot pull scanner data or analyzers from the internet, so every scanner, vulnerability database and analyzer image must be mirrored into your network before the first pipeline runs. GitLab documents separate guidance for running its security scanners offline, but availability differs by scanner and by tier. Ask the vendor to confirm offline support for each scanner you plan to use, and state how the vulnerability data will be refreshed and verified after each transfer.

Ultimate versus Premium features

GitLab Premium includes advanced CI/CD and priority support. Vulnerability management, compliance features and application security testing sit in Ultimate, which is custom priced. Public sector teams often need the compliance and vulnerability reporting that drives the Ultimate decision, so the tier choice should follow the control evidence your agency must produce. Confirm the Ultimate price in a written quote, and confirm which Ultimate features work on a fully offline instance.

SAML, LDAP, SCIM and smart cards

Agency identity usually lives in a directory service, and GitLab Self-Managed supports LDAP, SAML, generic OAuth 2.0, Kerberos, JWT, smart card authentication and SCIM user provisioning. Smart card sign-in matters where personnel hold government-issued credentials. Decide which source is authoritative for accounts, how group membership maps to GitLab roles, and how deprovisioning happens when staff leave. Test each path in the target environment, because the identity provider may not be reachable from a segregated enclave.

Runner isolation for air-gapped builds

Runners execute CI/CD jobs, so in an isolated network they are the path through which code, dependencies and images enter the build. Plan runner placement inside the enclave, decide between shell, Docker and autoscaling executors, and keep Runner major and minor versions aligned with GitLab. Build images and packages must be carried across the boundary as checked artifacts, with package integrity verified before they reach the runner. Ask who owns runner images and how job environments are reset between jobs.

The gitlab.rb hardening settings

GitLab's hardening guidance covers application settings, CI/CD, the operating system and NIST SP 800-53 mapping, and it says the work is ongoing and should be rolled out gradually. Most of the decisions live in the configuration file gitlab.rb, along with sign-up, visibility and SSH key settings. Record each setting you change, the control it supports and the reason, so the configuration becomes evidence rather than tribal knowledge. Test changes in a staging instance before production, since some settings affect integrations.

Geo for disaster recovery

Geo, available in Premium and Ultimate for self-managed GitLab, maintains a warm-standby secondary site that is continuously synchronized, which supports disaster recovery planning for systems that agencies must keep available. Geo is not a substitute for backups, and it needs a second site with capacity, network paths and sizing that match the primary. Confirm with your continuity plan how failover is tested, who authorizes it, and how the secondary site is kept inside the same security boundary.

How an offline GitLab rollout is sequenced

The sequence turns an air-gapped request into a self-managed GitLab that is sized, installed, hardened, recoverable and kept on a supported upgrade path. Each phase closes with a check that the next phase depends on.

Review the boundary and size against reference architectures
The agency's architects, security team and DeployOpen engineers document the enclave boundary, the user count, the expected API request rate and the CI load, then map them to the published GitLab reference architectures. This step also decides whether a single node is enough or whether high availability is needed, which the documentation generally recommends for 3,000 or more users. Confirm which components will live on VMs or managed services, because stateful components such as PostgreSQL and Redis are not supported inside Kubernetes. The step is done when the sizing, the architecture choice and the list of required ports and network paths are approved in writing.
Assemble and verify the offline bundle
The team collects the installation packages, container images, runner binaries, scanner content and vulnerability data needed for the enclave, using a connected staging network that matches the target versions. Each artifact is checked for integrity and authenticity against the publisher's published checksums before it crosses the boundary, and the transfer is logged under the agency's change process. Confirm with the vendor which offline scanner and AI components the chosen tier includes, since the offline guidance covers them separately. The step is done when the bundle manifest, checksums and transfer record are signed off by the agency's security owner.
Install GitLab and integrate agency identity
Engineers install the instance from the offline bundle using the chosen installation method, then configure the agency's identity source, such as SAML, LDAP, Kerberos or smart card authentication, along with SCIM provisioning where the agency's directory supports it. Test sign-in with a set of pilot accounts from each group that will use the system, and confirm that group membership maps to the intended GitLab roles. The step is done when administrators can sign in through the agency identity provider, a break-glass administrator path is tested, and the configuration is stored in version control.
Set up runners and offline scanners
Runners are deployed inside the enclave with the executor type matched to the build workloads, and their versions are aligned with the GitLab version as the Runner documentation advises. Application security scanners and any dependency or container scanning content are loaded from the verified bundle, with no outbound calls to public update services. Confirm which scanners the agency's license tier covers before promising coverage. The step is done when a test pipeline runs end to end on an isolated runner, each scanner completes a scan of a sample project, and the results appear in the project's security reporting.
Roll out hardening in stages
The security team works through the hardening guidance, which covers application settings, CI/CD, the gitlab.rb configuration file, the operating system and NIST SP 800-53 mapping. Because the documentation describes this guidance as a work in progress to be applied gradually, changes are grouped into batches, tested in a non-production instance, and mapped to the control IDs the agency is assessed against. Each batch is recorded as a configuration change with a rollback plan. The step is done when every hardening item is either applied, documented as an accepted deviation or scheduled, and the evidence is stored with the system security plan.
Test backup and restore before go-live
Engineers run the backup procedure on the production-like instance, then restore it to a separate host inside the enclave and verify repositories, issues, merge requests, pipelines, container registry content and the secrets files that the restore depends on. For high availability or Geo designs, failover steps are rehearsed as well, and the recovery time and data loss observed are recorded. The step is done when a restore has been completed and checked against a defined list, and the agency has signed off that the procedure can be repeated by its own staff.
Schedule upgrades around stops and the maintenance policy
The team agrees a written upgrade cadence that follows the maintenance policy, which ships a minor release each month, patch releases twice a month and maintains a small set of stable versions with security backports to recent monthly releases. Planned upgrades must pass through the required upgrade stops, so the plan lists the stops between the current and target versions and the offline bundle for each one. Confirm with the vendor how the agency will receive security releases inside the enclave. The step is done when the upgrade calendar, the path of stops and the test-before-production process are documented and owned by a named operator.

How updates, patches and packages cross the isolated boundary

Every GitLab component that enters an isolated network needs its own transfer record, and the workflow should treat the GitLab release, the Runner, scanner data and container images as separate items. Start by pulling the GitLab release you intend to install from the GitLab maintenance policy, which lists the currently maintained stable lines and the release cadence. Confirm the target version against the GitLab upgrade paths before anything is staged, because a required upgrade stop may decide which package must come across first. Record the version, the source, the checksum and the person who approved the transfer for each item.

The maintenance policy shapes how often you must carry packages across the boundary. Bug fixes are backported only to the current stable release, while security fixes are also backported to the previous two monthly releases. An agency that runs an older monthly release to avoid frequent change may still receive security fixes for it, but only if it keeps moving within that window. Keep the GitLab Runner at the same major and minor version as the server, as the GitLab Runner documentation advises, and carry Runner binaries and the scanner and container images in the same change package. Scanner vulnerability data and container images should be refreshed on the schedule your change board sets, and each refresh should be recorded as its own transfer.

For integrity, the practical analogy is NERC CIP-013-2, which requires supply chain procurement processes to address verification of software integrity and authenticity of vendor software and patches. Public agencies are not bound by that standard, but the same logic applies: verify checksums and signatures on the import side, compare them with the values published by the vendor, and keep the verification output in the change record. Ask your change board to confirm each step: who may approve a transfer, which media are permitted, where the verification is performed and how a rejected package is handled. Confirm these steps with your own change board and security office before the first transfer, since the controls you adopt will set the evidence auditors ask for later.

Compliance considerations agencies must evidence

Agencies running GitLab for public sector work against several overlapping frameworks at once, and each one asks for different proof. The cards below separate the control catalog, the cryptography expectations, vulnerability scanning and the cloud authorization boundary so that each evidence set has a named owner. DeployOpen prepares the controls and evidence, but independent assessors and authorizing officials decide what is authorized or certified.

NIST SP 800-53 control evidence

NIST SP 800-53 Rev. 5 is the federal control catalog that most agency authorizations inherit from, and SP 800-53B selects the low, moderate and high baselines. For a self-managed GitLab, evidence usually comes from application settings, audit events, the gitlab.rb configuration file and operating system logs rather than from a vendor attestation. Map each selected control to the setting or log that proves it, and confirm with your assessor which controls the platform owner, the hosting team or the agency inherits. Ask the assessor which baseline applies before mapping starts.

FIPS 140-3 and AES-256 for CJI

Where GitLab holds or pipelines touch criminal justice information, the FBI CJIS Security Policy version 6.1 requires FIPS 140-3 validated modules or FIPS 197 AES with keys of at least 256 bits for CJI in transit and at rest outside physically secure locations. Confirm that the GitLab images, the operating system crypto modules and the TLS endpoints in your deployment use validated modules, and that the validation certificate covers the version you run. Do not assume a container image is FIPS validated because its name says so.

Monthly vulnerability scanning for RA-5

CJIS Security Policy version 6.1 requires vulnerability scanning at least monthly, and the scanning requirement maps to the RA-5 control in SP 800-53. For GitLab, this covers the instance, the operating system under it and the container images used by runners. GitLab's security scanners can run on offline instances, but each scanner's advisory data must be updated through an approved import path. Record scan dates, scope, findings and remediation tickets so the monthly cycle is provable, not just performed.

FedRAMP scope for a single-agency system

FedRAMP applies to cloud products and services that handle federal information on behalf of an agency. A GitLab instance used only by one agency's own operations on cloud infrastructure, and not offered as a shared service, is generally outside FedRAMP scope, but the agency still needs a documented authorization decision under its own ATO process. Confirm the scope determination in writing with your agency security office, and record who operates the cloud account, who holds administrative access and whether any service is shared with other tenants.

What agencies ask before hiring a GitLab partner

What drives the effort and cost of an air-gapped GitLab build?

The main drivers are how many packages and artifacts must cross the isolation boundary, how many components the instance needs, and how much accreditation evidence the agency requires. GitLab documents running self-managed instances in offline, air-gapped environments, but each dependency still has to be identified, staged and verified. Scope also grows with the number of users, the CI load and whether security scanners and offline AI features are included. Ask the partner to break the work into staging the install media, building the internal mirrors and registries, configuring the instance, and validating scanners offline. Each line should map to a written deliverable.

Which costs are one-time and which recur after go-live?

One-time costs usually include design, installation, integration with identity, the first backup and restore test, runner setup and documentation. Recurring costs include licensing, staff time for patching and upgrades, runner capacity, storage growth, scanner database updates brought in through the offline process, and periodic restore testing. GitLab's pricing page lists Free at 0 US dollars per user per month, Premium at 29 US dollars per user per month billed annually and Ultimate as custom priced, and all three tiers are available for self-managed installations. Ask the quote to separate the license line from the services line and to state which items repeat each year.

What must the agency provide before the build starts?

The agency provides the target infrastructure, network approvals for the isolated enclave, a transfer process for approved media, and named contacts for identity, security accreditation and change control. Identity owners need to supply directory details for LDAP, SAML or OAuth 2.0 sign-in, and the accreditation contact needs to confirm which controls the evidence must support. Ask who approves each media transfer and how long those approvals take in your environment, because that is often the longest dependency. Write these responsibilities into the statement of work so delays have a clear owner.

Can our own team run a self-managed GitLab instance after handover?

Often yes, but only if the team has Linux administration, database and backup skills, and time for scheduled maintenance. GitLab's installation methods page describes the Linux package as the most mature and scalable install method, which suits teams that manage servers directly. The team must also follow required upgrade stops, keep runners aligned with GitLab's versions and test restores regularly. Ask the partner for a handover plan that includes runbooks, a training session on the backup and upgrade procedures, and a list of tasks the agency will own versus those covered by a support retainer.

How long does an air-gapped rollout take and what drives that timeline?

The timeline depends on the reference architecture chosen, the number of users, the identity integration, and how long media transfer approvals take inside the agency. GitLab's reference architectures range from 1,000 users at 20 API requests per second to 50,000 users at 1,000 API requests per second, and the documentation generally recommends a high availability strategy for 3,000 or more users. Larger topologies add build and test effort. Ask for a timeline that lists each approval gate and the duration the agency expects for it, rather than a single end date.

How are upgrades handled across GitLab's required upgrade stops?

Upgrades must pass through required upgrade stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11, for example 18.2, 18.5, 18.8, 18.11, 19.2, 19.5, 19.8 and 19.11, according to GitLab's upgrade paths documentation. Each offline upgrade means new packages must be staged, verified and carried across the boundary again. GitLab's maintenance policy ships a major release yearly, a minor release on the third Thursday of each month and patch releases twice a month, and it maintains 19.5, 19.4 and 19.3 at present. Security fixes are backported further than bug fixes, so the plan should set a schedule that keeps the instance on a supported line. Ask the partner to show the upgrade path from your current version and the backup taken before each stop.

What should we ask for in a fixed-scope quote?

Ask for a written scope that names each deliverable, the environments covered, the number of users and runners, and the security and compliance evidence the partner will prepare. The quote should state what is excluded, such as licensing, agency-owned hardware, third-party assessment fees and ongoing support, and it should list the assumptions behind the schedule. Request the acceptance criteria for each milestone, including backup and restore verification and offline scanner validation. DeployOpen plans and implements self-hosted platforms in the client's own infrastructure, works from a fixed-scope written agreement, and prepares evidence for compliance assessments, but independent auditors issue any attestation. Confirm with the partner which items they handle directly and which depend on the agency's accreditation process.

What agencies should decide before the build starts

The first decision is which baseline the system must meet. NIST SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B defines low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively. Agencies should confirm with their authorizing official or security office which baseline the GitLab system is categorized under, because that choice sets how much evidence the hardening work must produce. The NIST SP 800-53B baseline profiles are published in OSCAL, which lets the team trace each control to a configuration setting or a procedure. Confirm also whether the instance will be a shared service for several agencies, since that changes who owns each control. Second, decide whether any repositories, issues, pipeline logs or artifacts will hold criminal justice information or controlled unclassified information. CJIS Security Policy version 6.1 requires FIPS 140-3 validated modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations, and it requires vulnerability scanning at least monthly. If CUI is involved, 32 CFR 2002.14(h)(2) points agencies to NIST SP 800-171 for non-federal systems. Put the answer in writing before the first repository is migrated, because it decides whether FIPS images, encryption settings and scanning cadence are in scope from day one. Third, decide whether Geo is required and which edition the features demand. Geo, available in Premium and Ultimate for self-managed GitLab, provides a warm-standby secondary site that is continuously synchronized for disaster recovery. Agencies should state a recovery objective and then test whether a single-site backup and restore meets it. Edition choice follows features: the pricing page lists application security testing, supply chain security and compliance features under Ultimate, and Ultimate is custom priced. Ask the vendor for a quote tied to the specific features in the written scope, and confirm offline availability for each feature before assuming it works in an isolated network.

How DeployOpen scopes and delivers public sector GitLab work

DeployOpen plans, implements, hardens, backs up, documents and supports self-managed GitLab inside your own infrastructure, including air-gapped networks. For public sector work, we start from the authorization and control obligations your agency already carries, then build and hand over evidence your assessors can review.

How we scope

Written scope that names the environments, network zones and user population in the agency's boundary
Confirmation of the install method, edition and any offline scanner or self-hosted AI components in scope
Agreed mapping of the NIST SP 800-53 controls your authorizing body expects, with the baseline confirmed by your team
Fixed-scope deliverables and timelines agreed in writing before any build work begins

How we build

Installation in your environment, including offline packages and an internal mirror for updates and dependencies
Hardening of application settings, CI/CD configuration, gitlab.rb and the operating system, rolled out in stages
Integration with your approved identity provider, enforced two-factor authentication and runner isolation
Verification testing of access controls, backup restores and upgrade steps before the system goes live

How we hand over

Configuration and hardening records mapped to control identifiers, ready for your assessor and security team
Documented backup, restore and upgrade runbooks tied to the upgrade stops and release schedule you adopt
Knowledge transfer sessions so your administrators can operate, monitor and patch the instance without us
Clear list of items your agency must confirm with vendors, auditors or its own authorizing official

How we support

Ongoing support, upgrades and continuous testing available as a retainer after handover
Scheduled review of GitLab patch, minor and major releases against your change control process
Re-testing of hardening settings and offline scanner data after upgrades or significant configuration changes
DeployOpen prepares systems and evidence for assessments but does not issue audit reports, attestations or certifications

GitLab for public sector