GitLab Duo Self-Hosted add-ons and licensing

Which GitLab Duo add-on does a self-hosted deployment need?

The add-on a self-hosted Duo deployment needs depends on two things: whether the instance runs on an offline license or an online license, and whether that license is sold with Duo seats or with usage-based billing. Settle this before you size GPU servers or pick a model family, because the licensing path shapes what the instance can reach and what you pay each year. DeployOpen plans and implements these deployments, including the self-hosted AI gateway and the models behind it, but it does not set or quote GitLab's prices. The final licensing terms come from GitLab, and DeployOpen's written scope covers implementation work only.

Start with the base tier, because Duo add-ons sit on top of a GitLab edition. The GitLab pricing page lists Free at 0 US dollars, Premium at 29 US dollars per user per month billed annually, and Ultimate as custom priced, with all three available for self-managed installations. Confirm with GitLab whether Duo is bundled with a tier or sold separately, and whether the quote is per seat, per usage or a mix. If the instance must run with no internet connectivity, read the GitLab offline environments guidance, which covers Duo Self-Hosted offline as its own topic. Ask GitLab how the license is issued, renewed and loaded into an isolated instance before you commit.

Settle the license before hardware and model decisions, because several later choices depend on it. The offline path involves the Agent Platform Self-Hosted add-on, which changes what you must confirm about gateway and model placement, so an offline buyer should not size servers from an online assumption. Ask GitLab for a written quote that names the tier, the Duo seat count or usage basis, the add-on, the billing period, the renewal date and the GitLab version the license covers. Also ask whether the terms allow for planned seat growth. Keep that quote alongside the scope agreed with DeployOpen so the two match before any GPU order is placed.

Duo Enterprise seats, Agent Platform Self-Hosted and usage billing compared

This table compares the three licensing paths a self-hosted Duo deployment can use: Duo Enterprise seats, the Agent Platform Self-Hosted add-on for offline licenses, and usage-based billing for online licenses. Read each row against your connectivity model and your rollout plan, then confirm the current terms and feature lists with GitLab before you commit.

License path	What it covers	When it fits and what to confirm
Duo Enterprise seats	Per-user access to GitLab Duo features on a self-managed instance, applied to the users who will use Duo	Fits connected or hybrid deployments with a known developer population. Confirm the seat terms, which features each seat includes, and whether your instance tier and license type qualify
Agent Platform Self-Hosted add-on	Agentic Duo capabilities for offline licenses, so the self-managed instance can run without internet connectivity	Fits fully offline or air-gapped deployments. Confirm that the add-on is required with your offline license, which Agent Platform features it unlocks, and how it is renewed
Usage-based billing for online licenses	Consumption-based charging tied to Duo usage on an online license, rather than fixed seats	Fits connected deployments with uneven or uncertain usage. Confirm the metered units, how usage is reported from your instance, and what happens when a usage cap or threshold is reached
Recurring cost	Seat or subscription fees, add-on renewals or metered usage charges, depending on the path chosen	Recurs on each renewal period or billing cycle. Ask GitLab for the billing frequency, renewal terms and how price changes apply during a term
Connectivity requirement	Whether the license type allows the instance to reach GitLab services, which decides the add-on or billing path	Offline paths keep traffic inside your network. Confirm which Duo features send data outside the instance under each path before you select one
Model and gateway placement	Self-hosted models and the self-hosted AI gateway run in your infrastructure under any path, but support scope can differ	Confirm in writing which configurations each license path supports, including mixing self-hosted models with hosted model providers
Feature availability	Which Duo and Agent Platform features each option includes, and which depend on GitLab version or tier	Request the current feature list per option from GitLab, then map it to the use cases your teams need before comparing options
Quote basis	Terms are set by GitLab and by your written scope with any partner, not by a public price list in this page	Ask for the current terms, the feature list for each option, renewal conditions and a written quote that names your user count or usage assumptions

Online licenses versus offline licenses for Duo

When the GitLab instance and its AI gateway can reach GitLab's services over the network, the online license model applies. The license is activated against GitLab's service, and usage is reported so that consumption can be billed under the usage-based model for online licenses. Connectivity also means some Duo features can call services outside your network, so the feature list and the data path need to be reviewed together.

Activation: The instance must reach the endpoints the activation process uses, so confirm them with GitLab and allow them in your egress rules.
Usage reporting: Usage data leaves your network for billing, so security, finance and procurement should agree on exactly what is reported.
Feature dependencies: Some Duo features may send prompts or code to external model providers or GitLab-hosted services depending on configuration. Confirm which ones apply to your version.
Maintenance: Gateway and instance upgrades are easier to schedule when packages and images can be pulled through your normal channels.

Check which endpoints must be reachable, what usage data is reported, and whether any feature you plan to enable sends data outside your environment.

How the base GitLab tier and Duo seats fit together

Duo is bought on top of a GitLab self-managed tier, and the two costs are separate. Your base tier covers the GitLab instance itself: source control, merge requests, CI/CD and the security features each tier includes. Duo entitlements are a further layer that sits alongside that base. The public pricing page lists GitLab Free at 0 US dollars, Premium at 29 US dollars per user per month billed annually, and Ultimate as custom priced, with all three tiers available for self-managed installations. A budget that only counts Premium or Ultimate seats will miss the Duo line, and a budget that only counts Duo will miss the base tier you need to host it.

The tier you choose changes what your teams get beyond AI. Per the pricing page, Premium lists advanced CI/CD and priority support, while Ultimate lists application security testing, software supply chain security, vulnerability management and compliance features. If your security or audit team expects those controls, the tier decision belongs in the same review as the Duo decision, not after it. Ask GitLab in writing which tier and which Duo entitlement each user group needs, and whether those entitlements are included with the tier or sold separately, before you count seats.

Seat counts are the step most likely to be wrong, so reconcile them against your identity records before you request a quote. Confirm with GitLab whether a licensed user is counted by active account, by billable seat or by some other measure, how service accounts and bot users are treated, and how seat changes are prorated during the year. Ask for the renewal and true-up terms in the same document. Also confirm which Duo features each tier unlocks on a self-managed instance, since a feature list on a marketing page may not match the entitlement in your license file.

Cost components and what drives them up

A self-hosted Duo deployment combines a GitLab tier, a Duo entitlement, a license type and the hardware and people that run it. Each line has a different payee, a different billing rhythm and different drivers, so a quote should show them separately.

Base GitLab tier seats

Every user on a self-managed instance needs a paid tier seat, and this is usually the largest recurring line. GitLab's pricing page lists Premium at a per-user rate billed annually, so user count is the first driver. Ask whether the quote covers service accounts, bot users and deactivated users, and whether Geo is included, since it is available from Premium. Seat counts set at signing often become the baseline for later true-ups.

Duo seats or add-on entitlement

Duo access is licensed separately from the base tier, through Duo Enterprise seats or the Agent Platform Self-Hosted add-on, depending on how the instance is licensed. Paid to GitLab, it recurs by term. Drivers are how many developers receive Duo, which features are included and whether agentic features are in scope. Confirm the exact SKU that covers offline Duo before you size hardware, because the wrong entitlement can block features at go-live.

Offline license terms

Air-gapped instances cannot report usage over the internet, so their license is managed as an offline file with its own term and renewal. Paid to GitLab, it recurs at each renewal. Cost and risk rise with seat growth that needs mid-term changes and with long gaps between renewals. Ask for the term length, the true-up process, how seat counts are reconciled manually, and what happens if a license expires while the instance is running.

Usage-based charges

Online licenses for Duo can bill on usage rather than on a fixed seat count, so this line is recurring and variable. Paid to GitLab, it grows with how many developers use AI features concurrently and how often agentic workflows run. Ask for the metering unit, how often usage is reported, whether there are spending caps, and what alerts fire before a limit is reached. Model the spend at your busiest sprint, not your average week.

Model hosting and GPU hardware

Models and the AI gateway run on your own GPUs or on a cloud or private platform you choose. On-premises purchases are mostly one-time, with recurring power, support and refresh costs. Cloud GPU capacity recurs by usage. Drivers include model size, concurrent developers, the number of model and gateway instances, and whether you add redundancy or spare capacity for offline operation. Ask hardware vendors for GPU counts tied to a named model and concurrency level.

Internal or partner effort

Planning, licensing reviews, installation, model validation and rollout are paid as staff time or partner fees, and are mostly one-time. Upgrades and operations recur. Drivers are the number of GitLab instances, offline status, the number of required upgrade stops you must cross and whether you run high availability. GitLab's documentation generally recommends high availability from 3,000 users, which raises both build and run effort. Ask for effort by phase in any written scope.

Licensing sequence before a self-hosted Duo rollout

This sequence confirms the GitLab base that Duo depends on, selects the license path that matches your network, and ends with Duo features verified on the instance and the AI gateway. Each step produces a record you can check before any user relies on the feature.

Confirm the base tier and user count
Start by recording which GitLab edition and tier the instance runs today, along with the number of users who will need Duo. Pull the current counts from the GitLab admin area and compare them with the tier your organization has licensed. Duo is sold on top of a self-managed base subscription, so the base tier and seat count set the ceiling for every later step. Done means you have a signed-off sheet with edition, tier, and user count that the rest of the sequence references.
Decide online or offline licensing
Decide whether the instance will check in with GitLab over the internet or run as a fully offline, air-gapped deployment. This choice determines which add-on path applies, because offline licenses and online licenses are handled differently for Duo. Involve the network and security owners early, since an offline deployment also changes how models and the AI gateway are delivered and updated. Done means the decision is written down with the network boundary it assumes, and the team has confirmed that boundary with the people who own it.
Choose the Duo seat or add-on path
Map the decision from the previous step to a licensing path. Confirm with GitLab whether your offline license needs the Agent Platform Self-Hosted add-on, and whether your online license should use Duo Enterprise seats or usage-based billing. Check which Duo features each option entitles so you do not assume coverage that the contract omits. Done means you have a one-page comparison that names the product, the billing model, and the features each user group will receive.
Get a written quote with license terms
Request a written quote that is based on the scope from the previous step, and ask the vendor or reseller to state the license terms in the same document. Ask what recurs (seats or usage), what is one-time, how renewals are priced, and what happens when user counts or usage rise above the quoted amount. GitLab publishes Premium and Free pricing on its pricing page, while Ultimate is custom priced, so expect Duo terms to come from a direct quote rather than a public list. Done means you hold a signed quote and license terms that match the path you chose.
Activate the license on the GitLab instance
Upload or enter the license in the GitLab instance by an administrator, then confirm the subscription details shown in the admin area match the quote. Check the start date, expiry, seat count, and any add-on names against the signed document before continuing. Record who performed the activation and when, since this becomes part of your change evidence. Done means the admin area shows an active license with the expected subscription and no mismatch in seats or add-ons.
Confirm Duo entitlements for test users
Sign in as a small set of test users who represent each licensed group, and confirm that the Duo features they should see are visible and the ones they should not see are absent. Compare the results with the entitlement list in the admin area and the feature list from your quote. Mismatches usually mean a seat is not assigned or an add-on is missing, so resolve them before wider rollout. Done means every test user's view matches the written feature list, and the results are saved with the test date.
Verify AI gateway and model connections
Run a connectivity test from the GitLab instance to the self-hosted AI gateway, and from the gateway to the models it serves. In an offline network, confirm that all required endpoints resolve inside the boundary and that nothing attempts an outbound call. Check that the gateway and model versions are aligned with the GitLab version and that the enabled features match the licensed entitlements. Done means the connectivity tests pass, the gateway reports the expected features, and the results are filed with the license record.

What the offline add-on changes for air-gapped teams

In an air-gapped network, the licensing conversation starts with how the license and every update reach the instance, not with seat counts. The Agent Platform Self-Hosted add-on is the route for offline licensing, so the license file, the update packages and the installation media all have to cross the network boundary through your approved transfer process. Before you order, confirm with GitLab how the offline license is issued and renewed, and whether your team needs a separate process for each renewal. GitLab's offline environments guidance documents running self-managed instances without internet access, with separate guidance for running GitLab Duo Self-Hosted offline, so use that page as the reference for what your deployment must contain.

The model and gateway components also have to run inside the network. Nothing in a fully offline Duo deployment can call out to a hosted model or a public endpoint, so the self-hosted AI gateway, the models and their serving infrastructure must be in place and staged before go-live. Choose the installation method for the GitLab instance early, because the Linux package, the Helm chart, the GitLab Operator and Docker each change how packages are mirrored and updated. The installation methods page lists these options and is the right place to confirm which one your platform team can support offline.

Version alignment is the decision that must be made before the offline license is ordered. Confirm the GitLab release, the AI gateway release and the GitLab Runner release you will run, and check that the Runner major and minor versions match GitLab, as GitLab advises. Then map that target against GitLab's required upgrade stops and its maintenance policy, which limits which releases receive backported fixes. Your update cadence must fit the transfer process: if a monthly minor release and twice-monthly patch releases cannot be carried across the boundary on time, plan for a slower, deliberate upgrade schedule that stays within a supported release, and ask your vendor and GitLab what that means for security fixes before you commit.

Limits to confirm with GitLab before you buy

Duo Self-Hosted licensing depends on your edition, your GitLab version, how your instance connects to the internet and how usage is counted. The answers come from GitLab's current terms and your own version, and DeployOpen will not confirm them on GitLab's behalf, so get each one in writing before you sign.

Feature coverage by license

Confirm which Duo features each license type includes at the GitLab version you run or plan to run. Feature availability can differ between Duo seats, the Agent Platform Self-Hosted add-on and online usage billing, so ask GitLab for a per-feature table tied to your version. Keep the answer with your purchase record, because a feature listed for a later release may not be available on your current version.

Agent Platform add-on fit

Ask whether the Agent Platform Self-Hosted add-on applies to your deployment model. It is the route tied to offline licensing, so an online instance with a self-hosted gateway may not need it. Confirm which add-on your setup requires, and whether it is sold alongside or instead of Duo seats. Get this answer for your exact topology before you order.

How usage is measured

For online licenses, ask how GitLab counts usage: per request, per token, per seat or per active user. Confirm which events are metered, how often the counts are reported and where you can view them. Ask for an example calculation based on a usage profile similar to yours, and confirm whether usage is capped, alerted or billed in arrears.

Outbound connectivity requirements

Identify which Duo features send data to GitLab-hosted services, even when models run on your hardware. Offline and air-gapped deployments can only use features that work without outside calls, so map each feature you plan to enable against your network policy. Ask GitLab to name the endpoints each feature needs, and check that your firewall rules and proxies allow them.

Minimum version for self-hosted Duo

Confirm the earliest GitLab version that supports each self-hosted Duo capability you need, including the Duo Agent Platform. Check that your AI gateway and GitLab instance are on compatible versions, and plan upgrades around GitLab's required upgrade stops. If a feature you bought only arrives in a later version, ask GitLab for the date and the remedy if it slips.

Renewal and true-up terms

Ask how seat counts change during the term, whether you can add seats mid-term and how true-up charges are calculated when usage or headcount exceeds the order. Confirm renewal pricing, notice periods and what happens to offline licenses if a renewal lapses. Ask for these terms in the order form, not only in a sales email.

Questions buyers ask about Duo licensing and effort

What determines the cost of a self-hosted Duo license?

The cost follows three things: the add-on that fits your deployment, the number of seats, and the billing model. Duo Enterprise seats are counted per user, the Agent Platform Self-Hosted add-on applies to offline licenses, and online licenses can be billed by usage. GitLab's pricing page publishes list prices for its core tiers, including Premium at 29 US dollars per user per month billed annually, but you should confirm current Duo add-on rates and any base tier requirement with GitLab before you budget. Ask for the seat count, license type, billing term and usage metering rules in writing. Your own costs also include the GPU servers, storage and staff time that the models and gateway need, and those sit outside the license line.

Can I buy the Duo add-on without a base GitLab tier?

Treat the base GitLab subscription and the Duo add-on as separate lines, and confirm with GitLab which base tier each Duo add-on requires before you assume either way. The pricing page lists Premium and the higher tier as self-managed options, with advanced CI/CD and priority support on Premium and security, compliance and supply chain features on the higher tier. Your instance's existing tier may already settle the question, but a mismatch between the base tier and the add-on can delay activation. Ask GitLab for a written statement that names the required base tier, the add-on product, and any minimum seat count.

How long does Duo licensing and activation take to set up?

No activation timeline was supplied for this page, so ask GitLab for its activation steps and lead time in writing. The schedule is usually set by internal work: buying the license, loading it onto an instance you control, confirming the instance version, and aligning the AI gateway and models with that version. The Duo Agent Platform became generally available on self-hosted deployments from GitLab 18.8, so an instance on an earlier version may need upgrading first. Upgrades must pass through required stops, and 18.8 is one of them, so plan the upgrade path before you schedule activation. Ask your DeployOpen contact to show the dependencies in the written scope so you can see which steps block which.

What does the Duo work need from our team?

The work needs four named owners before implementation starts. A license administrator holds the GitLab account, approves seat counts and tracks renewal dates. A network owner confirms how the instance reaches GitLab services in an online deployment, or confirms an isolated network for an offline one. A GPU owner decides where the models run and how much capacity is available for concurrent developers. An identity owner confirms which users receive Duo access through your existing sign-in. Each owner should approve the parts of the written scope that touch their systems, so that licensing, network, hardware and access decisions are made once and recorded.

Can our team handle Duo licensing internally?

Yes, if you have a license administrator who can work through GitLab's licensing documentation and an engineer who can operate the instance. Buying, loading and tracking the license is administrative work that internal teams can do. Outside help tends to matter in design choices: which add-on fits offline or online operation, how the self-hosted gateway and models are placed, and how Duo features are tested before rollout. Compare the internal hours and skill gaps against a fixed-scope quote in writing. DeployOpen plans, implements, hardens and documents self-hosted platforms in your own infrastructure and prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications.

What does a DeployOpen quote cover, and what do GitLab's license terms cover?

A DeployOpen quote covers the work listed in the written scope, such as planning, configuration, implementation, testing and documentation, with deliverables and timelines agreed before work starts. It does not replace the GitLab subscription, which is a separate agreement with GitLab. GitLab's license terms govern what you may run, how many users you may license and how usage is measured. Ask DeployOpen to list which licensing tasks it performs and which stay with your team, and ask GitLab to confirm the seat, term and metering rules in writing. Review both documents before you sign, since each covers a different part of the spend and the risk.

What changes between online and offline Duo licenses?

An offline license applies to instances with no internet connectivity, and that is the case where the Agent Platform Self-Hosted add-on applies. An online license keeps a connection to GitLab and can be billed by usage. GitLab publishes offline environment guidance with separate steps for running Duo Self-Hosted offline, so an offline deployment needs its own plan for models, the gateway and updates that arrive by approved transfer. Expect more lead time for each release because packages must be moved into the network. Ask GitLab which Duo features the offline path supports, how renewal and usage reporting work without a connection, and what update path applies.

How DeployOpen works on this

DeployOpen is a Chainscore Labs company that plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For GitLab Duo Self-Hosted, we start by confirming which add-on and licensing model your deployment needs, then build and hand over only what the written scope covers.

How we scope

Confirm whether your instance needs offline licensing or an online license with usage-based billing before any design work starts.
Record the Duo Enterprise seat count and Agent Platform Self-Hosted requirements in the written scope with named owners.
Confirm with GitLab which add-on terms, license type and tier your instance and users actually need.

How we build

Map which Duo features would send data outside your network and plan the offline configuration for each one.
Align the GitLab instance, self-hosted AI gateway and model servers on versions that GitLab documents as compatible.
Test license activation, seat assignment and feature access on a staging instance before production rollout.

How we hand over

Deliver a license and entitlement record listing add-ons, seat counts, renewal dates and the owner of each item.
Document the licensing decision, the upgrade behavior of each add-on and the steps to renew or change seats.
Walk your platform and procurement teams through the handover so they can answer quote and renewal questions themselves.

How we support

Review seat usage and license status on a schedule agreed in the written scope or a support retainer.
Plan license changes alongside GitLab upgrades, including required upgrade stops, before each change window.
Update the entitlement record and runbook when GitLab changes add-on terms or when your user count changes.