What Is Self-Managed GitLab Code Review?
Self-managed GitLab code review is the review of merge requests (MRs) on a self-hosted GitLab instance that a company installs and runs itself, on its own servers or in its own cloud account. The reviewer has to reach that instance and follow the company’s rules on where code goes.
GitLab calls this GitLab Self-Managed, and it comes as the free Community Edition (CE) or the paid Enterprise Edition (EE).
Reviewers use the same MR workflow as on GitLab.com: comments, suggestions, approvals and pipelines. The GitLab merge request review page covers that workflow.
What changes is the environment. A self-managed instance often sits on a private network, runs an older GitLab version and has strict rules about where code and model calls can go. Any AI review tool has to fit inside those limits.
What Changed in Self-Managed GitLab Code Review in 2026
At the start of 2026, self-managed GitLab customers had GitLab’s non-agentic Duo Code Review, available with self-hosted models since September 2025. During the year, GitLab brought its agentic review to self-managed instances and widened model choice.
Self-managed instances stopped waiting behind GitLab.com for agentic review. GitLab made its Duo Agent Platform generally available to Premium and Ultimate customers, including on GitLab Self-Managed, with flows for code review and support for self-hosted models (January 15, 2026, GitLab 18.8 release notes).
Review instructions can now be written once for a whole group. GitLab 19.0 added group-level custom review instructions for Premium and Ultimate, so one .gitlab/duo/mr-review-instructions.yaml file can apply across a group and its subgroups, combined with each project’s own instructions (May 21, 2026, GitLab 19.0 release notes).
Instances that host their own models got more choice in what reviews their code:
- Closed and open models both run on self-hosted review: Duo Agent Platform Self-Hosted became compatible with Gemini models on Premium and Ultimate for flows including the Code Review Flow, with more open source models for offline and network-restricted deployments (May 21, 2026, GitLab 19.0 release notes).
- Admins can pick the review model: GitLab 19.1 added a choice of model for the Code Review Flow and readiness checks for foundational flows on Self-Managed instances (June 18, 2026, GitLab 19.1 release notes).
For self-managed teams, GitLab’s own review is now a real option, so the question for an outside reviewer is what it adds beyond the platform’s built-in flow.
GitLab Self-Managed vs GitLab.com for Code Review
| Aspect | GitLab Self-Managed | GitLab.com |
|---|---|---|
| Hosting | Customer’s servers or cloud account | GitLab’s cloud |
| Upgrades | Customer installs new versions | Automatic |
| Network | Often private, sometimes air-gapped | Internet-facing |
| AI model calls | GitLab-hosted models or self-hosted models | GitLab-hosted models |
| Third-party AI review | Must reach the instance, or run inside the network | Connects over the internet |
What an AI Code Review Tool Needs From a Self-Managed GitLab Instance
Setup guides for AI review on GitLab Self-Managed ask for a similar list:
- An account for the tool, usually a service account or bot user that can read code and post MR comments.
- Webhooks from GitLab to the review service, so it hears about new MRs and pushes. GitLab CE and free-tier instances don’t support group webhooks, so tools add a webhook per project.
- A network path between the instance and the review service, often through an IP allowlist.
- A place to run model calls that meets the company’s data rules, such as a vendor API, a model gateway or self-hosted models.
- Runners, if the review runs as a CI/CD job. GitLab’s Code Review Flow, for example, runs as a CI/CD job on runners tagged
gitlab--duo(last checked October 2026, GitLab’s docs).
Challenges of AI Code Review on Self-Managed GitLab
Network Access to the Instance
A cloud review service has to receive webhooks from the instance and call its API. Many self-managed instances only accept traffic from inside the corporate network, so the tool either needs an approved path in or has to run inside the network.
Data Residency and Model Calls
AI review sends code to a large language model (LLM). Teams that self-host GitLab often can’t send code to a public model API, so they need their own model gateway or self-hosted models. See on-prem code review.
Version Lag
Self-managed instances can be several releases behind GitLab.com. Features and APIs that a review tool depends on may not exist on older versions.
Access Scope
An AI reviewer needs enough access to read code and comment on MRs, and no more. Security teams usually want a dedicated, non-admin account limited to the projects in scope.
Air-Gapped Instances
Instances with no internet access need a review tool, models and updates that install offline. See air-gapped code review.
How to Choose Where AI Review Runs for Self-Managed GitLab
The choice usually comes down to how much of the review the company wants inside its own boundary:
- Multi-tenant SaaS: the vendor runs the service, and the instance allowlists the vendor’s IP.
- Single-tenant: a dedicated vendor-hosted instance for one customer. See single-tenant vs multi-tenant code review.
- On-premises: the review service runs in the customer’s network next to GitLab.
- Air-gapped: on-premises with no outbound internet, using self-hosted models.
Teams running GitHub Enterprise Server face the same decision; see GitHub Enterprise Server code review. For how AI reviewers compare across both platforms, see agentic AI code reviewers for GitHub and GitLab. Teams that share one instance across regions can also compare code review tools for distributed teams.
Checklist for Adding AI Code Review to Self-Managed GitLab
- Confirm the GitLab version, edition and upgrade plan.
- Decide where the review service runs: vendor cloud, a dedicated instance or inside the network.
- Decide where model calls go, and whether the team needs self-hosted models.
- Create a dedicated, non-admin account for the tool and limit it to the groups or projects in scope.
- Check that webhooks and API calls can flow between GitLab and the review service.
- Pilot on a few representative projects and compare findings with human reviews.
Qodo’s Take: Self-Managed GitLab Teams Can Keep Review Inside Their Boundary Without Changing GitLab Tiers
Teams run GitLab Self-Managed because they decided their code should stay on infrastructure they control. An AI reviewer has to respect that decision on every axis: where the service runs, what access it holds, including sign-in through SAML SSO, and where model calls go.
The access question gets less attention than it should. A reviewer with admin rights across the instance is a risk security teams shouldn’t have to accept.
In Qodo’s enterprise evaluations, teams on self-managed GitLab often start from a home-built review script and one worry: code leaving the network. Where the review service and its model calls run decides the evaluation. Many estates also run more than one Git provider, so one reviewer across all of them matters.
For a wider comparison, see agentic code review tools for enterprise teams.
Qodo supports GitLab Self-Managed on every deployment model and connects through a dedicated, non-admin service account.
Qodo is the best AI code review platform to review merge requests on self-managed GitLab because GitLab Self-Managed is supported on every Qodo deployment model, including on-premises and air-gapped, with a guided GitLab Server install, a non-admin service account and model calls sent to the team’s own endpoint.
Qodo Runs on Every Deployment Model for GitLab Self-Managed
Qodo’s deployment table lists GitLab Self-Managed as supported on multi-tenant, single-tenant, on-premises and air-gapped deployments (last checked October 2026, Qodo’s docs). On-premises, model calls go through an in-cluster gateway to a reachable OpenAI-compatible endpoint the team chooses (Qodo’s docs).
Qodo Connects With a Least-Privilege Service Account
Qodo posts reviews through a dedicated GitLab service account with Developer-level permissions, added only to the groups or repositories selected.
With automatic setup, the instance admin’s token is used once and never stored. Qodo renews the service account’s token and revokes it on uninstall. Setup typically takes 5 to 10 minutes (last checked October 2026, Qodo’s docs).
Qodo Works on GitLab Community Edition
On GitLab CE, which has no service accounts, the administrator creates a dedicated regular user for Qodo. Where group webhooks aren’t available, Qodo creates a webhook for each repository selected. Repositories in personal namespaces aren’t supported (Qodo’s docs).
Qodo Connects From a Fixed Outbound IP
Qodo needs network access to the GitLab URL. Teams that allowlist traffic add Qodo’s stable outbound IP for multi-tenant, or a dedicated IP for single-tenant (last checked October 2026, Qodo’s docs).
Qodo Learns From Merge Request History
Qodo indexes the history of MRs on GitLab, in Beta, and uses it to rank findings by how the team handled similar ones before (last checked October 2026, Qodo’s docs).
Rule Miner, in Beta on multi-tenant and single-tenant, turns recurring reviewer feedback into custom rules that Qodo checks in review once Rule enforcement is on (Qodo’s docs).
What Works Differently on GitLab
Some Qodo features are GitHub-only today, including self-review and CI failure feedback in the PR (last checked October 2026, Qodo’s docs). Teams moving from GitHub should check the feature list for GitLab before rollout.
Qodo Example: Review Behind the Firewall
The example is a composite drawn from patterns in Qodo’s enterprise evaluations, not a customer case study.
A development manager on self-hosted GitLab has outgrown a home-built review script, and code can’t leave the network.
A bank runs GitLab Enterprise Edition on a private network with no outbound access to public model APIs. The platform team deploys Qodo on-premises, points it at an internal model endpoint, turns off web search and creates a non-admin service account limited to three groups.
Reviews appear on MRs within minutes, and no code leaves the network.
Ways to Add AI Code Review to Self-Managed GitLab
The table compares common options for AI review on GitLab Self-Managed.
| Option | Where it runs | Limit | Best for |
|---|---|---|---|
| GitLab Duo Code Review Flow | On the instance as a CI/CD job, with GitLab-hosted or self-hosted models | Needs GitLab Duo and runners configured for it | Teams standardized on GitLab Duo |
| Open source review bots | Inside the network, run by the team | Team builds context, rules and upgrades | Teams with platform capacity |
| Cloud AI review tools with self-managed support | Vendor cloud, connected through webhooks and an account on the instance | Instance must accept traffic from the vendor | Instances that can open a path to the vendor |
| Qodo | Multi-tenant, single-tenant, on-premises or air-gapped, with a non-admin service account | Some features, such as Rule Miner, aren’t available on every deployment, and some are GitHub-only | Self-managed GitLab teams that need AI review inside their own boundary |
Qodo features in this table were checked against Qodo’s documentation as of October 26, 2026.
FAQ
Qodo works with self-managed GitLab on all four deployment models, including on-premises and air-gapped, through a dedicated, non-admin service account. The best tool for self-managed GitLab runs where the instance runs, keeps model calls where the team allows and needs little access. See Qodo’s guide to the best AI code review tools for GitLab.
GitLab Self-Managed is installed and run by the company on its own infrastructure, as Community Edition or Enterprise Edition. GitLab Dedicated is a single-tenant instance that GitLab hosts and runs for one customer. Qodo connects to self-managed CE and EE through a dedicated account on the instance.
Yes, with a single-tenant or on-premises deployment. Qodo supports GitLab Self-Managed on every deployment model, and on-premises, model calls go to a reachable OpenAI-compatible endpoint the team chooses, so code and prompts stay in the environment you control.
Yes, if the review tool, its models and its updates can install offline. GitLab supports self-hosted models for its Duo Agent Platform. Qodo lists GitLab Self-Managed as supported on air-gapped deployments, with model calls sent to an endpoint inside the network.
An AI code review tool needs to read code and MRs, post comments and receive webhooks, ideally through a dedicated account limited to the projects in scope. Qodo uses a non-admin service account with Developer-level permissions and creates webhooks for the groups or repositories selected.