Installation

The ReviewGate bot ships as a single Docker image. Redis comes up next to it (the review queue); PostgreSQL is optional and only stores review metrics. All of it runs inside your own network. The second surface — the CLI for a developer machine — ships as a separate executable with no Docker and no Node: CLI, hook and MCP.

Running it

Download the ready-made client docker-compose.yml (the bot plus Redis, optionally Postgres), fill in .env next to it (see the reference below) and bring it up:

curl -O https://reviewgate.dev/docker-compose.yml
docker compose up -d
docker compose ps        # every service healthy
docker compose logs -f app

Check that the bot answers:

curl http://localhost:3000/api/health
# {"status":"ok","ts":...,"version":"0.1.x",
#  "capacity":{"total":3,"cli":1,"mrReserve":2,
#              "inFlight":{"mr":0,"cli":0},"waiting":0}}

capacity is how the review throughput is set up, readable from outside without going onto the machine for the startup log: total is the number of reviews the worker runs in parallel (REVIEW_CONCURRENCY), cli is how many of those slots local runs through the review server may take, mrReserve is the slots they can never take — the guarantee that a request review starts at once — and inFlight/waiting are what is happening right now. Note what the answer does not tell you: it is produced without touching Redis or the database, so a green reply means the process is up, not that the queue is reachable.

Environment: GitLab

A vendor counts as configured once GITLAB_TOKEN is set. The bot works with one vendor or with both at once — but at least one must be configured, otherwise it will not start.

Environment: GitHub

The second hosting vendor: reviewing pull requests on github.com. Configuring it is not required — the whole block is optional. Connecting the vendor is described separately in Connecting GitHub.

Environment: Redis and the queue

Environment: the model

The details, and running a model locally, are in Models and your own key.

Environment: Postgres (optional)

Postgres is only needed for review metrics — it is off by default and the bot works fully without it. To enable it, uncomment the postgres service and the DATABASE_URL line in docker-compose.yml, then set a password in .env. The metrics hold counters and metadata only (how many findings were generated, kept and dropped by the judge; the models, the tokens) in your own database, cleaned up after 90 days — a convenient way to see what the bot is worth and what the judge drops.

Environment: license

Environment: logs (optional)

The recipe for shipping to Graylog, ELK or Loki is on Logs and monitoring.

Where the image comes from

docker compose up -d pulls the image on its own — the commands below are only needed if you fetch it by hand: into an air-gapped network, into your internal registry, or to inspect it before installing.

Ask the registry itself which versions are published:

curl -s https://registry.reviewgate.dev/v2/reviewgate-bot/tags/list

Pull it by hand and verify you got the right image — the digest must match the mirror, since the image is built once and published to both registries:

docker pull registry.reviewgate.dev/reviewgate-bot:latest

# the digest must match the mirror:
docker buildx imagetools inspect registry.reviewgate.dev/reviewgate-bot:latest | grep Digest
docker buildx imagetools inspect novohudonossor/reviewgate-bot:latest | grep Digest

Air-gapped network (no internet)

On a machine with internet access save the image to a file, move it by whatever means your policy allows, and load it on the target server. The image is built for linux/amd64 — pass the platform explicitly if you pull from an ARM machine, a Mac for example:

VERSION=latest   # or a specific tag from the list above

# 1) on a machine with internet access
docker pull --platform linux/amd64 registry.reviewgate.dev/reviewgate-bot:$VERSION
docker save registry.reviewgate.dev/reviewgate-bot:$VERSION | gzip > reviewgate-bot-$VERSION.tar.gz

# 2) move the file to the target server, then there:
gunzip -c reviewgate-bot-$VERSION.tar.gz | docker load
docker image ls | grep reviewgate-bot

After docker load, put the tag you loaded into docker-compose.yml — then up -d takes the local image and never reaches for the network.

Upgrading

The bot is distributed as a public image from registry.reviewgate.dev (mirrored on Docker Hub, see The image will not pull) — we recommend pinning a specific version tag. Upgrading is an ordinary pull and restart:

docker compose pull app
docker compose up -d app

If the tag is pinned (not latest), put the new one into docker-compose.yml first — otherwise pull fetches the same image and up -d recreates nothing. The list of published versions comes from the command in Where the image comes from.

Which version is running

The build version is baked into the image and shows up in the /api/health response, in the 🚀 ReviewGate bot … line of the startup log, and in the output of diagnose.sh.

curl -s http://localhost:3000/api/health
# {"status":"ok","ts":...,"version":"0.1.x","capacity":{...}}
#                                     ↑ the version of the running image

docker compose logs app | grep 🚀
# 🚀 ReviewGate bot 0.1.x listening on http://0.0.0.0:3000/api

If the bot does not start at all — because of an error in .env, say — the version is still readable: it lives in the image, not in the running application:

docker compose run --rm --no-deps app printenv REVIEWGATE_VERSION
# 0.1.x

Include the version in any support request — that is where the investigation starts.