LeoMoon Wiki-Go: a flat-file Go wiki that keeps its data in Markdown

The problem Wiki-Go targets: documentation you can copy with cp

Most wiki software asks you to accept a database before you write a single page. That means a schema, a migration path, a backup job that understands the schema, and a restore procedure that has to be tested rather than assumed. LeoMoon Wiki-Go removes that layer. The README describes it as a "databaseless flat-file wiki platform built with Go", and the Dockerfile confirms the shape of the thing: a single statically linked binary that exposes a volume at /wiki/data. Everything the wiki knows lives under that one directory.

The audience follows from the storage model. A small team that wants internal documentation without standing up Postgres. A solo developer who wants a personal knowledge base that survives a hosting migration because it is just files. Anyone who has been burned by a wiki whose export format was never quite complete. If your content is already Markdown and you would rather not convert it into rows, the pitch is direct.

It is also worth being clear about what the project is not. The repository topics list documentation, knowledge-base and collaboration, not CMS or publishing platform. Nothing in the README describes theme development, a plugin API, or a template override system. Those absences are design decisions, not gaps waiting to be filled by a future release.

How the storage and rendering pipeline actually works

The dependency list in go.mod tells you most of the rendering story. github.com/yuin/goldmark is the Markdown parser, gopkg.in/yaml.v3 handles configuration, golang.org/x/crypto covers password hashing, and github.com/gosimple/slug with github.com/gosimple/unidecode generate URL-safe directory names. That is a deliberately small dependency set, and the Dockerfile builds with -mod=vendor against a checked-in vendor directory, so builds do not reach out to the network for modules.

Content is organised as nested directories. Each document is a directory containing a document.md file, and the README is explicit about how the two names diverge: documents sort alphabetically by directory slug, while the title shown in the sidebar and heading comes from the first H1 in document.md. Prefixing a slug with a number, as in 1-overview, moves it up the sidebar without changing what readers see. This is a useful trick and also a trap, because renaming a slug to fix ordering changes the URL of a page that people may have bookmarked.

Search is implemented in-process rather than delegated to an external index. The README lists exact phrase matching with quotes, inclusion and exclusion of terms, and highlighted results. Version history is also file-backed: the README describes tracking changes with full revision history and restoring previous versions, and the data volume is the only place that history can live.

The container image runs as a non-root appuser with PUID and PGID build arguments defaulting to 1000, and it declares EXPOSE 8080 443 with VOLUME ["/wiki/data"]. If you mount a host directory owned by a different UID, you will hit permission errors before you hit any application bug.

Installing Wiki-Go with Docker and writing your first page

The README gives a Docker quick test as the first path. The image is leomoonstudios/wiki-go, the container listens on 8080, and the data directory is mounted at /wiki/data. Run this from a directory you are happy to keep:

docker pull leomoonstudios/wiki-go
docker run -d \
  --name wiki-go \
  -p 8080:8080 \
  -v "$(pwd)/data:/wiki/data" \
  leomoonstudios/wiki-go

After the container starts, open http://localhost:8080. The data directory you mounted is where config.yaml and your page directories will appear once the application writes them.

If you are terminating TLS at a reverse proxy, the README supplies docker-compose-http.yml for the plain HTTP case:

docker-compose -f docker-compose-http.yml up -d

This also starts the wiki on port 8080. The README warns that if the proxy-to-container hop is plain HTTP you must set allow_insecure_cookies: true in data/config.yaml, and it explains why: Wiki-Go sets the Secure flag on cookies by default, browsers reject Secure cookies over non-HTTPS connections, and login then fails. The README's own security note says to use that setting only in development or trusted internal networks, and to use HTTPS for public-facing wikis. Treat it as a development switch, not a deployment default.

The README also mentions server.trusted_proxies for login throttling. It says to add only the reverse proxy's exact IP address or network, and that the default is an empty list. That is the correct default: trusting a broad range would let clients spoof their address in throttling decisions.

To create your first page through the UI, add a document and give its directory a slug such as 1-getting-started, then put a single H1 at the top of document.md. The sidebar will show the H1 text while sorting the page first.

Where the flat-file model pushes back

The same property that makes Wiki-Go easy to back up makes concurrent editing awkward. There is no database transaction layer to serialise writes, and the README does not describe conflict resolution, edit locking, or a merge strategy for two people saving the same document at once. Version history lets you recover a previous revision after the fact, which is not the same as preventing the collision. For a small team writing different pages this rarely matters. For a group editing one long document in real time, it will.

Scale is the second boundary. Full-text search runs inside the application against files on disk. The README makes no claim about index size limits or search latency, and there is no separate search service in the dependency list or the repository layout. If your corpus is tens of thousands of pages, the absence of any stated benchmark means you should test with your own content rather than assume it holds up.

Finally, the HTTP login problem is a genuine failure mode rather than a footnote. A user who deploys behind a proxy, skips the allow_insecure_cookies setting, and sees login silently fail has no obvious path to the cause unless they read the configuration note. The README places that note near the top, which is the right call, but the failure itself is opaque from the browser.

On maintenance: the last push was on 2026-09-14, and releases v1.9.1, v1.9.0 and v1.8.13 shipped on 2026-09-14, 2026-09-06 and 2026-08-21 respectively. The repository is not archived. That is a recent release cadence, though the README does not document a support window or a long-term release branch.

Wiki-Go compared with a database-backed wiki such as Wiki.js

Wiki.js is the natural comparison point, and the difference is architectural rather than cosmetic. Wiki.js stores content in a database and offers a choice of several, which buys it structured queries, a mature authentication layer, and a large module ecosystem. It also means your content lives in tables until you export it, and your backup strategy has to understand the database engine you picked.

Wiki-Go takes the opposite position. The README's framing is "No database. No bloat. Zero maintenance. Just Markdown." The practical consequence is that a backup is a directory copy and a migration is rsync plus a config file. You give up the query layer: there is no way to join across pages or run ad hoc SQL against your content. If your wiki is also a data source for other systems, that is a real loss.

The feature sets overlap more than the storage models suggest. Wiki-Go documents access rules with public, private and group-restricted visibility, user groups, admin, editor and viewer roles, comments with moderation, Kanban boards, Mermaid diagrams, MathJax, custom shortcodes and a REST API. The repository ships rest-api-examples.http, so the API has concrete examples rather than only prose. That is a broader feature list than the phrase "flat-file wiki" implies, and it is the main reason to look past the storage model when comparing.

Where Wiki.js wins is ecosystem and depth of integration. Where Wiki-Go wins is operational surface area: one binary, one volume, one config file.

Licence, upgrade cost and what GPL-3.0 means for a self-hosted wiki

Wiki-Go is licensed under GPL-3.0, and the repository includes a LICENSE file at the top level. For the common case, running the wiki for your own team or your own notes, the licence imposes no practical obligation: you are not distributing the software, so the copyleft terms do not attach to your content or your configuration. Your Markdown stays yours.

The situation changes if you redistribute the binary, ship it inside a product, or modify it and hand the modified version to others. GPL-3.0 requires that those recipients get the corresponding source under the same terms. This is a real constraint for anyone embedding a wiki into a commercial appliance. It is not legal advice, and if your use is close to that line, the LICENSE file and a lawyer are the two things to read, in that order.

Upgrade cost is low by construction. The Dockerfile pulls a fresh binary and the data volume is separate, so replacing the image does not touch your pages. The Makefile builds versioned binaries for linux_amd64, linux_386, linux_arm64, linux_arm5, linux_arm6, linux_arm7, linux_s390x, windows_amd64, windows_arm64 and macos_arm64, and the version string is injected at build time through wiki-go/internal/version.Version. The README does not document a rollback procedure or a schema migration step, which is consistent with a file-based store but leaves you to handle a bad upgrade by restoring the data directory yourself.

Editorial conclusion

LeoMoon Wiki-Go fits teams and individuals who want a self-hosted knowledge base whose content is plain Markdown on disk, and who are comfortable running one container behind a reverse proxy that terminates TLS. It is the wrong tool if you need a database-backed query layer, a plugin ecosystem, or a hosted service, because all three are outside what the repository describes. Before you commit, verify three things on your own machine: that the login flow works with your proxy and cookie settings, that the REST API surface in rest-api-examples.http covers the integrations you need, and that a restore from a copied data directory actually reproduces your pages, since the README does not document a rollback procedure.

Frequently asked questions

Official sources

1. leomoon-studios/wiki-go on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases