A read-only web viewer for bare git repositories, honestly reviewed. Not a GitHub replacement — something more specific, and for a certain use case, much better.

TL;DR

What it is: A lightweight, fast web frontend for browsing bare git repositories in a browser. Think a modern cgit or gitweb, written in Rust [README].
Who it’s for: Developers who already self-host bare git repos via SSH or gitolite and want a clean web interface to browse or share code publicly — without spinning up a full forge like Gitea or GitLab.
Cost: $0 (WTFPL license — essentially public domain). Runs on the same server you already use for git. No SaaS tier exists.
Key strength: Genuinely fast. RocksDB metadata caching delivers up to 97% faster load times for large repos compared to on-demand approaches [README]. Written in Rust, minimal resource footprint.
Key weakness: Read-only. No push access, no issues, no pull requests, no CI/CD, no user management. It’s a viewer, not a forge. If you’re looking to escape GitHub’s feature set, rgit is not the tool.

What is rgit

rgit is a git repository web frontend — the software that turns a directory of bare git repos into browsable web pages with commit history, file trees, diffs, branch and tag lists, and rendered READMEs. Its author describes it as “a gitweb/cgit-like interface for the modern age” [README].

The tech stack is Rust all the way down: Axum for the HTTP layer, Askama for HTML templating, gitoxide for reading git data, and RocksDB as the metadata store. That last choice is the interesting one. Instead of re-reading git pack files on every request (the cgit approach), rgit builds and maintains a RocksDB database of repository metadata — commits, branches, tags — and reindexes it on a configurable interval (default: 5 minutes). Files, trees, and diffs are still loaded on demand via gitoxide, with a small in-memory cache for rendered READMEs and diffs [README].

The result is what the README calls “up to 97% faster load times for large repositories” compared to naive on-demand loading [README]. You can see it live at the author’s own instance: https://git.inept.dev/

At 202 GitHub stars, this is a small project with a narrow but well-defined purpose. It does not try to be a GitHub clone. It has no authentication layer, no write path, no issue tracker, no PR system. If you want those things, you want Forgejo or Gitea [1][4]. rgit’s entire value proposition is: you already manage your git repos via SSH and bare repos, and you want a fast, good-looking way to show them off or browse them in a browser.

Why people choose it

rgit doesn’t appear in mainstream “GitHub alternatives” roundups [5] because it isn’t one — which is actually what makes it worth reviewing on its own terms.

The r/selfhosted community thread on self-hosting git [1] is instructive: the conversation gravitates immediately toward full forges — Forgejo, Gitea, GitLab. The recommendation consensus for solo devs is clear: Forgejo runs on 100MB RAM, GitLab needs 4–8GB and is overkill for one person [1]. What the thread doesn’t cover is the category of developer who doesn’t want a forge at all — who manages repos as bare directories, uses SSH for push access, and only wants a web layer for reading and sharing.

That’s the rgit use case, and it’s a real one. cgit has served this need for over a decade but looks like it was designed in 2008 (because it was). gitweb ships with git and is functional in the same way a 1990s Perl script is functional. stagit generates static HTML and is fine for tiny repos but doesn’t scale. rgit is the first tool in this category that looks like it was written in this decade and performs like it.

The choice to build in Rust rather than Go (Gitea/Forgejo’s language) or Python reflects the specific optimization target: raw read throughput with minimal memory. RocksDB as the metadata backend is a serious engineering choice — Facebook built RocksDB for high-write-throughput SSDs, and using it for a git metadata cache is the kind of over-engineering that ends up being exactly right when a repo has 50,000 commits.

The WTFPL license is worth noting [README]. It’s about as permissive as a license gets — you can do whatever you want with the code. No “Fair-code” restrictions like n8n, no GPL copyleft, no MIT’s attribution requirement. For a tool you’re deploying on your own server and potentially modifying, this is the correct license choice.

Features

Based on the README and the live demo at https://git.inept.dev/:

Repository browsing:

File and directory tree browsing at any commit [README]
Commit history with full log [README]
Diff views per commit [README]
Branch and tag listing [README]
Rendered README display with in-memory caching [README]

Performance architecture:

RocksDB metadata store for commits, branches, tags — configurable reindex interval, default 5 minutes [README]
On-demand file/diff loading via gitoxide (not re-read every request) [README]
In-memory cache for READMEs and rendered diffs [README]
Claimed 97% faster load times for large repositories versus naive approaches [README]

UI:

Dark mode included [README]
Responsive layout (based on live demo)

Configuration:

Repository descriptions set via the description file inside the bare repo [README]
Repository owner set via [gitweb] owner = "Name" in the bare repo’s config file [README]
Repository indexing is recursive — point it at a directory, it finds everything [README]

Deployment options:

Single binary (install via Cargo) [README]
Docker image at ghcr.io/w4/rgit:main [README]
Docker Compose supported [README]
NixOS module with full service configuration [README]

What it explicitly does not have:

Push access or authentication of any kind
Issue tracking
Pull requests or code review
User management or ACLs
CI/CD
API

Pricing: SaaS vs self-hosted math

This section is simpler than usual because rgit has no SaaS version and no paid tiers. The software is free under WTFPL [README]. The only cost is the server you run it on.

The practical question is: what are you comparing it to?

If you’re currently using GitHub for private repos:

GitHub Free: free for public repos, free for private repos with limited features
GitHub Team: $4/user/month
Self-hosting rgit + bare repos on a VPS: $4–6/month for a Hetzner CX22, handles hundreds of repos

The math is straightforward for a solo developer or small team that doesn’t need GitHub’s issue tracker, Actions, or code review tooling — just a place to push code and browse it. A $4/month Hetzner box running rgit over SSH-managed bare repos is effectively free.

If you’re comparing it to full self-hosted forges:

Forgejo: free, but needs ~512MB–1GB RAM to run comfortably [1][4]
Gitea: same profile as Forgejo
GitLab: 4–8GB RAM minimum for a real workload [1]
rgit: the README suggests it’s lightweight enough to point at temporary storage for the database (-d /tmp/rgit-cache.db in the quickstart command) [README]. Memory footprint is not documented explicitly but Rust + RocksDB on a small repo set should run comfortably on 256MB.

If you’re already running Forgejo or Gitea and want rgit alongside it as a public-facing read-only viewer, the incremental cost is effectively zero.

Where pricing data doesn’t exist: rgit doesn’t publish benchmarks against cgit or gitweb in a controlled environment. The 97% claim is in the README without a citation [README]. Take it as directionally correct rather than a hard number.

Deployment reality check

What it requires:

A Linux server (or NixOS, or anything that runs Docker)
Bare git repositories — rgit will not work with non-bare repos [README]
Rust toolchain if you’re building from source (or use the Docker image)
A reverse proxy (nginx, Caddy) if you want HTTPS

The bare repository requirement is the first gotcha. If your repos are regular working-directory repos (the kind with a .git folder), you need to either convert them or create bare mirrors. The README links to the official Git-on-the-Server documentation for this [README]. It’s not hard, but it’s a step that will surprise developers who haven’t worked with bare repos before.

Installation path (Cargo):

cargo install --git https://github.com/w4/rgit
rgit [::]:3333 /path/to/my-bare-repos -d /tmp/rgit-cache.db

That’s the full quickstart. Point it at a port, a directory, and a database path. Repository indexing is recursive — you don’t configure individual repos [README].

Docker path:

docker run --mount type=bind,source=/path/to/my-bare-repos,target=/git \
  --user $UID:$GID \
  -it ghcr.io/w4/rgit:main

The user flag matters: the UID/GID must match the owner of the bare repo directory, otherwise you’ll get permission errors [README]. This is the most likely first deployment problem.

NixOS: A proper NixOS module is included with services.rgit service configuration [README]. For NixOS users this is unusually good — most small Rust tools don’t ship NixOS modules.

What can go sideways:

Repos created after startup don’t appear immediately — the reindex interval means up to 5 minutes lag before a new bare repo shows up in the UI [README, based on reindex behavior]
No authentication means rgit is public by default. If you want private repos to stay private, either don’t run rgit on them, or put it behind a reverse proxy with HTTP auth
The project has 202 stars and appears to be maintained by a single developer. There’s no governance structure, no organization, no SLA. If the maintainer moves on, the project stalls.

Realistic time to a working public instance for a developer familiar with Linux: 15–30 minutes, including setting up bare repos. For someone setting up bare repos for the first time: 1–2 hours including reading the git-on-the-server docs.

Pros and cons

Pros

Genuinely fast. RocksDB metadata caching is the right architectural choice. Large repositories with thousands of commits load quickly instead of making you wait while git walks pack files [README].
Rust + minimal footprint. Lower memory usage than Go-based forges, no JVM overhead, no Python interpreter. Appropriate for small VPS deployments.
WTFPL license. Do whatever you want with it. Fork it, modify it, embed it, ship it [README]. No commercial-use restrictions.
Dark mode. Included, not an afterthought [README].
NixOS support. A proper NixOS module is rare for a 200-star project [README].
Docker image. Available at ghcr.io/w4/rgit:main [README]. Standard Docker Compose workflow works.
Simple by design. No database migrations, no user tables, no auth systems to configure. The complexity ceiling is low.
Honest scope. It does one thing — display git repos in a browser — and doesn’t try to compete with Forgejo or GitHub.

Cons

Read-only. No write path, no push, no auth. This is a feature (simplicity) and a limitation (usability) at the same time. If you need anything beyond browsing, this isn’t your tool.
Bare repos only. The working-directory-to-bare conversion step is friction for anyone not already comfortable with git internals [README].
202 stars, single maintainer. Small bus factor. No indication of organizational backing, corporate sponsorship, or a development roadmap. Commits may slow or stop without warning.
No search. Can’t search commit messages or file contents across repos. cgit has this; rgit doesn’t appear to.
No clone links or smart HTTP. rgit displays repos but doesn’t serve them for cloning over HTTP. You’ll still need SSH or configure smart HTTP separately.
5-minute reindex lag. New repos and new commits don’t appear instantly [README]. Not a problem for most use cases, but worth knowing.
No documented REST API. There’s no API surface for programmatic access to repository data.

Who should use this / who shouldn’t

Use rgit if:

You already manage git repositories as bare repos via SSH, gitolite, or similar — and you want a web interface for browsing or public sharing without running a full forge.
You’re on NixOS and want a properly packaged git viewer with a native module.
You run cgit or gitweb and find them slow or ugly. rgit is a direct upgrade in both dimensions.
You want the lowest possible resource overhead for a git web viewer. Rust + RocksDB on a small VPS is about as lean as it gets.
Your repos are public and you don’t need auth at all.

Skip it (use Forgejo or Gitea instead) if:

You want issues, pull requests, code review, CI/CD, user management, or anything resembling a full development platform [1][4].
You’re migrating away from GitHub and need feature parity or near-parity.
You need clone-over-HTTP support without additional configuration.
You want something with a large community and organizational governance. Forgejo is run by a non-profit democratic organization [4]. rgit is one developer’s project.

Skip it (use stagit instead) if:

Your repos are small and rarely updated, and you’d prefer static HTML generated once rather than a running server.
You want zero runtime dependencies.

Skip it (stay on cgit) if:

You need cgit’s built-in search functionality.
You’re in a regulated environment and need a tool with a longer track record and formal security audit history.

Alternatives worth considering

cgit — the incumbent C-based git viewer. Older, less attractive, but battle-tested with a decade of production use. Has search. No Rust, no RocksDB — simpler deployment story on old systems.
gitweb — ships with git itself. Zero additional install. Perl, slow, functional. Fine for internal use where aesthetics don’t matter.
stagit — generates static HTML from bare repos. Fastest possible browsing (it’s just files), zero runtime, no database. Can’t handle very large repos well. Good for tiny public projects.
Gitiles — Java, used by Google internally (including for Android). Mature, fast, read-only like rgit. Much heavier dependency profile (JVM).
Forgejo — full forge: issues, PRs, CI/CD, user management, 100% free software under a non-profit org [4]. Higher resource usage than rgit. The right choice if you want a GitHub replacement, not a viewer.
Gitea — Forgejo’s upstream, same feature set [4]. Forgejo forked from Gitea over governance concerns; for most users the choice between them is marginal.
GitLab Community Edition — full DevSecOps platform. 4–8GB RAM minimum [1]. Overkill for almost every solo or small-team use case.

For the specific use case rgit targets — a read-only web viewer for bare repos — the realistic shortlist is rgit vs cgit vs stagit. Pick rgit if you want speed, dark mode, and Docker deployment. Pick cgit if you want search and a more established codebase. Pick stagit if you want static output and zero runtime.

Bottom line

rgit fills a gap that the “GitHub alternatives” conversation mostly ignores: the developer who already manages their own git infrastructure via SSH and bare repos, and just wants a web UI that doesn’t look like it was designed in 2008. It’s not trying to compete with Forgejo, Gitea, or GitLab. It’s competing with cgit and gitweb — and on performance, aesthetics, and deployment ergonomics, it wins that comparison comfortably. The RocksDB metadata architecture is a genuinely good engineering decision, Rust keeps the memory footprint lean, and WTFPL means you can do whatever you want with it. The caveats are real: single maintainer, 202 stars, read-only, bare repos only, no search. If any of those are blockers, they’re blockers. But if your use case is “I push code over SSH and want a fast way to browse it in a browser,” rgit is the cleanest answer in this category right now.