AI-Codereview-Gitlab: self-hosted LLM code review for GitLab merge requests

What AI-Codereview-Gitlab actually automates

The project targets one narrow moment in the GitLab workflow: a push or a merge request event. The README states that GitLab triggers a webhook, the system calls a third-party LLM to review the code, and the result is written back as a Note on the merge request or commit. That is the whole loop. There is no IDE plugin, no pre-commit hook, and no local CLI reviewer.

The intended user is a team that already hosts GitLab and wants review comments without adopting a hosted product. Six providers are listed as compatible: DeepSeek, ZhipuAI, OpenAI, Anthropic, Tongyi Qianwen and Ollama. The Ollama entry matters because it means the review can run against a local model, though the README does not describe what model size or hardware that requires.

Two features sit outside the core review loop. Review results can be pushed to DingTalk, WeCom or Feishu, and a daily report is generated from GitLab, GitHub and Gitea commit records. A Streamlit dashboard on port 5002 shows review logs and per-project and per-developer statistics. If you only want comments on merge requests, the push integrations and dashboard are optional surface area you can ignore.

The webhook-to-note data flow, and where the agentic mode diverges

In the default path, the system works on the diff alone. The README calls this strategy diff_only and says it behaves identically to the original version. The flow is short: webhook arrives at the Flask service on port 5001, the diff is filtered against SUPPORTED_EXTENSIONS, an LLM call is made, and the answer is posted back as a Note. Files whose extensions are not in that list are not reviewed at all, which is a deliberate cost control and also the first thing to check when a file type you care about is silently ignored.

The optional agentic mode changes the architecture rather than the prompt. Setting REVIEW_STRATEGY=agentic gives the model tool-calling ability: read_file and a sandboxed run_command. The service clones or updates the target repository under REPO_CACHE_DIR, and the model explores that local checkout before answering. The README describes the shell as read-only by default, allowing ls, cat, grep, find and git log, with three limits: a sandbox, path traversal checks, and a 30 second timeout. AGENT_SHELL_ALLOWLIST and AGENT_SHELL_BLOCKLIST control the command sets.

The design decision worth noting is the fallback. The README says any failure at any stage, whether clone, fetch, LLM or tool call, degrades automatically to diff_only. That is a sound choice for a webhook handler, because a webhook that returns nothing is worse than one that returns a shallower review. It also means an agentic failure is invisible in the output unless you are reading logs: you get a review, just not the one you configured.

Installing with Docker Compose and posting a first review

The README gives Docker as the first deployment option. Clone the repository and create the environment file from the distributed template:

git clone https://github.com/sunmh207/AI-Codereview-Gitlab.git
cd AI-Codereview-Gitlab
cp conf/.env.dist conf/.env

Then edit conf/.env. The README lists the keys that matter for a first run: the provider, its API key, the extensions to review, and the GitLab token. The example below uses DeepSeek and keeps DingTalk disabled.

LLM_PROVIDER=deepseek
DEEPSEEK_API_KEY={YOUR_DEEPSEEK_API_KEY}
SUPPORTED_EXTENSIONS=.java,.py,.php,.yml,.vue,.go,.c,.cpp,.h,.js,.css,.md,.sql
DINGTALK_ENABLED=0
GITLAB_ACCESS_TOKEN={YOUR_GITLAB_ACCESS_TOKEN}

Start the stack, which the compose file maps to ports 5001 and 5002 and mounts ./data and ./log as volumes:

docker-compose up -d

Verification is a browser check. Visiting http://your-server-ip:5001 should show "The code review server is running." and http://your-server-ip:5002 should show the review log dashboard. If the first page loads but the second does not, the Streamlit process is the one to investigate, since the Dockerfile runs both under supervisord.

The remaining step is on the GitLab side. In the project settings, add a webhook pointing at http://{your-server-ip}:5001/review/webhook and tick only Push Events and Merge Request Events. The README is explicit that other event types should not be selected. The Secret Token field accepts the access token, but the README gives a priority rule: GITLAB_ACCESS_TOKEN in .env wins, and the webhook Secret Token is used only when that variable is unset. After the first merge request, a Note should appear on it.

If you prefer a bare Python install instead of Docker, the README requires Python 3.10 or later, then pip install -r requirements.txt, python api.py for the API, and streamlit run ui.py --server.port=5002 --server.address=0.0.0.0 for the dashboard. The environment file is the same.

Agentic mode's real cost, and the cases where it is the wrong tool

The README is unusually candid about agentic overhead, and the numbers deserve attention before anyone flips the switch. Disk usage is 10MB to 2GB per project in the cache, with a recommendation to reserve at least 50GB. A single session peaks around 500MB of memory. Token consumption per review is 5k to 50k, which the README describes as 3 to 10 times diff_only. Latency is 30 seconds to 5 minutes per review.

Those figures rule out agentic mode for some teams outright. A merge request that waits five minutes for a comment is fine on a large refactor and annoying on a one-line fix. The cache also grows with every project reviewed, so the 50GB figure is a floor, not a target. And the token multiplier applies to every review, including the ones where the diff alone would have been enough.

The deeper limitation is verification. Because every failure path degrades to diff_only, you cannot tell from the posted Note whether the model explored the repository or just read the diff. The README does not document a status field, a log marker, or a configuration flag that would surface the strategy actually used for a given review. If you are paying for agentic reviews, you have no built-in way to confirm you received one.

A second boundary is network topology. The README notes that GitLab must be able to reach this system, and suggests deploying on an external server when the internal network is restricted. For teams whose GitLab sits in an isolated network, that is a deployment blocker rather than a tuning problem. A third is extension filtering: code in a language absent from SUPPORTED_EXTENSIONS is never reviewed, and nothing in the output says so.

How it compares with GitLab Duo code review

GitLab Duo code review is the hosted option most teams will weigh against this project, and the difference is architectural rather than a matter of feature lists. Duo is part of the GitLab platform: there is no webhook to configure, no separate service to run, and no server that GitLab must be able to reach over the network. Review happens inside the product you already pay for.

AI-Codereview-Gitlab inverts that. You supply the model, the API key, the server and the storage. In exchange, the model is your choice among six providers, including Ollama for a fully local setup, and the review data stays in your own database and dashboard. For teams with data residency constraints or an existing LLM contract, that control is the reason to pick it. For teams that want review comments without operating another service, Duo removes an entire deployment step that this project requires.

The comparison also cuts against this project on maintenance surface. Running it means managing a Docker image, two ports, an environment file, a repository cache in agentic mode, and a GitLab webhook configuration. None of those are hard individually. Together they are a service you now own. The README's own deployment notes about network reachability are a reminder that this is infrastructure, not a plugin.

Release cadence, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-07-23. The most recent release is v1.5.1 from 2026-06-29, preceded by v1.4.3 on 2026-05-20 and v1.4.2 on 2026-03-15. The docker-compose file pins the image tag to 1.5.1, so upgrading is a matter of changing that tag and pulling again rather than tracking a moving latest.

Upgrade cost is concentrated in two places. The first is the environment file: new releases can add keys, and the README does not document a migration path or a changelog for conf/.env, so comparing your file against conf/.env.dist after each pull is the practical approach. The second is the agentic cache under REPO_CACHE_DIR. A cached clone from an older release is not described as versioned in any way, and the README does not say whether it is invalidated on upgrade.

The licence is Apache-2.0, which permits commercial use and modification, and requires that the licence and attribution notices be preserved. The repository also ships a Pro version, distributed separately via an install script that pipes a remote shell script into bash. That is a separate product with its own terms, and nothing in the README suggests the open source licence covers it. Treat the two as distinct when assessing what you are allowed to do.

Editorial conclusion

Adopt it if your team already runs GitLab on a network that can reach an external server and you want review notes posted without buying a hosted product. Skip it if you cannot expose port 5001 to your GitLab instance, or if per-review token spend of 5k to 50k in agentic mode is unacceptable. Before rolling it out, verify that your GitLab instance can reach http://{your-server-ip}:5001/review/webhook and that your chosen provider key is accepted by the model you configured in LLM_PROVIDER.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. sunmh207/AI-Codereview-Gitlab on GitHub