Gollum

Last reviewed Aug 26, 2026 · 801 words

I ran a team wiki for 3 years where the "sync" was git pull, the "backup" was a second remote, and the "edit conflict" was a merge. That wiki was Gollum, and the trade it offers has not changed since 2010: every page is a plain file in a Git repository, the web UI is a thin Ruby app that commits on save, and there is no database, no user table and no permissions system at all. If your team already lives in Git and wants a wiki they can also edit in Vim, Gollum is the most honest tool in the wikis category. If anyone needs "only managers can see this page", it is the wrong one, and no plugin fixes that.

Launch is 1 command, and it works on an existing repo

Gollum is a Ruby gem. On a machine with Ruby 3, libicu and cmake (for the Rugged Git bindings) it is gem install gollum and then:

gollum /srv/wiki --port 4567 --host 0.0.0.0 --allow-uploads page --h1-title

Point it at any Git repository and it serves the Markdown files as pages immediately; a Home.md becomes the front page. The Docker image gollumwiki/gollum wraps the same thing with the repo mounted at /wiki, which is the sane way to avoid the "Ruby toolchain required" con. RAM sits well under the catalogue's 256 MB for a wiki of a few hundred pages.

The flags that matter: --allow-uploads page stores images next to the page in the repo, --live-preview gives a split-pane editor, --mathjax and --css for the people who need them, and --config config.rb for anything else, including authentication.

No login means you supply the login

Gollum ships with no authentication. On a private network that can be fine; on anything else, you wrap it. The two standard patterns are a reverse proxy with forward-auth (Authelia or Authentik in front, which also gets you SSO) or Rack basic auth inside config.rb:

module Precious
  class App < Sinatra::Base
    use Rack::Auth::Basic, "Wiki" do |user, pass|
      user == "editor" && pass == ENV.fetch("WIKI_PASS")
    end
  end
end

Either way the model is binary: you can see and edit everything, or nothing. Commit authorship is a second gap; without configuration every edit is committed as the same author. The config.rb hook that sets session['gollum.author'] from a request header is how you push the proxy's authenticated username into the commit log, and it is worth the 10 lines because "who changed this" is half the reason for a wiki.

Where the Git model pays off

The wins are concrete. A page rename is a Git move with history intact. A bad edit is git revert. A wiki for a project can live inside that project's repository under docs/ and be served by Gollum while Gitea or Forgejo hosts the same files with pull request review. Offline editing is a clone. Migration away is nothing, because the pages were always Markdown, AsciiDoc, Org, reStructuredText or one of the other 10 supported markups in plain files. GitHub's wikis are the same format, so a git clone of a GitHub wiki serves under Gollum unchanged, and that is the fastest way to bring a project's wiki in-house.

The losses are equally concrete. Search is grep-grade. There are no page-level permissions, no comments, no drafts, no page templates with structured fields, and the UI looks like 2012 because it mostly is. Two people editing the same page at once get a merge conflict resolved in the browser, which is workable but not pleasant.

When to pick Wiki.js or BookStack instead

For a public knowledge base with mixed technical and non-technical editors, Wiki.js gives you Git as an optional sync backend plus real permissions, search and a modern editor, at the cost of a Postgres database and a heavier footprint. For a team that wants a book-and-chapter structure and a WYSIWYG editor, BookStack is the friendlier choice and the better Confluence replacement. Gollum wins only when the Git repository is the point.

What I'd do

Engineering team, under 20 people, wiki content owned like code: Gollum in the gollumwiki/gollum container, repo mirrored to your Git forge as the backup, Authentik forward-auth in front with the username header wired into commit authorship, --allow-uploads page on, and a weekly cron git push to a second remote. Anyone who needs per-page permissions or has non-Git users: Wiki.js. I would not run Gollum for a company handbook, and I would not run anything else for a runbook repository that engineers edit from the terminal.