GitLab air-gapped installation guide

Why a GitLab air-gapped installation takes more planning than a connected one

A GitLab air-gapped installation runs self-managed GitLab for source control, code review and CI/CD on a network with no route to the internet. Every package, container image, license input and scanner update reaches that network through a controlled transfer process, and the team owns each step that a connected install would otherwise fetch on its own. Regulated and restricted environments often need this model, so most of the effort sits in planning the transfers, the upgrade sequence and the version alignment before the first installation command runs.

The core install is not the hard part. GitLab documents running self-managed instances in offline environments, but it covers the core installation, GitLab security scanners and GitLab Duo Self-Hosted in separate guidance. Each one has its own set of files to move, its own update path and its own verification steps. Before building a transfer bundle, confirm which of these features the organization needs in the first release, because each one adds a separate intake process and a separate owner. Ask the team that will operate the enclave to sign off on that list.

The update path is the gap that surprises most teams. GitLab requires upgrades to pass through required upgrade stops, and since GitLab 17.5 these 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. On a connected instance, the upgrade tooling can fetch the stop it needs. Offline, each stop must be staged, verified and moved across ahead of time, so the team should map its planned upgrades to specific stops and agree on how far ahead of the next stop it must stage packages.

Runner and image versions need the same discipline. GitLab's documentation advises keeping GitLab Runner major and minor versions aligned with GitLab, so the Runner binaries and the CI container images mirrored into the enclave must match the instance version. GitLab's maintenance policy also sets the cadence: a minor release on the third Thursday of each month, patch releases twice a month, and security fixes backported to the previous two monthly releases as well as the current one. Confirm with the security team whether it can review and import that volume of releases on time, and write that cadence into the operating procedure.

Components that must travel across the gap for a GitLab air-gapped installation

An offline GitLab instance works only if every artifact it needs arrives through your transfer process: the installer, bundled services, CI runner software, scanner data, AI components and the license. The cards below list each component, what it needs from the offline bundle and what to confirm with GitLab for the exact version you plan to run.

Installation method and package

GitLab can be installed with the Linux package, the Helm chart, the GitLab Operator, Docker or from source. The Linux package is described as the most mature method, and it is the method this page assumes. Your bundle must include the package for the exact target version, its checksums, and any repository metadata your package manager needs on an isolated network. If you choose the Helm chart or Operator path, the bundle also needs every container image mirrored into your internal registry. Confirm with GitLab which method and version its offline documentation covers.

Bundled PostgreSQL, Redis and Sidekiq

The Linux package bundles PostgreSQL, Redis and Sidekiq, so these services arrive inside the installer and do not need a separate offline download. Check that the bundle contains the database and cache versions shipped with your release. Plan PostgreSQL backups separately from the configuration and secrets files that the restore depends on. If you move any of these services to external or managed instances, their packages or images must also be in the bundle. Confirm with GitLab which bundled versions apply to your target release before the transfer is scheduled.

GitLab Runner packages and images

GitLab Runner executes CI/CD jobs and is distributed under the MIT license. It supports shell, Docker and autoscaling executors across clouds and hypervisors, and each executor depends on different offline artifacts. A shell executor needs the Runner binary and every tool that jobs call. Docker executors also need helper images and the build images your pipelines pull, all mirrored into your internal registry. Keep Runner major and minor versions aligned with GitLab. Confirm with GitLab which helper images and package versions match your release.

Offline security scanner content

Security scanners depend on data that goes stale. Without internet access, the advisory data and analyzer images used by each enabled scanner must be exported from a connected network and imported on a schedule you define. The bundle should include the analyzer images, the vulnerability data for each scanner you use, and the import procedure. Decide who approves each import and how often it runs, because outdated data produces an incomplete picture of risk. Confirm with GitLab which scanners the offline guidance covers and which update method it documents for your version.

GitLab Duo Self-Hosted artifacts

GitLab Duo Self-Hosted runs AI features inside your own infrastructure, so model artifacts and serving components must cross the gap too. GitLab documents offline use of Duo Self-Hosted separately from the core installation, which means it has its own bundle requirements. Plan for the model files, the serving software and the hardware they run on, and confirm how each is licensed and sized. Enabling the core instance offline does not by itself confirm that Duo features will work offline. Confirm with GitLab the exact artifacts, supported models and hardware for your target version.

License file activation

The license file determines which tier features are enabled on your instance, and the tiers are Free, Premium and Ultimate. Premium and Ultimate are subscriptions, and Ultimate is custom priced. On an isolated network, the license file must be transferred in and applied without the instance depending on an online activation step. Confirm with GitLab how the license is delivered for your deployment, which features your tier enables, and what happens when a license is renewed or replaced during an upgrade. Keep a controlled copy of the file in your records.

Which installation method and tier fit an isolated network

This table compares the main installation, tier and scope decisions for a GitLab instance on an isolated network, with the operational load each choice places on your team. Read each row as a trade-off: the option on the left is not automatically right, and the last column shows when it fits. The main takeaway is that the Linux package keeps offline patching and image handling simplest, while Kubernetes, external databases and scanner or Duo scope add registry, validation and maintenance work.

Decision	Option and what it takes on	When it fits
Installation method	Linux package. Bundles PostgreSQL, Redis and Sidekiq and is described as the most mature method. Your team handles OS packages, patch transfers and service restarts on each node.	Dedicated VMs or bare metal in the isolated network, with a small platform team comfortable running Linux servers.
Installation method	Helm chart or GitLab Operator on Kubernetes. Adds an internal container registry, mirrored images for every component and a longer validation cycle before each upgrade.	The isolated network already runs a supported Kubernetes platform and your team operates it well.
Database and cache	Bundled PostgreSQL and Redis. Fewer components to patch and back up separately, but scaling and failover options are limited as user counts grow.	Small to mid-sized instances where a single-node or simple layout meets your user count and recovery targets.
Database and cache	External PostgreSQL and Redis. Your team takes on database patching, backup, failover and capacity planning, and the offline transfer of database packages.	Larger instances, or organizations that already run approved database services inside the isolated network.
Tier	Free at 0 dollars. Excludes advanced CI/CD, priority support and the security and compliance features listed on the pricing page, so scanner work is limited.	Core source control, code review and basic CI/CD where scanners and Duo are not required.
Tier	Premium at 29 US dollars per user per month billed annually (GitLab pricing page). Adds advanced CI/CD and priority support. Check with GitLab which Premium features your offline license covers.	Teams needing advanced CI/CD and vendor support but not the Ultimate security suite.
Tier	Ultimate, custom priced. Covers application security testing, software supply chain security, vulnerability management and compliance features. Request a written quote that states the scanner and Duo entitlements.	Regulated teams that must run scanners and vulnerability management inside the isolated network.
Scanners and Duo scope	Scanners in scope now. Each scanner needs its own offline data and rule updates, which your team must transfer and refresh on a schedule.	When security testing is a current requirement and your team can manage the update cycle.
Scanners and Duo scope	Duo Self-Hosted in scope now. Requires separate offline guidance, model hosting and GPU capacity that your team must size and maintain.	Only when AI-assisted features are a defined requirement. Otherwise, defer it and confirm the prerequisites in writing first.

Steps for a GitLab air-gapped installation, from bundle to first patch

This sequence takes a self-managed GitLab instance from a version decision on a connected network to a tested offline install, a verified restore and a rehearsed patch, with a check closing each stage so the team knows the isolated system behaves as expected.

Confirm target version and upgrade stop path
Pick the target GitLab version and map the required upgrade stops between your current version and that target. Since GitLab 17.5, required upgrade stops fall at x.2, x.5, x.8 and x.11, so a jump from an older release may need several intermediate installs, each with its own offline bundle. Confirm the exact path against the GitLab upgrade paths documentation and the offline environments documentation for the version in use. Done when the team has a written list of versions to install in order, with each stop's bundle and image set identified.
Build the offline bundle on a staging host
On a connected staging host that matches the target operating system, download the Linux package or other chosen installation artifacts, the required container images and the content for security scanners and any GitLab Duo Self-Hosted components you plan to run offline. Follow the offline environments documentation for the exact bundle and image steps for your version. Record the file list with versions and SHA-256 checksums in a manifest. Done when the manifest is complete and every file has a recorded checksum.
Transfer and verify the bundle through approved media
Move the bundle into the isolated network using the media process your security team has approved, such as a controlled transfer station, scanned removable media or a data diode. Keep the manifest with the bundle. On the isolated side, recompute every checksum and compare it with the staging manifest, and log who handled the media and when. Done when all checksums match and the transfer record is signed off by the security owner.
Prepare the offline host and internal registry
Prepare the target operating system, time synchronization, storage layout, DNS entries and certificates for the GitLab hostname. If your design uses an internal container registry or package mirror, load the images and packages into it and point the instance at it. Confirm that no step attempts outbound internet access. Done when the host resolves its internal names, the registry lists the expected images, and a network test confirms outbound internet is blocked as designed.
Install GitLab and run a health check
Install the staged version from local packages or the internal registry, applying the configuration file, secrets and external service settings that the team has defined. Keep the secrets and configuration files saved separately from the database backup from the start. Run the built-in health check and confirm sign-in works for an administrator account. Done when the health check reports no failed components and the instance serves the expected version.
Activate the license and configure runners, scanners and Duo
Upload and activate the license file from the offline environment, then confirm the tier and user count shown in the admin area. Register GitLab Runners on internal hosts, keeping their major and minor versions aligned with GitLab. Point the offline security scanner content and any GitLab Duo Self-Hosted components at the internal sources you loaded. Done when a test project pipeline runs on an internal runner and a scanner job completes without requesting external resources.
Restore a test backup and compare results
Take a backup from a source instance or a prepared sample, then restore it into a separate offline test environment using the GitLab backup and restore procedure. Compare project counts, user counts, a sample of repositories and a sample of CI artifacts between source and restored copies. Confirm the secrets file restores with the data, since encrypted values depend on it. Done when the comparison shows matching counts and sampled items open correctly and the restore notes are saved as a runbook.
Rehearse a patch before the first production patch
Apply the next patch release to the test environment using the same bundle process as the first install: build, transfer, verify, then upgrade. Run the health check, a test pipeline and the restore comparison again after the patch. Record the elapsed effort and any manual steps so the production runbook matches what worked. Done when the patched test instance passes all checks and the team has signed off the production patch runbook.

How the air-gapped design changes for single node, high availability and Kubernetes

A single-node Linux package installation is the simplest air-gapped layout. The Linux package bundles PostgreSQL, Redis and Sidekiq on one host, so the offline transfer is one set of package files, its checksums and any container images your CI needs, moved across the boundary once per upgrade. Because everything runs on one machine, the design is easiest to verify but has no built-in node-level redundancy.

Offline transfer: one package set per release, staged on a media or transfer host and verified before import.
Runner placement: Runners can sit on separate isolated hosts that reach the instance over the internal network.
Backup storage: the gitlab-backup archive and the secrets and configuration files must go to a separate store inside the enclave.
Failure scope: a host failure takes the whole instance down, so restore time depends on the tested backup process.
Reference architecture: confirm with GitLab's reference architecture documentation that a single node matches your user count and API load.

Confirm the single-node sizing against the reference architecture for your user count before committing, and rehearse a restore onto a spare host.

What drives GitLab air-gapped installation effort and how to keep it down

This table lists the factors that most change the work and cost of an isolated GitLab installation, with how each one raises effort and how to reduce it. Read each row as a decision point to settle before the project starts. The main takeaway is that user count, upgrade distance, and approval steps for moving media usually matter more than the installation itself, so ask for the scope in writing before work begins.

Driver	Why it raises effort or cost	How to keep it down
User count and reference architecture	GitLab's reference architectures run from 1,000 users (20 API requests per second) to 50,000 users (1,000 API requests per second). Larger tiers add more nodes, storage and offline package sizing to move and verify.	Confirm the user count and peak API load in writing. Size the reference architecture to the real load, and avoid over-provisioning for growth you have not planned.
High availability at 3,000 or more users	The docs generally recommend high availability at 3,000 or more users, using Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. Each component adds configuration, offline packaging and testing work.	Decide early whether high availability is required by your service levels. If it is, agree the component list and test failover as part of the fixed scope.
Upgrade stops between current and target version	GitLab requires upgrades to pass through required stops at x.2, x.5, x.8 and x.11 since GitLab 17.5. Each stop needs its own offline package, a backup, and a verification pass in an isolated environment.	Pick the target version at project start and count the stops in the upgrade paths documentation. Keep the installation on a supported release so later patches stay small.
Number of Runners and executors	Each Runner needs its own host or cluster capacity, offline images and dependencies, and a version aligned with GitLab. Autoscaling executors need cloud or hypervisor capacity that works without internet access.	List the job types and concurrency needed, then pick the fewest executor types that cover them. Mirror required images into the isolated network once rather than per job.
GitLab Duo Self-Hosted and security scanner scope	Running scanners and GitLab Duo Self-Hosted offline needs separate guidance and extra data, such as vulnerability databases and model artifacts, to transfer and refresh across the boundary.	Confirm in writing which scanners and Duo features are in scope, and which tier they need. Reduce the number of offline data sets by limiting scanners to those your policy requires.
Identity integration	Connecting LDAP, SAML, OAuth 2.0, Kerberos or SCIM means reaching identity services from inside the isolated network, plus testing group mapping and certificates.	Name the identity provider, protocol and group model before work starts. Use the identity sources that already run inside the isolated network to avoid new connections across the boundary.
Number of isolated environments	Staging, production and recovery environments each need their own installation, offline packages, configuration and backups. Keeping them in sync adds ongoing work with every upgrade.	Agree the environment count in the scope. Use one tested build pipeline for offline packages so the same artifacts deploy to each environment.
Approval steps for moving media across the boundary	Each transfer of packages, images and data across the air gap may need security review, malware scanning, logging and sign-off. Delays here often set the schedule more than technical work does.	Map the approval workflow and its lead times with the security team at project start. Batch transfers into fewer, planned releases and record each one for evidence.

How to test a GitLab air-gapped installation and confirm it fails safely

Run these acceptance tests before the team signs off the installation, and write the expected result for each one before running it. A passing test should prove the instance works without internet access, which a clean startup alone does not show. The tests cover network isolation, offline licensing, offline pipelines, offline security scanning, identity login and restore to a separate host. Record the results in the handover pack with the date, the GitLab version under test and the name of the person who ran each check, so that a later upgrade can be compared against a known baseline.

Start with isolation, because every other test depends on it. From a host inside the instance network, confirm that connections to public internet addresses and public DNS resolvers fail. Confirm that the GitLab server, Runners and scanner hosts cannot reach package repositories, container registries or update services outside your network. Then confirm that the packages, container images and scanner content came from your transfer media and resolve to internal registries or mirrors. For licensing, upload or activate the license with no outbound connection and confirm the instance shows the expected tier. Check the exact offline activation steps and screens in the documentation for your GitLab version, since they can change between releases.

Next, prove that pipelines run on offline components. Create a test project whose runner is registered on the isolated network, pull images only from the internal registry and fetch dependencies only from internal package mirrors. Include a job that references an image not loaded into the registry, and record how it fails. Then run a security scan job against the offline content. Inspect the scanner logs to confirm which vulnerability database or advisory source it used, and check the configured update source to confirm it points to your internal mirror. A scan that finishes with a stale or empty database should count as a failed test, because its results will look clean while covering little or nothing.

Test sign-in through the identity method you chose, using at least one account from each group that maps to a role, and confirm that group mappings grant the expected access. Confirm that the identity provider is reachable only from the internal network. Then restore the latest backup to a separate host with no route to production systems. Verify that projects, users and repository contents match the source, and that the restored instance can run a pipeline. Restore procedure details, secrets handling and test frequency are covered in the backup topic, so treat this step as a check of the restore path and note any manual steps it required.

Failure testing matters as much as the happy path. Remove one dependency on purpose, such as a required package or a certificate the instance trusts, and confirm that the affected feature reports an error instead of retrying silently or hanging without explanation. Request an image that is absent and confirm the job fails with a message that names the missing image. Block the scanner's update source and confirm that the scan reports the update failure and keeps the last good database. Capture the exact messages and compare them with the version documentation. Finally, confirm that no traffic leaves the network by checking boundary firewall logs, DNS query logs and flow records during these tests, and by running a short packet capture on the egress path.

Access control and secrets handling in an air-gapped GitLab installation

Access in an air-gapped GitLab installation depends on what enters the network, who can sign in and what automation can reach. The cards below cover the controls that become harder to change once users, pipelines and backups depend on them. Work through them before go-live and again at each upgrade.

Offline bundle integrity and provenance

Every package, container image and bundle that crosses into the isolated network is a supply chain entry point. Record checksums and signatures when files are downloaded on the connected side, verify them again after transfer, and keep the transfer log with the change record. Confirm with GitLab which checksum and signing formats apply to each artifact in your release, and confirm how transfer media is scanned before import. Verify each upgrade bundle the same way as the first install.

License and secrets rotation

The license file and the secrets the instance uses, such as database and Redis credentials, need a named owner and a dated rotation record. Store the license file in your vault with restricted read access, and test the rotation procedure on a non-production instance first. Ask GitLab how license renewals are delivered to an offline instance and what must be uploaded to activate a new file. Record each rotation against the instance version it was made on.

Backing up gitlab.rb and the secrets file

The gitlab-backup archive does not replace the configuration and secrets files. The backup documentation says gitlab.rb and the secrets file must be backed up separately, so they need their own copy held to the same access controls as the server. Losing the secrets file can leave encrypted data, such as tokens and two-factor secrets, unreadable after a restore. Include both files in restore drills and confirm the restore steps for your version.

Sign-up limits, 2FA and hardening baseline

Disable public sign-up and decide who may create accounts before users are onboarded. Enforce two-factor authentication for all users with a fixed enrollment deadline. GitLab's hardening guidance covers application settings, CI/CD, configuration files, the operating system and NIST SP 800-53 control families. That guidance is a work in progress, so roll out its items in stages, test each change, and record which items you accepted or deferred.

Choosing an authentication method

GitLab Self-Managed supports LDAP, SAML, generic OAuth 2.0 and OmniAuth providers, Kerberos, JWT, smart card authentication and SCIM provisioning. Pick the method that matches your directory and your offboarding process. Check whether your identity provider is reachable from the isolated network, how group membership maps to roles, and who removes access when someone leaves. Confirm each option's requirements with GitLab for your version.

Runner isolation and protected variables

GitLab Runner executes CI/CD jobs, so it needs the same isolation thinking as the GitLab server. Place runners on a network segment that reaches only the resources their jobs need, and choose the executor type that matches your trust model for shared runners. Mark credentials as protected variables so they reach only pipelines on protected branches and tags, and mask them in job logs. Keep Runner major and minor versions aligned with GitLab, and confirm how Runner images are supplied offline.

How to patch GitLab without internet access and keep the upgrade path current

An air-gapped GitLab stays secure only if offline transfers run on the same calendar as GitLab's releases. GitLab ships a minor release on the third Thursday of each month and patch releases twice a month. Bug fixes are backported only to the current stable release, but security fixes also go to the previous two monthly releases. A team that falls two monthly releases behind therefore receives security fixes only if it moves them into the enclosed network in time. Build a recurring transfer window for each cycle, and treat the package and container image transfer as routine operations work rather than an event triggered by an alert.

Plan the upgrade path backward from the target version, because GitLab requires upgrades to pass through required upgrade stops at x.2, x.5, x.8 and x.11 since GitLab 17.5. For example, a move from 18.5 to 19.5 passes through 18.8, 18.11 and 19.2. Each stop needs its own package transfer, its own backup point and its own verification before the next step starts. Keep the GitLab Runner fleet on the same major and minor version as the instance, and transfer Runner packages in the same cycle as the GitLab packages so that jobs keep running between stops. Confirm the exact sequence on the upgrade paths documentation before you schedule the work.

Before each change, take a fresh backup with the gitlab-backup tool and save the secrets and configuration files separately, as described in the backup and restore guidance. Then restore that backup into an isolated staging copy on the same offline network and confirm that projects, CI configuration and users load correctly. Restore tests on a schedule catch problems that a successful backup job does not reveal. After each upgrade, monitor the instance for errors, background migration progress, disk growth and failed jobs, and record the baseline values so the next change has something to compare against.

Offline scanners need their vulnerability and advisory content refreshed by hand, so that content is a recurring deliverable with its own schedule. The offline environments guidance describes how GitLab security scanners and GitLab Duo Self-Hosted are kept working without internet access. Record the date and source of each content import, check scanner results after every import, and keep the previous content package so you can roll back if an import breaks scanning. Confirm the current content procedure with GitLab's offline documentation before you commit to a refresh interval, because the steps can change between releases.

Before every planned change, confirm the currently supported versions on GitLab's maintenance policy page, since the set of maintained releases changes as new minor releases ship. Then hand the operating documentation to the owners of the instance: the upgrade path with its stops, the transfer calendar and checksum process, the backup and restore runbook, the Runner version map, the scanner content log and the rollback point for each change. Ask any partner quote to state which of these tasks sit in fixed-scope work and which fall under an ongoing support retainer, and who performs the transfers and restore tests after handover.

Questions teams ask before hiring help with a GitLab air-gapped installation

How much does a GitLab air-gapped installation cost?

The cost comes from the written scope, which DeployOpen agrees with you before work starts. There is no public price list, so ask for a quote that follows from the scope. Who pays for what: the implementation fee covers scoping, the offline bundle build and transfer procedure, installation, identity integration, backup setup, verification and handover documentation. Your organization also pays for servers or cloud capacity inside the isolated network, storage, and the GitLab subscription. GitLab's pricing page lists Free at 0 US dollars, Premium at 29 US dollars per user per month billed annually, and Ultimate as custom priced. One-time versus recurring: the implementation is one-time, while subscriptions, infrastructure and any upgrade or support retainer recur. Ask the quote to separate these items and to list what is excluded.

How long does an air-gapped GitLab project take?

The duration is set in the written scope, and no fixed timeline applies to every project. The main drivers are your user count, because it determines the reference architecture, with GitLab's reference architectures running from 1,000 to 50,000 users. GitLab generally recommends a high availability strategy at 3,000 or more users, which adds design and testing work. Other drivers include the number of approval cycles for moving packages across the boundary, the complexity of your identity source, how many repositories or systems you migrate, and how quickly your staff review and approve each stage. Upgrade paths also matter, since GitLab requires upgrades to pass through required stops. Ask for a milestone plan that names the dependencies on your side, such as approvals and access to hosts.

What must our team provide for an isolated GitLab deployment?

Your team supplies the decisions and access that only your organization can give. Confirm these items early in scoping:

Network approvals: change requests for hosts, routes and any transfer path into the isolated network.
Media process: an approved method for moving offline packages and images across the boundary, using whatever transfer method your security policy allows.
Identity source: access details and a test account for LDAP, Active Directory, SAML or another identity provider you plan to use.
Staff for approvals: named people who can sign off on each stage, plus a technical contact who can test and accept the result.
Infrastructure: hosts, storage and backup targets inside your environment, with sizing agreed against your user count.

Delays usually come from approval queues and unresolved identity questions, so start those conversations before the build begins.

Can our internal engineers install GitLab air-gapped without a partner?

Yes, an experienced Linux and GitLab administration team can do it, because GitLab documents offline environments and several installation methods, including the Linux package, the Helm chart, the GitLab Operator, Docker and source. The harder parts are usually the ones that repeat over time. Building a complete offline bundle, checking the version path against required upgrade stops, setting up backups and running restore tests, and running security scanners and GitLab Duo Self-Hosted offline with the correct tier all take focused effort. Consider your team's current workload, whether engineers can be released for several weeks, and who will own the work after go-live. Many teams run a pilot on a non-production instance first. Ask a partner to review your plan before you commit staff to the full build.

How does patching work after handover from an isolated network?

Patching becomes a repeatable transfer cycle. GitLab ships a minor release on the third Thursday of each month and patch releases twice a month. Bug fixes are backported only to the current stable release, while security fixes are also backported to the previous two monthly releases. GitLab currently maintains 19.5, 19.4 and 19.3. Each release must reach your network through your approved transfer process, then go to a staging copy for testing before production. Upgrades must also pass required upgrade stops at versions x.2, x.5, x.8 and x.11, so you cannot skip them. For example, the documentation lists 18.2, 18.5, 18.8 and 18.11 as stops. Ask whether the handover includes an operations runbook and whether a retainer covers each release cycle.

Do GitLab security scanners and GitLab Duo Self-Hosted work offline?

GitLab documents separate guidance for running security scanners and GitLab Duo Self-Hosted in offline environments, so both are possible, but each needs its own setup. Scanners depend on vulnerability and analyzer content that must be imported into the isolated network through your transfer process, so you need a schedule for refreshing that content. Duo Self-Hosted requires its own model and component packages, which must also be transferred and validated. On tiers, GitLab's pricing page lists application security testing and related features under Ultimate, while the tier needed for Duo Self-Hosted was not confirmed in the information we reviewed. Confirm the required tier and the offline content list with GitLab before you finalize the budget and scope.

How does DeployOpen approach an air-gapped GitLab installation?

DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including isolated networks. Work is fixed-scope, and the scope, deliverables and timelines are agreed in writing before work starts. A typical sequence covers scoping and reference architecture selection, building the offline bundle and transfer procedure, installing GitLab and integrating identity, configuring and testing backups with a restore test, hardening the instance, and handing over runbooks. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.

How DeployOpen works on this

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including isolated networks. For GitLab air-gapped installation, the work starts with a written scope that defines the offline transfer path, the chosen installation method and the security tooling that must run without internet access.

How we scope

Confirm the GitLab tier, which determines whether scanners and Duo features are in use
Map the offline transfer path for packages, images and license files into the isolated network
Agree in writing which scanners, runners and integrations are in or out of scope

How we build

Install the instance from offline packages using the method selected during scoping
Configure and test scanner and Duo Self-Hosted offline setups against documented offline guidance
Verify backups, restores and a patch-transfer procedure before the environment is accepted

How we hand over

Deliver runbooks for offline package intake, license activation and patch installation
Document the configuration, secrets and file locations that must be backed up separately
Walk the operations team through restore tests and the upgrade stop calendar

How we support

Offer ongoing support, upgrades and patching as a retainer after handover
Review each monthly and patch release for offline transfer and upgrade-stop impact
Confirm with your team the support scope, response expectations and retainer terms in the quote

GitLab air-gapped installation