Self-hosted AI code review: the part after docker run

Follow one pull request all the way through

Start with a small change. Someone fixes a logout handler, opens a pull request, and waits for feedback. A webhook reaches the reviewer. The reviewer fetches the diff, reads surrounding code, calls a model, and posts a comment about a missing await. That single comment has already crossed several boundaries.

The Git platform holds the repository. The review service gathers context. A model processes that context. A database keeps the review history. Logs may record enough detail to help debug a failure. If you want to know what self-hosting gives you, draw that journey before you choose a server.

With Mira, you operate the review service and its data stores. Model inference is a separate choice. You can use your own key with a cloud provider or send requests to an endpoint you operate. Both are self-hosted Mira deployments; they have different answers to the question of where source context is processed.

View full size

Decide what “our infrastructure” should mean

It is tempting to treat the location of the Docker container as the whole privacy decision. It is one box on the diagram. A local review service connected to a cloud model still sends the context needed for inference to that provider.

For some teams, that arrangement is exactly right. They want control over review history, credentials, and configuration while using a managed model. Others need inference to stay within a particular network. Make that distinction explicit so nobody mistakes a deployment preference for a guarantee about data movement.

These are the parts worth accounting for in a Mira deployment. The precise storage layout depends on your configuration.

A working container is not a storage plan

A disposable container is useful. Disposable review history is less useful. Before connecting a repository that matters, decide which data should survive an image update and where it will live.

Mira supports SQLite and Postgres. Its deployment guide also covers persistent index storage. Follow that storage setup rather than assuming the container’s writable filesystem will outlive the next deployment. If you use Postgres, check the index volume as well: choosing an external database does not automatically make every file persistent.

Backups need a restore procedure. A backup job that reports success tells you a file was written somewhere; it does not tell you that the next person on call can bring the service back. Try restoring a test deployment and checking that the expected settings and review history are present.

Keep configuration and secrets separate. A deployment-level mira.yaml can describe how the service should behave. Tokens, private keys, and passwords belong in your secret-management setup. For GitHub, the private key is a multi-line PEM, so pay attention to the Docker guide’s mounting instructions instead of pasting it into a normal single-line env-file entry.

View full size

Make a missing review visible

The service can be healthy while a review fails. A webhook might not arrive. A provider token might expire. A model request might time out. The interesting operational question is whether a pull request made it from receipt to a posted review.

Give that path an owner. Decide where to look for webhook deliveries, how to investigate a failed review, and which model endpoint the deployment actually used. Those decisions save a surprisingly long conversation when an author asks why the bot said nothing.

Treat model configuration as part of the deployment record. Mira allows separate indexing, review, and security models, along with fallback configuration. A review incident is easier to explain when you can see which settings were effective rather than reconstructing them from a team chat.

You do not need an elaborate monitoring project before trying the tool. You do need a way to distinguish a quiet review from a failed one. Start there.

Start with repositories someone will actually watch

For your first Mira rollout, connect one or two repositories with maintainers willing to read the feedback and tell you when it is wrong. GitHub, GitLab, and Forgejo are supported, so you can start where the team already reviews code. A small, attentive rollout gives you time to investigate each finding before expanding the installation.

Keep a short record of the first batch of reviews: useful findings, false alarms, failed runs, and any surprising model cost. Include routine changes. A reviewer that finds a real bug in a complicated PR but complains about every dependency update may still be a poor fit for the team.

When you adjust a threshold or change a model, revisit the same examples. Otherwise, a different mix of pull requests can make a configuration change look better or worse than it is. You are looking for a review process people can rely on, which requires more than one impressive demonstration.

Choose the responsibility you want to take on

Self-hosting gives you decisions that a hosted service makes on your behalf: where state lives, which model runs, how upgrades happen, and how the reviewer connects to the rest of your environment. That control is useful when you have a reason to exercise it.

It also leaves your team with the service to operate. Budget for that work alongside infrastructure and model usage. For an initial deployment, a useful definition of done is modest: a real PR has been reviewed, its data survives a restart, and someone knows how to investigate the next failure.

Use Mira’s Docker deployment guide to get that first repository connected, then keep the storage, model, and operating decisions beside your deployment configuration. When you add the next repository, you should be extending a setup you understand.