Self-hosted code review, honestly reviewed. Built by Google, used at planetary scale — but is it right for your team?

TL;DR

What it is: Apache-2.0-licensed self-hosted code review and Git repository management platform, built by Google and used to ship Android, Chromium, and OpenStack [4].
Who it’s for: Engineering teams that need structured, enforced code review at serious scale — think 10+ engineers, multiple repositories, strict merge workflows. Not a tool for non-technical founders.
Cost savings: Gerrit itself is free. Running it on a VPS costs $5–15/mo. Managed hosting via Elestio starts at $14/mo [4]. GitHub Teams runs $4/user/mo and up — for a 20-person engineering team that’s $80/mo minimum, and GitHub Enterprise is substantially more.
Key strength: The most battle-tested open-source code review engine alive. If it can handle the Android kernel codebase, it can handle your startup’s monorepo. REST API is comprehensive and well-documented [5]. Plugin system is genuinely extensible [website].
Key weakness: The UX is from 2010 and it shows. The Change-Id workflow is foreign to anyone who learned Git via GitHub pull requests. Setup is non-trivial. And if your team is under 10 engineers, you almost certainly don’t need this.

What is Gerrit

Gerrit is a web-based code review and Git repository management tool. You push a change to Gerrit, reviewers see a side-by-side diff with syntax highlighting, leave inline comments, vote with +2/+1/0/-1/-2 scores on a Code Review label and a Verified label, and only when the right votes are in place does the change get submitted to the target branch [website][README].

That workflow is the whole point. Gerrit doesn’t let you merge your own changes without a +2 from someone else (unless you configure it to). It’s a gate, not a convenience. Google designed it to ensure that no code lands in a large shared codebase without at minimum one qualified reviewer signing off. The project itself is maintained by Google and used internally at Google, which is the strongest possible signal that it works at scale [4].

The GitHub mirror sits at 1,158 stars — which sounds modest until you learn that the canonical repository lives on Google’s own Gerrit instance at gerrit.googlesource.com, not GitHub. The mirror is secondary. The actual project has hundreds of active contributors and an eight-year track record of production deployments at some of the biggest open-source projects on the planet [4][2].

As of this review, the latest release is 3.13.3 [website].

Why people choose it over GitHub, GitLab, and Gitea

The honest answer is that most teams don’t choose Gerrit anymore — they inherit it, or they come from a Google-adjacent engineering culture where it’s the default. Understanding why teams stay on it is more instructive than understanding why they choose it fresh.

The Change-Id model is the core differentiator. In GitHub’s pull request model, you push a branch, someone reviews it, and you merge the branch. In Gerrit’s model, you push individual commits. Each commit gets a Change-Id (a hash embedded in the commit message by a git hook), and that Change-Id tracks the change through all its revisions. Patch Set 1, Patch Set 2, Patch Set 3 — reviewers can see exactly what changed between each revision, not just the final diff against main [2][README]. For codebases where commit hygiene matters — where you want clean, atomic commits rather than a branch with 47 “fix typo” commits — this model is genuinely better than GitHub’s.

The access control system is serious. Gerrit’s permission model is project-by-project, branch-by-branch, label-by-label. You can say “only members of the security team can give +2 on changes to src/auth/**.” You can say “no one can push directly to main under any circumstances, ever.” You can delegate branch ownership to specific contributors without giving them admin rights elsewhere [website][README]. GitHub offers branch protection rules; Gerrit offers a policy engine.

It runs at scale that GitHub self-hosted cannot match. Android, Chromium, OpenStack — these aren’t marketing claims, they’re the production users [4]. When your repository has millions of commits and hundreds of active contributors, Gerrit’s underlying architecture (each commit is a full object in a JGit store, backed by mature garbage collection and replication) handles it. The website mentions geographic mirror replication built in as a first-class feature [website].

Review Board integrates with it. For teams that want to bolt on more sophisticated review capabilities — issue tracking per comment, moved code detection, multi-line comment threads — Review Board has a Gerrit plugin and RBTools CLI support [1]. This is a point in Gerrit’s favor for teams that find the native UI inadequate.

Features

Based on the README, website documentation, and REST API docs:

Code review engine:

Side-by-side and unified diff views with syntax highlighting [website]
Inline comments with reply threads [website][README]
Configurable vote labels (Code Review, Verified, and custom) [README]
Patch set history — every revision of a change is retained and browsable [2]
Auto-submit rules when required votes are met [README]
Submit strategies: merge, rebase, cherry-pick, fast-forward only [README]

Git repository management:

Built-in SSH and HTTPS Git servers compatible with all Git clients [website][README]
Hosts multiple repositories per instance [website]
Branch and tag management with fine-grained ACLs [website]
Scheduled git gc and geographic replication for latency reduction and hot-spare redundancy [website]
Ref-based access control: per-branch, per-ref, per-project permissions [website]

Developer tooling:

REST API covering accounts, changes, projects, groups, plugins, config, access rights, and documentation [5]
JSON output with compact and pretty-print modes, gzip compression support [5]
CORS support for web integrations [5]
RBTools CLI integration via Review Board plugin [1]
Change-Id git hook for tracking commits through revisions [2]

Extensibility:

Plugin system for server-side extensions [website]
Plugin REST endpoints and management API [5]
Source for community plugins available through the project listing [website]

Operations:

Docker images on DockerHub (CentOS 8 and Ubuntu 20.04 variants) [README]
Debian/Ubuntu apt packages and CentOS/Fedora yum/dnf packages [README]
Bazel build system for building from source [README]

Pricing: SaaS vs self-hosted math

Gerrit has no SaaS pricing because there is no official Gerrit SaaS. It is self-hosted or managed by a third party.

Self-hosted (free software, Apache-2.0):

License cost: $0
VPS to run it: $10–20/mo for a reasonable instance (Gerrit is a Java app; it wants at least 2GB RAM, 4GB recommended for larger repositories)
Your time to set it up and maintain it

Managed hosting via Elestio:

Starts at $14/mo [4]
Includes automated backups, SSL, monitoring, updates, AI DevOps, and human support [4]
Runs on dedicated VMs, not shared containers [4]
SOC2 and GDPR compliant [4]

Comparison: GitHub Teams

$4/user/month
10 engineers: $40/mo. 25 engineers: $100/mo. 50 engineers: $200/mo.
GitHub Enterprise: pricing not available in source data — contact sales

Comparison: GitLab

Pricing data not available in source material. Do not invent.

Concrete math for a 20-person engineering team: GitHub Teams at $4/user × 20 = $80/mo, or $960/year. Self-hosted Gerrit on a $15/mo VPS = $180/year. That’s roughly $780/year saved — not as dramatic as the Zapier comparison that automation tools enjoy, but real. The actual savings scale with team size: at 50 engineers, GitHub Teams is $200/mo ($2,400/yr) versus Gerrit’s flat VPS cost.

The caveat is that GitHub includes issue tracking, Actions CI/CD, Packages, and Copilot integration in that price. Gerrit is only code review and Git hosting. You’d need separate tooling for everything else. That changes the math.

Deployment reality check

Gerrit is a Java application. Deploying it is not a docker run and done situation, even though Docker images exist.

What you actually need:

A Linux VPS with at least 2–4GB RAM (Java heap + Git object store)
Docker or a package manager (apt on Debian/Ubuntu, yum on CentOS/RHEL) [README]
A domain and reverse proxy for HTTPS termination
An SMTP server for email notifications
A decision on authentication: LDAP, OAuth2, HTTP auth, or Gerrit-managed accounts

What can go sideways:

The Change-Id git hook has to be installed on every developer’s machine. Missing this hook means commits land without Change-Ids and Gerrit cannot properly track them across patch sets. This is not self-correcting [2].
The permission model is powerful and therefore complex. Getting it wrong means either too-open (anyone can push to main) or too-tight (nobody can submit anything). There is no “sane defaults” wizard [website].
If your team is used to GitHub pull requests, the Gerrit workflow will feel alien for weeks. “Push to a magic refs/for/branch refspec” instead of pushing a branch is not intuitive [2][README].
The UI is functional but dated. It has not kept pace with GitHub or GitLab on visual polish. Some teams run Gitiles alongside Gerrit for browsing and accept Gerrit’s review UI as-is.
Managed via Elestio sidesteps most of the above at $14/mo [4], but you still inherit the workflow complexity.

Realistic time estimate for a technical DevOps engineer: 2–4 hours to a working instance. For a developer who has never administered Java services: full day, possibly with yak-shaving on JVM tuning and file descriptor limits.

Pros and Cons

Pros

Apache-2.0 license. Truly free, no commercial use restrictions, no “fair-code” exceptions. You can fork it, embed it, run it for clients — no legal friction [README].
Battle-tested at serious scale. Android and Chromium are not toy projects. If you have a hard requirement for a code review system that will not fall over, Gerrit’s production history is unmatched in the open-source space [4].
Google-maintained. The core team works at Google and dogfoods Gerrit on Gerrit’s own repository. This is the opposite of an abandoned project [4][2].
Comprehensive REST API. Every major resource — accounts, changes, projects, groups, plugins — has REST endpoints. The Wikimedia Foundation runs a public Gerrit instance with full API documentation [5]. Automation and tooling integration are first-class.
Fine-grained ACLs. Per-project, per-branch, per-label permissions that GitHub’s branch protection cannot match.
Patch set history. Reviewers can compare exactly what changed between any two revisions of a change. This is architecturally better than GitHub’s “force push to update a PR” model.
Plugin extensibility. Server-side plugins can add REST endpoints, UI panels, and behavior hooks [website].
Review Board integration for teams wanting advanced commenting features [1].

Cons

UI is dated. The interface reflects its 2008 origins. GitHub and GitLab have lapped it on visual experience. This matters for developer adoption — a tool people find ugly gets used grudgingly.
Steep workflow learning curve. The Change-Id / refs/for/* model is a full paradigm shift from GitHub-native workflows. Onboarding GitHub-native developers onto Gerrit is a real time cost [2].
No built-in CI/CD. Gerrit manages code review and Git hosting. Everything else — issue tracking, pipelines, container registry, artifact storage — you source separately.
Java runtime overhead. The JVM adds memory pressure. On a $5/mo VPS with 1GB RAM, you will have a bad time. Budget for a larger instance.
No official SaaS. If you don’t want to operate infrastructure, your only option is a third-party managed provider like Elestio [4]. There’s no Gerrit.com with a free tier.
Small GitHub star count on the mirror (1,158). This undersells the actual project health but creates a false impression when evaluating via GitHub. The canonical repository is on Google’s infrastructure [README].
Overkill for small teams. Under 10 engineers, the setup and workflow cost is not worth what you get over simpler alternatives like Gitea with branch protection.

Who should use this / who shouldn’t

Use Gerrit if:

You’re an engineering team of 10+ that needs enforced, structured code review with no ability to self-merge.
Your codebase has strict commit hygiene requirements and you want patch set history as a first-class feature.
You need fine-grained Git ACLs that branch protection rules can’t express.
You’re migrating from an enterprise tool (Perforce, ClearCase) and need enterprise-grade access control.
You want a completely free (Apache-2.0), self-hosted Git hosting + code review stack with no vendor dependency.

Skip it (use Gitea + Forgejo instead) if:

You have fewer than 10 engineers and just want self-hosted Git with basic pull request review.
You want GitHub-style UX without the GitHub subscription.
You want a single binary that runs on a $5 VPS without JVM tuning.

Skip it (stay on GitHub/GitLab) if:

You need CI/CD, issue tracking, container registry, and code review in one integrated product.
Your team is GitHub-native and the workflow change cost is not worth the savings.
You’re a non-technical founder — Gerrit is an engineering infrastructure tool, not a founder tool.

Skip it (use GitLab self-hosted) if:

You want the full DevSecOps platform (CI/CD, security scanning, environments, packages) self-hosted under an open-core license.

Alternatives worth considering

Gitea / Forgejo — Lightweight, single-binary Git hosting with basic PR review. Much simpler to deploy and maintain. Right choice for small teams that want self-hosted GitHub. Forgejo is the community fork with stronger open governance.
GitLab CE — Full DevOps platform: code review, CI/CD, container registry, issue tracking, security scanning. Apache-2.0 on the Community Edition core. More complex than Gitea, far more complete than Gerrit.
Phabricator / Phorge — Phabricator is effectively abandoned by its creators; Phorge is the community continuation. Similar structured review philosophy to Gerrit but with task tracking built in. Smaller community.
Review Board — Dedicated code review tool that integrates with Gerrit (and other VCS) rather than replacing Git hosting [1]. Worth considering if you want Gerrit’s Git hosting plus a better review UI.
GitHub Enterprise — The obvious incumbent. Managed, polished, expensive for large teams. Pricing data not available in source material.
Sourcehut — Minimalist, email-based code review. The opposite of Gerrit’s UI complexity in a different direction. Niche but principled.

The realistic choice for most self-hosted engineering teams is between Gerrit, GitLab CE, and Gitea/Forgejo. Gerrit wins if enforced review workflow and Git ACL depth are the priority. GitLab wins if you want the integrated DevOps platform. Gitea wins if you want simplicity.

Bottom line

Gerrit is the right answer to a specific question: “How do we enforce structured, multi-reviewer code approval at scale, self-hosted, with no commercial dependency?” It answers that question better than any other open-source tool because it was built to answer exactly that question, by the team that ships Android. The Apache-2.0 license, the comprehensive REST API, the plugin system, and two decades of Google investment make it genuinely enterprise-grade. The trade-offs are real: dated UI, a workflow paradigm that takes weeks for GitHub-native developers to internalize, Java runtime overhead, and no built-in anything beyond code review and Git hosting.

For a non-technical founder trying to escape SaaS bills, Gerrit is not the answer — look at Gitea or GitLab CE. For an engineering team at a company that has outgrown GitHub’s access control model or is paying $200+/mo for GitHub Enterprise, Gerrit is worth the setup investment. A $15/mo VPS or a $14/mo Elestio managed instance replacing a $200/mo GitHub Enterprise bill is the math that keeps Gerrit alive and maintained.

If the setup is the blocker, that’s exactly what unsubbed.co’s parent studio upready.dev deploys for engineering clients. One-time fee, running in production, you own the infrastructure.