What the GitLab Duo Agent Platform on self-hosted models changes for your teams
If you run self-managed GitLab and want agentic AI features inside your own infrastructure, the first question is not whether the Duo Agent Platform is available on self-hosted deployments. It is generally available there from GitLab 18.8. The harder question is whether your instance, models, network path and governance are ready for agents that can act on behalf of developers. Agentic features depend on a model that supports them, so a Duo deployment that works for code suggestions and chat does not automatically give you agent capabilities. Treat the Agent Platform as a separate readiness decision.
Four decisions come before any rollout. The first is the model: confirm which self-hosted models GitLab lists as supporting agentic features at your target version, and what support level it gives each feature. The second is licensing, which determines the add-on and seat model you need for an online or offline installation. The third is the network path, since your gateway and model endpoints must be reachable from the instance without sending data outside your boundary. The fourth is governance: who can enable agent features, which projects and groups receive them, and how their activity is reviewed. Each of these changes sizing, procurement and change control, so settle them in writing before pilot users are added.
Feature-level details change between GitLab releases, so verify them against GitLab's current Duo documentation for your exact version rather than relying on a summary, including this one. Ask your GitLab representative or partner to confirm which agent features are supported on self-hosted models, which need external services, and which behave differently in an offline environment. Record the answers against your upgrade plan, because an instance that moves to a new release may gain or lose agent capabilities.
Which deployment option fits your environment
This table compares the three decisions that shape a self-hosted Duo Agent Platform rollout: how the instance connects out, where the models run and how the deployment is licensed. Read each row against your network policy first, then check the licensing and model rows, since they often depend on the connectivity choice. Confirm every row with GitLab before you commit to a design.
| Decision | What it keeps inside your network | When it fits | What to confirm with GitLab |
|---|---|---|---|
| Hybrid connectivity (outbound services allowed) | Repositories, pipelines, CI data and self-hosted gateway traffic stay on your infrastructure, while named GitLab-hosted services are reached over outbound connections. | Your policy allows controlled outbound traffic to specific GitLab endpoints and you want the fewest components to operate. | Which features still call GitLab-hosted services, the exact endpoints to allow, and whether any feature in your plan needs outbound access. |
| Fully offline (air-gapped) | The GitLab instance, AI gateway, models and scanners run with no internet connectivity, so no prompt or code leaves the network. | Regulation, classified work or network rules prohibit any outbound path, and you accept that some features will be unavailable. | Which Agent Platform features are supported offline, offline license handling, and how model and gateway updates are delivered into the network. |
| On-premises GPUs as the model platform | Model weights, inference servers and prompt data run on hardware you own or lease in your data centers. | Data residency rules require all inference inside your facilities, or you already run GPU capacity you can dedicate to Duo. | The supported model families and their ratings for agentic features, and the hardware sizing GitLab documents for your user count. |
| Private cloud model service (AWS Bedrock or Azure OpenAI) | Your prompts and outputs pass through your own cloud tenant under the provider's terms, and GitLab components remain on your infrastructure. | Private cloud is acceptable under your policy and you prefer managed model capacity over operating GPUs. | Which model and region combinations GitLab supports, how the gateway authenticates to the service, and how data handling is documented for your contract. |
| Online licensing with usage-based billing | License checks and usage reporting reach GitLab over the network, so the instance needs connectivity for licensing. | The instance can reach GitLab services and you want licensing to follow actual usage. | How usage is reported, what happens when connectivity is interrupted, and how billing changes if the deployment later moves offline. |
| Agent Platform Self-Hosted add-on with offline license | License and entitlement data are provided as a file that can be applied without an internet path. | The deployment is fully offline or the network policy forbids license callbacks. | Add-on eligibility for your tier, renewal and license file delivery, and whether seat counts must be declared in advance. |
| Required GitLab version | Agentic features need a GitLab release where the Agent Platform is generally available on self-hosted deployments, starting with GitLab 18.8. | You plan to deploy or upgrade to a supported release line and align the AI gateway version with it. | The minimum version for each Agent Platform feature, and the upgrade stops you must pass through to reach it. |
Hybrid or offline: how the choice changes the rollout
A connected self-managed instance can reach GitLab services and model endpoints over outbound paths that your team approves. The rollout is mostly a question of which features send data outside your network, and which license and billing model you hold.
- Hybrid features reach outside: Some Duo features call services that run outside your infrastructure. Ask GitLab which requests leave your network for each feature you plan to enable.
- Licensing is validated online: Confirm with GitLab how an online license is validated and whether it uses usage-based billing before you size seats.
- Updates follow the public schedule: Minor releases ship on the third Thursday of each month and patch releases twice a month, as set out in the GitLab maintenance policy. Keep the AI gateway on the same version as the instance.
- Proxies need documented allowlists: If outbound traffic passes through a proxy, record each hostname and port, then test them from the instance host and the gateway host.
Check with your security team which outbound destinations apply to your version and whether your data processing terms allow them before you commit.
Many regulated networks sit between the two extremes. The instance reaches only approved internal endpoints and a short list of allowlisted external hosts. This posture needs an audit of each path, because some features may depend on outbound access while others do not.
- Map every destination: Build a register of each host that the instance, gateway and runners contact, with the reason for the connection and a named owner.
- Scope runner egress separately: CI/CD runners need their own outbound rules, distinct from the instance. Isolate runner networks as described in GitLab's hardening recommendations.
- Keep model traffic internal where possible: Self-hosted models on your own hardware keep prompt traffic inside your network, but the gateway still needs a documented path to the GitLab instance.
- Align versions across the path: The AI gateway and the instance must match versions, so any package or image pull path must deliver both at the same release.
- Watch for drift after patches: Firewall changes made during patching can silently break a feature. Test each enabled feature after every patch release.
Confirm with your security team which destinations each enabled feature requires, and record that list as part of the change approval.
GitLab documents running self-managed instances in offline, air-gapped environments, and it provides separate guidance for GitLab security scanners and GitLab Duo Self-Hosted offline. Read the guidance for your target version in the offline environments documentation before you design the network, because it defines what must be carried into the environment.
- Duo guidance is a separate track: The offline material covers Duo Self-Hosted on its own terms. Plan the rollout around that guidance, and do not assume the general installation steps cover it.
- License delivery changes: Offline licensing works differently from online validation. Confirm with GitLab which offline add-on your seats need and how renewals are delivered.
- Updates need a transfer process: Packages, container images and model artifacts must cross the boundary through a process your security team approves. Patch releases twice a month means a recurring transfer cadence.
- Upgrade stops still apply: Required upgrade stops at x.2, x.5, x.8 and x.11 apply in offline environments too, so schedule transfers around them.
- Each feature needs confirmation: Do not assume any Duo capability works offline. Confirm each feature against the offline documentation for your version.
Ask GitLab in writing which features are documented for offline use on your target version, and get your security team to approve the transfer process before any hardware is ordered.
Enabling the Agent Platform in the right order
This sequence takes a self-managed GitLab instance from a version that supports the feature to a pilot group running agent sessions on models you host. Each step closes with a check, so the team confirms the result before moving on to the next step.
Confirm the GitLab version is 18.8 or later
The Agent Platform is generally available on self-hosted deployments from GitLab 18.8, so the platform team checks the running version in the Admin Area before installing anything else. If the instance runs an earlier version, the upgrade comes first. Done when the version shown in the Admin Area is 18.8 or later and the team has recorded it in the change ticket.
Confirm the upgrade path passes through required stops
If the instance is behind 18.8, GitLab requires the upgrade to pass through required upgrade stops. Since GitLab 17.5 those fall at versions ending in .2, .5, .8 and .11, so 18.8 is itself a stop. Use the upgrade paths documentation to map the route from your current version, and take a backup before each stop. Done when the team has a written sequence of stops to the target version.
Deploy the self-hosted AI gateway
The platform team installs the GitLab AI gateway at a location that both the GitLab instance and your model servers can reach, following the gateway's version alignment guidance. Network placement, TLS and access rules are set here and stay inside your infrastructure. Done when the gateway responds to a basic status request from a host on the instance network and the team has logged the response.
Serve the models behind the gateway
Host the chosen models on servers you control, expose them through an endpoint the gateway can call, and register that endpoint with the gateway. Accelerator capacity is a separate planning exercise that depends on the models and the number of concurrent developers. Done when a direct request to the model endpoint returns a response from inside your network and the gateway passes a test request through to the same model.
Validate model support for agentic features
Compare each candidate model against GitLab's support matrix for the Agent Platform and its agentic features. Support ratings can differ by feature and by model family, so record the rating for each feature rather than assuming a model family covers everything. Done when the team has a signed-off list of approved models, the features each model may use, and the gaps that are accepted or blocked.
Confirm the license and add-on before enabling
Check which add-on the deployment needs for the Agent Platform, and whether the environment is online or offline, because offline licensing is handled differently from seat-based access. Confirm the add-on and entitlements with GitLab before the pilot starts, and ask for the license terms in writing. Done when the license on the instance lists the Agent Platform entitlement the pilot requires.
Enable the feature for a pilot group
An administrator turns on the feature for a small group of users in the instance settings. Keep the group small enough that the platform team can watch the first sessions and read the logs. Done when a pilot user starts an agent session, the request reaches the gateway, and the session logs show the model the team approved in the previous step.
Check gateway and instance versions stay aligned
Record the GitLab instance version and the gateway version together in the runbook, then repeat the check before every GitLab upgrade and every gateway change. A gateway that drifts out of alignment with the instance can break agent sessions, so plan the gateway upgrade in the same window as the instance upgrade. Done when both versions are recorded and the team has a written rule for upgrading them together.
Why model support decides which agent features you can offer
Agentic features only work when the model behind them is supported for those features, and support can differ from one feature to the next. Before you promise developers an agent workflow, read GitLab's support matrix for each feature you plan to offer, such as Chat, Code Suggestions and the agent workflows themselves, and check the model family, version and deployment type in the same row. A model that is well rated for chat may be rated lower for multi-step agent tasks. Ratings are described as Full, Partial and Limited. Confirm the current definitions in GitLab's documentation before you write them into a design. In practice, a Full rating means you can plan for the feature as documented, a Partial rating means some capabilities or workflows may be missing or degraded, and a Limited rating means you should treat the feature as experimental for that model.
A pilot should test the exact model, quantization and version you intend to run, on the GitLab version and self-hosted AI gateway version you will deploy. Support matrices change with releases, and GitLab ships a minor release on the third Thursday of each month, so a rating you read in one month may not hold on the version you install later. Use representative tasks from your own repositories: multi-step changes, tool calls that touch CI configuration, long files and deliberately ambiguous prompts. Record which steps succeed, which fail and how the failures look to a developer. Those results, not the matrix alone, should decide which features go to your first group of users.
Model choice also sets your hardware and your offline path. Larger models need more accelerator memory, and the number of concurrent developers changes how many GPUs you need, so the model decision and capacity planning must be made together. A model you cannot serve inside your network does not help a fully offline deployment, which also depends on the Agent Platform Self-Hosted add-on for offline licensing. Read the sibling topics on choosing a model for GitLab Duo Self-Hosted and on GPU sizing for GitLab Duo Self-Hosted, then fix the feature list and the model together, before you commit to hardware or a rollout date.
Governance controls to settle before users get agent access
Agentic features read code, issues and pipeline data, and send requests to models, so access is a governance decision before it is a configuration task. The six controls below connect who can turn features on, what data agents see, how the gateway and models are maintained, and how changes and credentials are recorded. Settle each one in writing before the first user is enabled.
Who can enable agentic features
Decide which groups, subgroups and projects may use Agent Platform features, and who is allowed to change those settings. Start with a small pilot group and widen it only after review. Confirm with GitLab documentation which roles and settings control enablement on your version, because the exact permission names should come from the product docs rather than assumptions. Record the approver for each expansion.
Data agents can read and model traffic paths
Agents act on repositories, issues, merge requests and pipeline output that may contain regulated or confidential data. Map which projects and content an agent can reach, then confirm that every model request goes only to your self-hosted gateway and models. Check that no feature falls back to an external service, and test this with outbound network rules in place.
Gateway and model patch alignment
The self-hosted AI gateway, the GitLab instance and the model servers must move together. Set an owner for each component, a patch cadence and a rule for version alignment with GitLab releases. Tie this to the maintenance policy, which backports security fixes to more releases than bug fixes, so a stale gateway may still be exposed when GitLab itself is current.
Audit trail in your monitoring
Agent actions and gateway requests must land in logs your security team already watches. Decide what is logged at the GitLab, gateway and model layers, where it is forwarded, how long it is kept and who reviews it. Confirm which audit events the instance emits for agent activity, and test that a sample action appears in your SIEM before enabling broader access.
Scoped secrets for agent workflows
Agents that call external systems need credentials, and a broad token turns an agent into a wide-reaching identity. Create dedicated, least-privilege credentials for each workflow, store them in your secrets manager, and set expiry and rotation. Confirm how CI/CD variables and protected environments apply to agent-triggered jobs before allowing those jobs to deploy anything.
Change control for model versions
Changing a model or gateway version alters agent behavior, so treat it as a managed change. Require a test run against a fixed evaluation set, a recorded approval, a rollback target and a notice to pilot users before each switch. Keep the change record in GitLab so the approval, test evidence and deployment sit in one place for later review.
What buyers ask before a self-hosted Agent Platform rollout
How much does a self-hosted Agent Platform rollout cost?
The cost has four parts: GitLab licensing, model hardware or cloud capacity, the host for the self-hosted AI gateway, and the labor to design, integrate and validate the rollout. The GitLab pricing page publishes GitLab Premium at 29 US dollars per user per month billed annually, and lists Ultimate as custom priced. Both tiers are available for self-managed installations. Agent Platform features and their add-ons are licensed separately, so confirm with GitLab which seats or add-ons your deployment model needs. Licenses and compute recur each year, while design, integration and testing are usually one-time. DeployOpen does not publish a price list. A quote follows from a written scope, so ask for licensing, hardware and services as separate line items.
How long does a pilot take, and what drives the length?
The length depends on the scope you agree, so there is no fixed duration to plan around. The largest drivers are GPU procurement and delivery, the model family chosen against GitLab's support matrix, and whether the GitLab instance already runs a version that supports the feature. Network approvals for the AI gateway and model endpoints often take longer than the technical build. Offline constraints add transfer and validation steps. Identity integration, the number of pilot groups and the change approval process also set the pace. DeployOpen works on fixed-scope engagements, so scope, deliverables and timelines are agreed in writing before work starts. Ask for milestones tied to hardware arrival, gateway connection and a pilot exit review.
What does our team need to provide for the rollout?
Your team supplies the decisions and access that only your organization can give. Plan for the following:
Can our own team run a self-hosted Agent Platform without a partner?
Yes, if your team already runs self-managed GitLab, operates GPU servers and can keep the AI gateway and GitLab on aligned versions. The work that tends to stall internal teams is version management across GitLab releases, model serving operations, security review of model traffic and the time needed for upgrades. Read the GitLab upgrade paths documentation before you commit, because required upgrade stops affect the sequence of every change. A partner can plan, implement, harden, document and support the deployment inside your infrastructure, with ongoing support available as a retainer. Assess your team's capacity honestly against those duties before you decide.
How do offline and hybrid deployments differ in effort?
An offline deployment usually takes more effort than a hybrid one because every dependency must be brought inside your boundary. Hybrid deployments keep some features that send requests outside your network, so you review and approve those flows. Offline deployments remove that path, which means you must move installation packages, container images, model files and license material through an approved transfer process. Each feature must then be validated without internet access. GitLab documents offline environments and gives separate guidance for running GitLab Duo Self-Hosted offline, so read that guidance before you size the work. Ask any partner to state which features are excluded or changed in each mode.
How does maintenance work across GitLab releases?
Maintenance follows GitLab's published release cadence, and it needs a fixed owner. GitLab ships a minor release on the third Thursday of each month, patch releases twice a month and one major release a year. The GitLab maintenance policy states that bug fixes are backported only to the current stable release, while security fixes also go to the previous two monthly releases. Required upgrade stops still apply, so plan upgrades to land on stops. Keep the AI gateway, model servers and GitLab on compatible versions, and check the compatibility guidance for each release before you upgrade. Budget recurring time for testing each change in a non-production environment.
Limits to confirm in your environment before you commit
Duo Agent Platform on self-hosted models depends on several moving parts at once: the GitLab version, the model, the license, the network path and the hardware. Each item below is a point where a plan can look complete on paper and still fail at rollout, so confirm each one in GitLab's current documentation and with GitLab's sales or support team before you commit.
Version and agentic feature support
Agentic features are not all supported on every GitLab release. Check whether the specific agentic capabilities you need are supported on the GitLab version you run or plan to reach, and confirm that the self-hosted AI gateway version matches your GitLab instance. Ask GitLab to put the version pairing in writing for your target release, because a feature available in a newer minor release may not exist on the one your upgrade schedule lands on.
Model support rating
Each self-hosted model carries a support rating for each feature, and those ratings decide which features you can rely on. Confirm the rating for every feature you intend to use with the exact model family and size you plan to run, not with a model that is merely similar. A feature rated below the level your teams expect should be treated as a scope decision for the rollout, not a configuration detail to resolve later.
Add-on and license requirements
A self-hosted Duo deployment may need Duo seats, the Agent Platform Self-Hosted add-on, or usage-based billing, depending on whether the license is online or offline. Confirm with GitLab which add-on and license type your deployment requires, how seats are counted, and what changes if you later move between online and offline operation. Ask for the terms in writing, since the commercial model determines what your budget owner must approve.
Network connections your path requires
The path you choose determines which outbound and internal connections must exist. A hybrid setup may send some requests outside your network, while a fully offline deployment must function with no internet access at all. List every connection the gateway, the models and the GitLab instance need, then check each against your firewall, proxy and segmentation rules. Confirm with GitLab which features are unavailable in offline mode before you promise them to users.
Hardware for the expected concurrency
Serving a model is a capacity question, not only a compatibility question. Confirm that your accelerators can hold the chosen model at the quantization and context size GitLab supports, and that they can serve the number of developers who will use agentic features at the same time. Ask GitLab for the sizing guidance that matches your model and user count, and test with a realistic group of users before you buy hardware.
Upgrade schedule and required stops
GitLab ships monthly minor releases and requires upgrades to pass through required upgrade stops, so an agentic feature may depend on a release you reach only after a planned stop. Compare your upgrade calendar with the release cadence and the stop versions, and confirm that the Duo components can move with the GitLab instance without leaving a version gap. Plan the Duo upgrade in the same change window as the GitLab upgrade, not as a separate effort.
How DeployOpen scopes and delivers a self-hosted Duo Agent Platform rollout
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. For GitLab Duo Agent Platform on self-hosted models, we start with a written scope that settles model choice, gateway placement, licensing and governance before any rollout work begins.
How we scope
- Confirm your GitLab edition, version and whether the instance runs online or fully offline before choosing add-ons.
- Map which Agent Platform features your teams need against the model support ratings published for your GitLab release.
- Record gateway placement, network paths, GPU or hosting location and which outbound connections each feature requires.
- Agree governance controls, user groups and approval steps in writing, with deliverables and timelines fixed before work starts.
How we build
- Install and align the self-hosted AI gateway with your GitLab version, following the documented version match requirements.
- Connect your chosen self-hosted models and verify each enabled agentic feature against the support matrix for your release.
- Configure access, group permissions and audit logging so agent actions follow your existing access model.
- Test agent behavior in a staging instance, including offline behavior, failure handling and rollback steps before production.
How we hand over
- Document the architecture, version alignment, upgrade stops and the configuration decisions behind each setting.
- Provide runbooks for enabling features, rotating credentials, adding models and responding to gateway or model outages.
- Walk your platform, security and compliance owners through the controls and the evidence they can use in assessments.
- Deliver the written record of what was scoped, built, tested and changed so your team can run the rollout without us.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial rollout.
- Plan each GitLab upgrade against the required upgrade stops, then retest agentic features and the gateway after each step.
- Review model support changes in new releases and agree with you which features to enable, hold or retire.
- Confirm with your GitLab account team and licensing contacts which add-ons and usage terms apply before each renewal.
