Your code review server is humming. CI jobs are running. Then a teammate can’t reach Gerrit because of a proxy timeout, and someone mutters “Jetty again.” It’s the quiet heart of Gerrit’s web layer, yet when something feels sluggish or unsafe, Jetty is often where the story begins.
Gerrit Jetty is the built-in HTTP server that powers Gerrit Code Review. Jetty handles incoming requests, manages TLS, enforces authentication, and serves static assets. Unlike using Apache or Nginx frontends, Jetty runs natively inside the JVM. That makes setup fast and portable, which is exactly why so many teams stick with it rather than offloading traffic through a separate reverse proxy.
When integrated properly, Gerrit Jetty becomes more than an embedded server. It turns Gerrit into a self-contained service that can scale, reuse existing identity providers, and support secure automation. Jetty’s async model handles hundreds of concurrent requests without blocking, perfect for teams reviewing large merges at the same time.
To configure Jetty inside Gerrit, define authentication style, port bindings, and SSL context in the gerrit.config under the [httpd] section. Most teams connect it with OAuth or OIDC flows from Okta or Google Workspace. The logic is simple: Jetty takes care of session verification, Gerrit applies permission logic, and reviewers stay inside a consistent, authenticated UI. The fewer hops between browser and repository, the fewer unknowns in production.
A few best practices keep Jetty running smooth. Rotate SSL certificates more often than you think you need to. Keep requestHeaderSize reasonable to avoid abuse. Monitor thread pools since one rogue plugin can starve Jetty’s workers. Map groups from your identity provider rather than duplicating Gerrit groups manually to simplify RBAC and auditing.