When a fully offline GitLab Duo deployment is the right answer
A fully offline GitLab Duo Self-Hosted deployment is the right answer when your GitLab instance and its AI features must operate with no internet path at all, because policy, classification or network design rules out any outbound connection. In that case the whole Duo stack moves inside your boundary: licensing, the self-hosted AI gateway, the models and every feature that would otherwise call a service outside your network. GitLab documents this case in its offline environments guidance, which covers self-managed instances in air-gapped networks and gives separate instructions for running GitLab Duo Self-Hosted offline.
The decision usually comes from a regulated or isolated environment: a network segment for critical systems, a government or defense enclave, or an operator whose security rules forbid vendor connections from production hosts. If your environment only limits which hosts may reach the internet, a hybrid design may be enough, and the hybrid option is the one that would otherwise send some requests outside. Confirm with your security team which traffic is prohibited, not just which destinations are preferred. Then check each Duo feature you plan to use against the offline guidance, because support for individual features can differ between connected and disconnected modes.
Before committing, ask your GitLab account team and confirm in writing which license type, add-on and feature set apply to an offline instance, how license renewals and usage reporting work without connectivity, and how new model and gateway versions will reach an isolated network. Plan for a transfer process for every update, since an offline instance cannot pull packages, models or images on its own. Also confirm the GitLab version you will run and its upgrade stops, because the gateway and the instance must stay aligned.
Which Duo capabilities need outside connectivity in hybrid mode
Hybrid deployments can depend on licensing and usage reporting that assume a connection to GitLab. A fully offline design replaces that dependency with a license that works without outbound contact. The offline path runs through the Agent Platform Self-Hosted add-on, while online licenses use usage-based billing that requires the instance to report usage. Confirm the exact license mechanics with GitLab before you commit, because the add-on and seat model decide what the instance is permitted to run.
- Online billing: Usage-based billing assumes the instance can report usage, so it does not fit a network with no outbound path.
- Offline license file: Obtain the license through the Agent Platform Self-Hosted add-on and load it into the instance during setup.
- Seat and add-on scope: Confirm which seats and add-ons cover each Duo feature you plan to enable, since seat counts and add-on scope are separate decisions.
- Renewal handling: Plan how renewed licenses reach an isolated network through the same controlled transfer process used for other media.
Ask GitLab in writing which license type and reporting method apply to your offline design, and settle the answer before procurement.
Hybrid mode can send prompts to models or services that GitLab hosts, depending on the feature. A fully offline design needs an inference path for each feature that stays inside your network. Self-hosted models served behind the self-hosted AI gateway cover this only for features that support them, and GitLab's support matrix rates feature support for self-hosted models. Do not assume that a feature works with a given model family because the platform as a whole works.
- Model mapping: Map each Duo feature you plan to use to a model you host, using the support matrix as the source.
- Support rating: Check whether each feature is rated for self-hosted models and what that rating covers.
- Inference endpoint: Confirm that the gateway calls an endpoint on your network and has no fallback to a hosted provider.
- Egress controls: Block outbound traffic from gateway and model hosts so a configuration error cannot route prompts out of the boundary.
Test each feature with an internal prompt and review network logs to confirm that no outbound call occurred.
The gateway, model servers and supporting components are delivered as images and packages. In a hybrid design these can be pulled from public registries during install and upgrade. Offline, every artifact must be staged in advance, verified and moved across the boundary through an approved transfer process. Version alignment matters here because the gateway must match the GitLab release in use, and the upgrade path follows GitLab's required stops.
- Internal registry: Mirror every image and package the gateway and model stack need into a registry inside your network.
- Version alignment: Stage the gateway version that matches your GitLab instance, and record the pairing for each upgrade.
- Integrity checks: Verify checksums and signatures for each artifact before it enters the isolated network, and keep the verification record.
- Kubernetes images: If the gateway runs on Kubernetes, pre-pull cluster images into the internal registry, using the image list tooling for that cluster distribution.
Confirm with GitLab which artifacts the offline installation guidance requires, and build the transfer manifest from that list.
Some Duo features and security scanners consult sources outside the instance, such as public documentation, package registries or vulnerability databases. Hybrid mode can reach those sources directly. Offline, each lookup must be served from an internal copy, replaced by an internal source or switched off. GitLab documents offline guidance for security scanners separately from Duo, so the two need separate plans.
- Vulnerability data: Use the offline update method that GitLab documents for scanners, and set a schedule for importing new data.
- Package sources: Point dependency resolution at internal mirrors so builds do not reach public registries.
- Web search and external knowledge: Confirm whether each feature can use an internal knowledge source, and disable any external search that cannot be redirected.
- Telemetry and analytics: Review instance settings that send usage or product data, and disable the ones your policy does not allow.
Use GitLab's offline environments documentation as the starting point, and confirm each lookup against the current release.
Some capabilities may have no offline equivalent in the version you deploy. Hybrid mode hides these gaps because the outbound dependency is handled for you. In a fully offline design, each gap needs an explicit decision: accept it, defer it, or cover the need with another control. Support for offline operation can change between releases, so the decision record should be reviewed at each upgrade stop, not only at installation.
- Gap register: List every Duo feature that depends on outside connectivity in your hybrid test, with the feature owner and the decision.
- Business impact: Describe what developers lose if the feature is off, so the decision reflects real workflow costs.
- Compensating controls: Name the internal control that covers the same need, such as manual review or an internal tool.
- Review schedule: Re-check the register at each GitLab upgrade and when the support matrix changes.
Share the register with developers and the security team before rollout, so the limits of the offline design are known to everyone who uses it.
Choosing the license and model platform for an offline Duo deployment
This table compares the offline licensing path, the on-premises GPU model platform and the alternatives for each decision. Read each row as a question to settle with GitLab and your own infrastructure team before procurement starts. The main takeaway is that the license path and the model platform must be chosen together, because the offline license and the hosting location constrain each other.
| Decision | What it fits | What it requires from your infrastructure | What to confirm with GitLab |
|---|---|---|---|
| Offline license via Agent Platform Self-Hosted add-on | Networks where the GitLab instance and AI gateway cannot reach GitLab's cloud licensing services at all | A license file imported into the instance, a planned process for renewal and a way to move the file across the air gap | Which Duo features the offline license covers and how renewals and seat changes are issued without connectivity |
| Online license with usage-based billing | Environments that allow outbound connectivity for licensing while keeping code and prompts inside the boundary | Outbound access for license validation and usage reporting, with firewall rules documented for the security team | Exactly which endpoints must be reachable, what usage data is reported and whether your policy accepts it |
| Duo Enterprise seats | Organizations that want seat-based entitlement for Duo features across the developer population | Depends on the license path chosen; seats still need a matching offline or online license to function | Whether seats are valid on a fully offline instance and which add-on, if any, is also required |
| On-premises GPU model platform | Data residency rules that forbid any model traffic leaving your facilities, including air-gapped sites | GPU servers with capacity planned from GitLab's sizing examples, local storage for model weights and a self-hosted AI gateway | Supported model families and ratings for your features, driver and CUDA versions, and how weights are delivered offline |
| Private cloud model service (AWS Bedrock or Azure OpenAI) | Cases where private cloud is acceptable and GPU procurement is not practical | Private network connectivity from the AI gateway to the cloud service, which breaks a strict offline boundary | Whether this option is supported with a fully offline license and how it matches your residency and connectivity rules |
| Model platform with no GitLab support matrix entry | Teams that already run an inference stack and want to reuse it | Compatible OpenAI-style endpoint, version alignment with GitLab and a validation pass for each feature | Whether GitLab rates the model for the features you need before any build work begins |
| Fully offline vs. hybrid licensing | Sites where internet access is blocked by policy, not just limited | Offline-capable image and package delivery, plus an airgap transfer process for every upgrade | Which features the hybrid option would send outside the network and the offline alternative for each |
Setting up an offline GitLab Duo Self-Hosted instance
This sequence takes a self-managed GitLab instance from a standard offline install to a working Duo Self-Hosted deployment with a self-hosted AI gateway, locally served models and an offline license. Each step ends with a check so the team knows what it has confirmed before moving on.
Prepare the offline GitLab instance
The platform team installs self-managed GitLab inside the isolated network by following GitLab's offline environments guidance, which also covers running GitLab Duo Self-Hosted without internet access. Choose the install method your team can maintain (the Linux package is the most mature option in GitLab's installation methods) and confirm the target version against the upgrade stops and maintenance policy before you install. Done means GitLab loads in a browser from inside the network, the admin area reports the expected version, and the instance does not attempt outbound connections during its own health checks.
Transfer and verify packages and images
Build the transfer set on a connected machine: GitLab packages, container images, Runner binaries, the AI gateway image, and the model artifacts and inference server images your serving stack needs. Record a checksum for every file and image digest, then move the set across the boundary through your approved media process. Repeat the checksum comparison on the isolated side before anything is installed. Done means every artifact matches its recorded hash and the list of transferred items is signed off by the person who owns the boundary, which supports the software integrity expectations in NERC CIP-013-2 if that standard applies to you.
Install the self-hosted AI gateway
Deploy the self-hosted AI gateway inside the same network so GitLab can reach it over internal addressing only. Set the gateway version to match your GitLab version, since the two must align, and confirm the exact pairing in GitLab's Duo Self-Hosted documentation before you pull the image. Point the gateway at the internal endpoint of your model server and block its egress to any external address. Done means the gateway starts, reports healthy, and GitLab's configuration shows the gateway address as a reachable internal service.
Deploy the model serving endpoint
Stand up the model server on local GPU hosts, using models from GitLab's supported list for Duo Self-Hosted and the serving layer you have chosen, such as vLLM behind an OpenAI-compatible endpoint. Load model weights from the transferred set rather than pulling from a public hub, and keep the serving host's outbound route closed. Confirm the model names and hardware requirements with GitLab's support matrix, not with memory or community sources. Done means the endpoint answers a test completion request from the gateway host, and the model responds without any outbound request in the firewall logs.
Load the offline license
Obtain the offline license file through your DeployOpen or GitLab account contact, confirm it covers the Agent Platform Self-Hosted add-on and the seat count you need, and upload it in the GitLab admin interface. Offline licensing differs from online usage-based billing, so check the add-on and seat terms in the licensing guidance before this step. Done means the license page shows an active subscription with the expected seat count and expiry date, and GitLab does not attempt to contact the license service.
Validate each Duo feature
Test each Duo feature the team plans to use, one at a time, with a named test user and a non-production project. Start with Code Suggestions in the IDE, then Chat, then any Agent Platform features you have enabled, and record what works and what returns an error. Use GitLab's feature support matrix to set expectations for Full, Partial and Limited ratings before you judge a result. Done means every planned feature has a recorded test result, and any feature that depends on an outside service is either disabled or documented as an accepted gap.
Confirm no outbound traffic remains
Run a network capture or firewall review across GitLab, the gateway and the model host while Duo features are exercised. Look for DNS lookups, TLS sessions or HTTP calls to addresses outside the boundary, including telemetry and update checks. Where a feature still tries to reach an external service, record the setting that controls it and decide whether to turn it off or accept the gap in writing. Done means the capture shows only internal traffic during feature tests, and the findings are saved with the deployment record for your assessors.
Moving packages, models and updates across the isolated boundary
Every artifact that enters a fully offline Duo deployment crosses one boundary by hand: GitLab and Runner packages, container images for the GitLab AI gateway and the model-serving stack, model weight files, and security updates for the operating system and GitLab itself. Plan that transfer as a controlled process with a named owner, a staging area on the connected side, a written list of what is allowed through, and a record of who approved each import. The offline guidance in the GitLab offline environments documentation describes how to prepare these components, but your transfer procedure, media handling and approval steps are yours to define and confirm with your security team.
Verify each item before it is installed. For packages and images, record the checksum or signature published by the source and compare it again on the isolated side, and keep the signed manifest with the transfer record. For model files, confirm the exact model name, version and license against the GitLab Duo Self-Hosted support matrix before loading anything, since a model that is not supported for a feature will not behave as the documentation describes. Security updates need the same treatment, with a rule for which patch releases are pulled in and when. GitLab's maintenance policy says security fixes are backported to more releases than bug fixes, so confirm which releases your environment must track. NERC CIP-013-2 is one example of this expectation: it asks utilities to address verification of software integrity and authenticity in their vendor procurement. Electric utilities should map that requirement to their own process. Other regulated sectors, including those with CMMC or FedRAMP obligations, have similar supply chain expectations, so confirm the applicable control with your assessor.
Security and operational risks in a disconnected Duo deployment
A fully offline Duo deployment removes the automatic channels most teams rely on for patches, license checks and telemetry. The cards below cover the risks that appear once those channels are gone and the mitigations to plan before go-live.
Stale model and security patches
Without internet access, GitLab releases, self-hosted model weights and gateway images all arrive by hand, and each one must match the others. Security fixes are backported to the previous two monthly releases, so a patch cycle that slips a few months leaves the instance on an unsupported fix line. Plan a fixed intake process: download, verify checksums and signatures, stage in an internal registry and apply on a schedule. Ask GitLab which versions of the gateway and models pair with your instance before each update.
License renewal without connectivity
An offline license is a file you carry into the network, and it has to be renewed and replaced before it expires. Duo features stop working or degrade when the license lapses, so the renewal date belongs on the operations calendar, not in a procurement inbox. Confirm with GitLab how offline license files are issued, how long they run and who on your side receives renewal notices. Test the license load on a staging instance before each renewal date.
Access control for developers and admins
Developers reach Duo through GitLab, and administrators reach the gateway, model servers and host operating systems through separate paths. Each path needs its own role model, with admin access to the GitLab Rails console, the gateway configuration and the GPU hosts reviewed separately. Connect GitLab sign-in to your corporate identity provider so that removing a user in one place removes access everywhere. Review who holds administrator rights each quarter and record the result.
Segmentation between gateway and GitLab
The AI gateway sits between GitLab and the model servers, so it sees prompts and code context from every developer. Place the gateway and model endpoints in a network zone that accepts connections only from the GitLab instance and the approved administrative hosts. Deny all outbound traffic from that zone by default, including traffic to public package and model registries. Verify the rules with a test that attempts outbound connections from each host and records the failures.
Logging and monitoring without telemetry
A disconnected instance cannot send usage data or alerts to a vendor or a cloud monitoring service, so problems stay inside your walls unless you route them there. Send GitLab, gateway and model server logs to a central store you run, and set alerts on failed model requests, queue growth and certificate expiry. Confirm which GitLab Duo logs contain prompt or code content and set retention and access for them accordingly. Keep health checks running during maintenance windows.
Backup and restore of the offline instance
Backups must cover the GitLab data, the secrets file, the model files, the gateway configuration and the offline license. A restore is only proven when a rebuilt instance on separate hardware runs Duo features against the restored model endpoint. Store backups in a location that is also disconnected from the internet, and keep a copy off the primary site. Rehearse a full restore after every major upgrade, since the upgrade path and the model set may both have changed.
Questions buyers ask before running Duo fully offline
What drives the cost of running GitLab Duo fully offline?
The cost is driven by four components: GPU server capacity for the self-hosted models, the self-hosted AI gateway and GitLab instance around it, the Duo license itself, and the people who build and operate the stack. The license is paid to GitLab, typically as Duo Enterprise seats or the Agent Platform Self-Hosted add-on for offline licenses, and the add-on choice should be confirmed with GitLab. Hardware and the team effort are paid to you or your partner. The main cost levers are the number of concurrent developers, the model size you select and how much of the work is one-time build versus recurring operations. Ask any quote to break these out separately, with the GitLab license, hardware, and services each shown as their own line.
How long does an offline Duo deployment usually take?
Duration depends on scope rather than a single standard figure. The work usually splits into the GitLab base instance, the GPU and model serving layer, the AI gateway placement and version alignment, offline license activation, and validation of each Duo feature you intend to use. A narrow pilot for one team on one model moves faster than a multi-site rollout with air-gapped image transfer procedures and formal evidence collection. Confirm the schedule in writing against your written scope, and ask which milestones depend on hardware delivery, because GPU lead times often control the critical path more than software work does.
What does the client team need to provide?
Plan on supplying access and decisions rather than only budget. Typically that includes a host plan inside your data center or isolated cloud network, GPU servers or accelerator capacity, a internal container or package mirror because the environment has no internet access, DNS and certificate authority details, identity integration for sign-in, and named owners who can approve model and feature choices. Security and compliance staff should confirm which evidence they need to retain. Ask the partner to list every artifact that must cross the isolation boundary so your team can review each transfer before work starts.
Can an internal team build and run this without a partner?
Yes, many teams can, provided they already run GitLab self-managed, operate GPU hosts and know how to move artifacts into an isolated network. The skills that are often thin are GPU capacity planning, model serving behind an OpenAI-compatible endpoint, gateway version alignment and offline packaging. Assess your team against those skills and against the time needed for a first working deployment. A partner is most useful when the team must deliver quickly, has no prior offline GitLab experience, or needs a fixed-scope deliverable with documented verification. Either way, the team should own the runbooks after handover.
How do offline upgrades differ from online upgrades?
Offline upgrades add a transfer step: every GitLab package, container image, model artifact and gateway release must be prepared outside the network, checked for integrity and carried in. GitLab still requires upgrades to pass through required upgrade stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11, so the offline plan must include each stop and the matching gateway and model versions. Release timing also matters: GitLab ships a minor release on the third Thursday of each month and patch releases twice a month, and only the current stable release receives bug fixes, so plan a regular bundle cadence. Confirm the exact procedure with GitLab's offline documentation for your version.
What recurring work remains after the deployment goes live?
Recurring work includes applying upgrade stops and monthly minor releases, keeping the AI gateway and GitLab on aligned versions, refreshing model artifacts when GitLab supports a new model, rotating certificates and credentials, monitoring GPU utilization and queue depth, and running backups and restore tests. Runner versions should also stay aligned with GitLab. Security scanning rules and vulnerability data must be refreshed by an offline process, because nothing pulls updates automatically. Ask any quote to separate this run work from the one-time build and to state whether it is covered by a support retainer.
How should we ask for a fixed-scope quote?
Send a written scope that names the GitLab version and edition, the Duo features in scope, the number of concurrent developers, the target models and GPU capacity you expect to provide, the isolation boundary, the identity provider, and the evidence you need to retain. Ask the partner to list deliverables, acceptance tests, and the client responsibilities that would delay the schedule if late. Request separate pricing for the GitLab license, hardware, one-time implementation and recurring support. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and does not publish a price list, so the quote follows from that written scope.
How DeployOpen scopes an offline Duo engagement
An offline Duo engagement starts with a written scope, agreed before any work begins. DeployOpen plans, implements, hardens, documents and supports self-hosted GitLab inside the client's own infrastructure, and for an air-gapped Duo deployment the scope document is where the network boundary, the feature list and the model choice are fixed. Deliverables, timelines and responsibilities are set out in that document so the client can compare the quote against its own team's effort before signing. DeployOpen does not issue certifications or attestations, so the scope also records which evidence the client's independent assessor will need and who produces each item.
Discovery comes first and checks four things. The network boundary question is whether any path exists from the GitLab instance, the AI gateway or the model hosts to the internet, including package mirrors, container registries, license validation and telemetry, and which of those paths must be closed or replaced with internal equivalents. The data handling question is where prompts, code context and logs are stored and for how long. The feature list question is which Duo capabilities the team actually needs, since GitLab documents separate offline guidance for GitLab Duo Self-Hosted and some features depend on connectivity that the offline environment cannot provide. The model choice question is which model families and hardware the organization can operate, checked against GitLab's support matrix. Confirm each answer with GitLab's offline environments documentation and your own network owners before the scope is written.
The client receives documented deliverables that it can hand to its own operations and audit teams. Typical items, to be confirmed in each written scope, include an architecture record showing the boundary and data flows, the installed and configured GitLab, AI gateway and model components with their version alignment, the offline licensing and add-on arrangement, a tested backup and restore runbook, a feature-by-feature statement of what works offline and what does not, and a support or retainer plan for upgrades. Ask for the acceptance criteria in writing, because they define when the engagement is complete and what the client owns afterward.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. For fully offline GitLab Duo Self-Hosted, we scope the licensing, gateway, model and feature boundaries first, then build and test the deployment against those boundaries before handover.
How we scope
- Confirm which Duo features your teams need and which ones depend on outside connectivity before any build starts.
- Agree the offline licensing path, including the Agent Platform Self-Hosted add-on, with your procurement team in writing.
- Define the written scope, deliverables and timelines together so the engagement is fixed-scope before work begins.
How we build
- Install the self-hosted AI gateway and model serving inside your network, with the GitLab instance version aligned to the gateway.
- Transfer and verify every package, image and model artifact carried across the isolated boundary before it is loaded.
- Test each Duo feature in the offline environment and record which features are unavailable or limited without external access.
How we hand over
- Document the offline architecture, update procedure and media transfer steps so your own staff can repeat them.
- Walk your platform, security and compliance teams through configuration, access controls and the evidence they will need.
- Provide written runbooks for licensing renewal, model updates and restore testing for the Duo components.
How we support
- Offer ongoing support, upgrades and continuous testing for the offline deployment as a retainer, if your team wants it.
- Plan upgrades around GitLab's required upgrade stops and the offline media process, scoped in writing for each cycle.
- Prepare systems and evidence for compliance assessments, while independent auditors and certification bodies issue any formal reports.
