Self-Hosted Code Review: GitLab Self-Managed + VS Code 2026

Self-Hosted Code Review: GitLab Self-Managed + VS Code 2026

You picked GitLab Self-Managed for a reason. The data lives in your datacenter, the audit trail stays in your control, and you do not have to file a ticket with Atlassian or GitHub when a compliance auditor asks where the source code went last Tuesday. Then you sit down to add AI code review on top, and every vendor's first question is "what is the public URL of your GitLab instance?" — which is exactly the question you went self-hosted to avoid. The good options are narrower than they look, and the cost math is more sensitive to license tier than the marketing pages let on.

This guide is for the team that already runs GitLab CE or EE on-prem and wants AI in the merge request loop without sending code through a third-party cloud or paying $580/month per ten developers for a feature buried in an enterprise add-on. We will walk through what each tier actually gives you, where the built-in VS Code extension stops being useful, and the trade-offs between Duo, CodeRabbit, Greptile, and a fully outbound-only setup with Git AutoReview.

TL;DR: GitLab Duo Code Review is a real product but lives behind Premium + a $39/user/mo Duo Enterprise add-on — about $580/mo for 10 devs, with cloud connectivity required by default. The official VS Code extension can read merge requests but cannot post new comments. CodeRabbit's webhook architecture needs your GitLab instance publicly accessible, which kills it for most internal deployments. Git AutoReview runs outbound-only from VS Code, supports CE Free through Ultimate, and keeps code flowing directly from your developer's machine to your chosen AI provider — no third-party cloud, no inbound webhooks, no public URL required.

Why teams pick GitLab Self-Managed in the first place

Three reasons come up over and over when teams justify the operational overhead of running their own GitLab instance. None of them are about features that GitLab.com is missing — they are about who holds the keys.

Full data control. The repositories, the merge request metadata, the CI logs, the secrets in CI variables, the audit trail of who pushed what when — all of it stays on infrastructure you own. For finance teams, defense contractors, healthcare, and anyone working under client contracts that explicitly forbid third-party SaaS for source code, this is non-negotiable. The compliance argument is more about predictability than about regulations mandating on-prem: very few standards actually require it, but having full data control simplifies every audit conversation because the answer is always "it is on our hardware, here is the access log."

Predictable cost at scale. GitLab.com Premium runs $29/user/mo. Self-Managed Premium is $19/user/mo on annual billing — that is $10/user/mo cheaper before you count the hardware and ops time. The math flips for small teams (the infrastructure cost dominates under ~25 paid seats), but at 100+ seats the self-managed license is the cheaper line item even with a half-time SRE running the cluster. The savings are real but boring. The control argument is what actually closes the decision.

No third-party dependency. Every SaaS dependency is a runtime risk. GitLab.com going down means your team cannot merge. GitLab.com getting hacked means your code is in the breach report. GitLab.com changing its pricing means your CFO has a new line to manage. Self-managed converts all of those uncertainties into a known operational cost — and for risk-averse organizations, "known cost" beats "smaller cost" every time.

What GitLab's built-in code review gives you by tier

GitLab's tier matrix has changed enough over the past three years that it is worth pinning down what you actually get on each plan before adding AI on top. The shape of the table below is the May 2026 pricing, verified against GitLab's pricing page.

The interesting tier line is between Free and Premium. CE is genuinely capable for small teams — you can assign reviewers, leave comments, request changes, and merge. What you cannot do on Free is enforce that a merge request needs N approvals from specific people before the merge button activates. That gate is a Premium feature, and for any team operating under a compliance regime that requires segregation of duties, Premium is the floor.

Ultimate is harder to justify on code review alone. The features it adds over Premium are mostly security policy-as-code, vulnerability management, and the Suggested Reviewers ML feature — all useful, none of which most teams would spend $80/user/mo extra to get. The honest framing: you buy Ultimate for the security suite and inherit Suggested Reviewers as a side benefit, not the other way around.

The VS Code problem — read-only is not good enough

GitLab's official VS Code extension (GitLab.gitlab-workflow) has 3,084,319 installs and a 3.5/5 rating across 89 reviews. It supports self-managed instances out of the box — drop in your URL and a Personal Access Token, and the extension pulls merge requests directly into your editor. You can read the diff with full VS Code power: search across files, jump to definitions, see related code in tabs, run the test suite in the integrated terminal without leaving the editor.

Then you try to leave a comment and hit the wall.

From the GitLab engineering blog, in their own documentation: "The interaction is mostly read-only, meaning you can see the changes and discussions, but you can't add or change comments, yet." The "yet" has been there since 2023. Three years later the limitation is still real. What the extension does well is the read side of review — checkout the MR branch locally, look at the diff with your editor's full search and navigation, run tests, look at related files that are not in the diff. What it cannot do is the write side: posting new comments, replying to threads, resolving discussions, approving the MR, reacting with emoji.

The workflow this creates is the worst kind of context switch. You read the diff in VS Code with all your editor power. You find the bug, you have the explanation typed out in your head. Then you open the browser, navigate to the merge request, find the same line in GitLab's web diff viewer, click the comment icon, paste what you already wrote, hit submit. By the time you have done that for the third comment on a long MR, you have lost twenty minutes to tab switching that should have happened inside VS Code in the first place.

The official extension has its place — it shines as a read tool for understanding what changed and why. As a complete review surface, it stops short of where the work actually happens.

GitLab Duo Code Review — when the math works

GitLab Duo Code Review is GitLab's first-party AI review feature. It went generally available in GitLab 18.1 (after experimental status in 17.5) and works across GitLab.com, Self-Managed, and Dedicated. You assign it as a reviewer (/assign_reviewer @GitLabDuo) or pick it through the UI, and it generates suggestions inline on the merge request diff like a human reviewer would.

What it sends to its LLM is documented: the MR title and description, the file contents before changes for context, the diffs themselves, the filenames, and any custom review instructions you have configured on the project. That payload goes through GitLab's AI Gateway — which is a cloud service GitLab operates, not something you can fully self-host on the standard license. For a typical self-managed deployment, the gateway connection means your instance needs outbound internet access. True air-gapped operation requires the separate Offline Cloud License, which is a different commercial conversation.

The cost is where this gets interesting. Duo Code Review requires Premium or Ultimate, plus the Duo Enterprise add-on at approximately $39/user/mo on top of the base license. For a 10-developer team on Premium Self-Managed:

GitLab Premium SM: $19/user/mo × 10 = $190/mo
GitLab Duo Enterprise add-on: $39/user/mo × 10 = $390/mo
Total: $580/mo

$580/mo for AI code review on a 10-person team is not unreasonable if you are already on Premium and the Duo Enterprise add-on covers other AI features your team uses (Code Suggestions, Duo Chat, etc.). What it is not is a free upgrade to your existing GitLab plan. The newer agentic Code Review Flow option (GitLab 18.8+) shifts to credit-based billing on top of that, which adds variability to a previously predictable bill.

When Duo makes sense: you are already on Premium or Ultimate, the Duo Enterprise add-on is already in your budget for other features, your instance has cloud connectivity and that is fine, and you want one vendor for everything. When it does not: you are on CE Free, your security posture forbids the AI Gateway, or $580/mo for 10 devs feels heavy for a single feature.

AI code review options for GitLab Self-Managed: trade-offs

Four tools cover the GitLab Self-Managed AI review space in mid-2026. Each makes a different trade between deployment complexity, cost, and whether your GitLab instance has to be reachable from the public internet.

* Git AutoReview subscription price only. ~$2-5/mo AI compute costs paid directly to AI provider (Anthropic/Google/OpenAI bills you separately). GitLab Duo and CodeRabbit bundle AI compute in their price.

The pivot point most teams miss is the webhook column. CodeRabbit's architecture is webhook-based by design: CodeRabbit's cloud calls into your GitLab instance to fetch MR data and post comments back. That call has to terminate at a publicly reachable URL. If your GitLab instance lives inside a private network — which is the most common reason teams went self-managed in the first place — you either expose the instance to the internet (defeating the purpose), set up a reverse proxy with auth (operational overhead), or rule out CodeRabbit entirely.

Greptile is the opposite end of the spectrum. Their self-hosted option runs as a Docker Compose stack with PostgreSQL, pgvector, and Redis. The deployment is non-trivial: enterprise contract, custom pricing, and your platform team owns the whole stack. For organizations large enough to have a dedicated platform team and a hard requirement that nothing leaves the perimeter, Greptile self-host is the cleanest answer. For everyone else, the setup cost dominates the AI value.

Git AutoReview takes the third path: the integration runs inside the developer's VS Code, calling out to your GitLab instance over the REST API. The connection is outbound-only from the developer's machine, and the AI provider call goes directly from the developer's machine to Anthropic/Google/OpenAI — nothing transits gitautoreview.com servers. Your GitLab instance does not need to be publicly accessible, no webhook configuration, no port forwarding, no exposing the admin panel.

Duo lives in the middle of the trade-off space. It runs against your GitLab instance natively, which is great for integration. But the AI Gateway requirement means a cloud dependency that some teams went self-managed specifically to avoid. The math works for teams already on Premium with Duo Enterprise; for everyone else it is the most expensive option on the table.

Git AutoReview on GitLab Self-Managed: setup in 5 minutes

The setup is intentionally short because the architecture is intentionally simple. There is no webhook to register, no service account to provision, no admin panel to expose. The developer's VS Code talks to your GitLab instance with their own credentials, and to the AI provider with the team's BYOK keys.

Step 1: Install Git AutoReview from the VS Code Marketplace.

Open VS Code, go to Extensions, search "Git AutoReview", click Install. Or use the command line: code --install-extension vitalii4reva.git-autoreview. The extension is free — install on every developer's machine in your team.

Step 2: Add your GitLab Self-Managed instance URL in settings.

Open the Git AutoReview sidebar, choose "GitLab Self-Managed" as the platform, and paste your instance URL — for example https://gitlab.yourcompany.com. The extension will use this for all GitLab API calls.

Step 3: Create a Personal Access Token on your GitLab instance.

In GitLab, go to your User Settings -> Access Tokens. Create a new token with api scope (this gives read/write access to MRs and comments through the REST API). Copy the token immediately — GitLab only shows it once.

Token name: VS Code Git AutoReview
Scopes: api
Expiration: whatever your security policy requires

Paste the token back into the Git AutoReview extension. The connection is now ready. Your token sits in VS Code's secure storage (system keychain) and never transits anywhere except your GitLab instance.

Step 4: Add your AI API key.

Pick a provider: Anthropic (Claude), Google (Gemini), or OpenAI. Generate an API key from their console and paste it into Git AutoReview. The diff content goes directly from VS Code to your AI provider's API endpoint — gitautoreview.com servers do not see your code. The BYOK model means you pay the AI provider directly at their posted rate, typically around $2-5/mo per developer who runs reviews regularly.

Step 5: Open a merge request in VS Code and run Quick Review.

Pick any merge request from the sidebar. Click "Quick Review." The extension reads the diff, sends it to your AI provider, and shows the findings in a panel inside VS Code. You review each finding — approve to publish as a comment on the GitLab MR, edit if the suggestion is mostly right but needs tweaking, or reject if it is noise. Approved comments post under your own GitLab identity, not a bot account.

What did not happen during setup: no webhook registration, no port forwarding, no making your GitLab instance accessible from the public internet, no service account, no admin approvals, no code touching gitautoreview.com servers, no AI Gateway licensing conversation. The whole flow runs over outbound HTTPS from the developer's machine — the same connections their browser already makes to read GitLab in the first place.

Quick overview: installing GitLab Self-Managed

If you have not set up GitLab Self-Managed yet and you are reading this article to scope a green-field deployment, this section is the 60-second version. The full installation docs at docs.gitlab.com/install cover the depth you will eventually need — what follows gets a working instance running on a fresh Ubuntu server.

Hardware requirements (verified against GitLab's official requirements page for up to 1,000 users):

The RAM number is the one most first-time installers under-provision. GitLab is a Rails monolith plus Sidekiq plus Gitaly plus a handful of subsystems — at 8 GB you can run a development instance with one user; at 16 GB you can run a small team comfortably; production deployments above 100 users typically want 32 GB+ with horizontal scaling on the GitLab Reference Architectures for larger scales.

Ubuntu Omnibus install (from GitLab's official install docs):

sudo systemctl enable --now ssh
sudo ufw allow 22/tcp && sudo ufw allow 80/tcp && sudo ufw allow 443/tcp && sudo ufw enable
sudo apt update && sudo apt install -y curl
curl --location "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh" | sudo bash
sudo EXTERNAL_URL="https://gitlab.yourcompany.com" apt install gitlab-ce

That last line sets the public hostname GitLab uses for clone URLs, OAuth callbacks, and the admin URL. Set it to whatever DNS name resolves to your server before running the install — changing it later is a config edit plus gitlab-ctl reconfigure, but it is cleaner to get it right the first time.

After the install finishes, the root password is in /etc/gitlab/initial_root_password. The file gets deleted after 24 hours, so log in with the root account, change the password, and move on. From there the rest of the bootstrap — TLS certs, SMTP for emails, LDAP/SAML if you have an identity provider — is in the official docs.

Configuring webhooks for internal integrations

If you do need webhooks for some other integration (CI, ChatOps, monitoring, anything other than AI review), the GitLab webhook system on self-managed has one feature that GitLab.com lacks: it can hit URLs inside your private network. The default is locked down — GitLab will not call internal addresses to prevent SSRF attacks — but admins can opt-in for internal services.

Project-level webhook: Settings -> Webhooks -> Add new webhook. Pick the events you care about. For an MR review integration the relevant checkboxes are "Merge request events" (fires on open/update/merge) and "Comments" (fires on new discussion notes).

Internal network access: Admin Area -> Settings -> Network -> Outbound requests -> "Allow requests to the local network from webhooks and integrations." Off by default, on for internal-only services. Combined with allowlists, you can let GitLab call http://internal-ci.lan/webhook without opening the door to every IP on your network.

Push event limits and timeouts: self-managed admins can tune push_event_hooks_limit via API and configure webhook timeouts globally — GitLab.com hardcodes the timeout at 10 seconds, which has bitten plenty of teams whose downstream service is just slow. On self-managed you set the limit to whatever your infrastructure can sustain.

Note that none of this is needed for Git AutoReview — the VS Code extension uses the REST API for everything, no webhooks involved. The section above is for teams who want webhooks for other integrations and were burned by GitLab.com's stricter defaults.

Pain points that drive teams toward better tooling

Three frictions come up consistently in self-managed teams that we have not already covered, and they are worth naming because they shape the case for adding AI review on top.

Web UI latency. A Hacker News thread captured the sentiment: "The GitLab web interface has always felt sluggish to me. 10 years later the same problem remains." The MR diff view, the file tree on large repos, the comment-reply round-trip — none of it is broken, but the cumulative friction adds up over a day of review work. VS Code-based review (any flavor, including Git AutoReview) bypasses the web UI entirely for the read side, which is most of the time.

No auto-refresh on new commits. If you are reviewing an MR in the web UI and the author pushes a fix while you are reading, the diff in your browser is now stale. There is no notification, no auto-refresh, no banner — you have to reload the page to see the new state. Teams develop habits around this (refresh before every comment, ping the author on Slack to coordinate) but it remains a frequent source of "we commented on the same line twice" duplicates.

Notification fatigue on long MRs. Every individual comment fires a separate email. A 30-comment MR with three reviewers generates 90+ emails, plus reply notifications, plus the merge notification. The signal-to-noise of GitLab email traffic on active projects is roughly the same as Jira — most teams disable email entirely and rely on the in-app inbox, which has its own UX quirks.

None of these kill the platform — teams ship millions of MRs through GitLab Self-Managed every year. But each friction is a reason teams pull review work into editor-based tools when possible, and the case for an AI assist that runs inside VS Code stacks on top of the case for human review inside VS Code.

Compliance: what self-managed actually does for you

The compliance argument for self-managed gets oversold in vendor decks. Let us be precise about what running your own instance actually buys you across the four frameworks teams ask about most.

FedRAMP. Requires deployment on a FedRAMP-authorized cloud. GitLab Dedicated for Government received FedRAMP Moderate ATO in May 2025 — that is a separate product from generic self-managed. Running GitLab CE on your own AWS GovCloud account does not automatically inherit FedRAMP status. Self-managed is a building block for FedRAMP compliance, not a compliance certification.

HIPAA. No vendor can hand you HIPAA compliance because HIPAA is a process, not a checkbox. What self-managed gives you is full control of the data path — every PHI access can be logged, every export can be audited, your DPA is between you and your AWS/GCP provider (or your own datacenter) rather than between you and GitLab Inc. That control simplifies the BAA conversation considerably, but the work of actually being HIPAA compliant is on you.

SOC 2. SOC 2 applies primarily to SaaS providers, not to teams running their own infrastructure. If you are running GitLab Self-Managed for your own product, SOC 2 is something your customers might ask about your service — and your GitLab instance is one piece of your control environment. Self-managed makes the audit easier because you control the answers; running on GitLab.com means your auditor has to read GitLab's SOC 2 report as part of theirs.

ISO 27001. Standard for any deployment, on-prem or cloud. ISO 27001 is about your information security management system, not where the bits live. Self-managed simplifies certain controls (data residency, access control, incident response) by giving you direct ownership of them.

The honest framing: teams choose self-managed not because cloud is forbidden, but because it gives control and predictability without third-party dependency. Compliance frameworks rarely mandate on-prem — they require controls, and on-prem makes some of those controls easier to implement and easier to audit.

When each option actually fits

Pulling the threads together, the decision tree is shorter than the comparison table makes it look.

Already on Premium + Duo Enterprise, cloud connectivity is fine: GitLab Duo Code Review. The integration is native, the budget is already approved, and you get a single vendor for AI across review, code suggestions, and chat.

On CE Free, instance is internal-only, want AI review without ceremony: Git AutoReview. Works on every tier, no public URL required, BYOK keeps the code path under your control, $14.99/mo flat covers the whole team.

Need the deepest possible self-hosted AI stack and have a platform team: Greptile Enterprise. The deployment cost is real, but the result is a fully on-prem AI review system with no third-party calls in the data path.

Public-facing GitLab instance, fine with code going through CodeRabbit cloud: CodeRabbit. The webhook architecture works cleanly when the instance is reachable, and the auto-publish model is what some teams actually want.

The most common configuration we see for internal self-managed GitLab is the combination: Git AutoReview running in VS Code for developer-driven AI review with human approval, plus GitLab's native Premium approval rules and Code Owners for the enforcement layer on top. The two pieces solve different parts of the problem — AI catches the issues, GitLab enforces the policy gate — and they compose cleanly because neither one requires changing the other.

Frequently asked questions

Related Resources

GitLab-specific:

• AI Code Review for GitLab — Cloud and Self-Managed setup walkthrough, Duo comparison
• GitLab AI Code Review landing page — Product overview and feature matrix

Architecture deep-dives:

• BYOK Code Review — Why bring-your-own-key matters for self-hosted deployments
• Private Code Review — How the data path works when code never touches our servers
• Human-in-the-Loop AI Code Review — Why approval gates matter for AI review

Pricing and comparisons:

• AI Code Review Pricing Comparison 2026 — Real costs for 5/10/20/50 dev teams
• Best AI Code Review Tools 2026 — Full landscape across GitHub, GitLab, Bitbucket
• AI PR Review Guide — Decision framework for AI review across platforms