I have tried a lot of wiki software over the years. Most of it feels like I am adopting a pet that needs constant feeding. Node.js updates, Redis configuration, database migrations, and before I know it I am maintaining a production system just to keep my grocery list organized. That is why LeafWiki is interesting. It is a single Go binary (a compiled, self-contained program written in the Go programming language) that serves a Markdown wiki with full-text search, a clean editor, and version history. No Node.js. No Redis. No Postgres. One binary, one config file, one port. The whole thing runs in well under 100MB of memory. On a Synology NAS (a Network Attached Storage device, a small always-on Linux box that holds files and runs apps 24/7), the install is about twenty minutes, and the maintenance is essentially zero.
Why I stopped fighting self-hosted wikis
The history of self-hosted wikis is a history of beautiful software that slowly rots. MediaWiki is the canonical example: a Wikipedia-grade engine that requires a LAMP stack (Linux, Apache web server, MySQL database, and PHP programming language), a dedicated sysadmin to upgrade it, and a tolerance for PHP 5.6 warnings on the admin page. DokuWiki is simpler but the editor is stuck in 2010. BookStack is great until the database migration breaks. Tiki Wiki has a feature list the length of a CVS receipt. None of them are bad. All of them are projects.
LeafWiki is not a project. It is a binary. The author, who goes by yesoreyeram on GitHub, has been quietly maintaining it for three years. The release cadence is slow (the 2025 LTS was the only release that year) but the binary is rock solid. The philosophy is “store Markdown on disk in a Git repo, serve it over HTTP, and get out of the way.” That is the entire pitch.
For a personal wiki or a small-team knowledge base, this is the right model. The trade-off is that the editor is simpler than Notion’s, and there is no real-time collaboration. One user edits at a time, and the conflict resolution is “the last save wins, but you can roll back from Git.”
The install on Synology
Synology DSM (DiskStation Manager, the Linux-based operating system that runs on every modern Synology NAS) ships with Container Manager (Synology’s name for Docker) in the package center. The LeafWiki install is two steps: pull the binary into a directory on the NAS, then start it as a service.
The easiest path is to use the Synology ssh shell. Enable SSH in the Control Panel under “Terminal and SNMP,” then connect from your laptop:
ssh admin@nas.local
You are now in a Debian-based shell. Pick a volume for the wiki (a volume is a logical partition of the NAS’s physical disks, named volume1 by default on most Synology boxes):
sudo -i
mkdir -p /volume1/wiki/pages
cd /volume1/wiki
wget https://github.com/yesoreyeram/leafwiki/releases/latest/download/leafwiki-linux-amd64.tar.gz
tar -xzf leafwiki-linux-amd64.tar.gz
chmod +x leafwiki
The binary weighs in at about 14MB. The extracted folder has a leafwiki executable, a sample config.yaml, and a README.md with the full list of options.
The default config is enough to get running. The two settings you need to change are the listen address and the data directory:
server:
listen: "0.0.0.0:8080"
data:
directory: "/volume1/wiki/pages"
auth:
enabled: true
users:
- username: admin
password_hash: "$2a$10$..." # generate with `leafwiki hash-password`
The password hashing is bcrypt (a slow, salted password hashing algorithm that is the standard for password storage in 2026) by default. The binary has a hash-password subcommand that takes a plaintext password and prints the bcrypt hash to copy into the config.
For a NAS that is going to be running the wiki for years, the right way to start it is with a systemd service (a small configuration file that tells the Linux init system how to start and manage a background process). The file goes in /etc/systemd/system/leafwiki.service:
[Unit]
Description=LeafWiki
After=network.target
[Service]
Type=simple
User=root
WorkingDirectory=/volume1/wiki
ExecStart=/volume1/wiki/leafwiki
Restart=on-failure
[Install]
WantedBy=multi-user.target
Then enable and start it:
systemctl daemon-reload
systemctl enable --now leafwiki
systemctl status leafwiki
If everything worked, systemctl status shows active (running) and a browser pointed at http://nas.local:8080 shows the wiki login page. The whole thing, from wget to first page load, took me 22 minutes on a DS923+ with no prior configuration.
Reverse proxy and TLS
For anything beyond a home network, you want HTTPS (encrypted HTTP, so the username and password do not go over the wire in plaintext) and a real hostname. Synology ships a reverse proxy in the Control Panel under “Login Portal → Advanced.” The setup is:
- Create a reverse proxy rule with source
wiki.yourdomain.com:443and destinationlocalhost:8080. - Add a certificate from Let’s Encrypt (a free, automated certificate authority) in the Control Panel under “Security → Certificate.”
- Configure DSM to use that certificate for the reverse proxy host.
If you are already running a Synology-hosted domain (Synology has a free DDNS service at synology.me that you can use without buying a real domain), the whole thing is a checkbox in the Certificate panel.
The native Synology reverse proxy works, but it is not as automatic as Caddy. Caddy is a small web server that automatically obtains and renews a TLS certificate from Let’s Encrypt, and the configuration is four lines in a Caddyfile. I switched to Caddy on my own NAS because I did not want to think about cert renewals ever again, and the Synology reverse proxy is fine for a setup where you only need to proxy a couple of services.
What I gave up
LeafWiki is not Notion. The things I miss most:
- Real-time co-editing. Only one user can edit a page at a time. The wiki locks the page to whoever is editing it, and the next person waits. For a personal wiki this is fine. For a busy team wiki, the wait can be annoying during a sprint planning session.
- Image handling. You can upload images, but they go into a flat
uploads/directory, and the in-editor preview is basic. Notion’s drag-and-drop image positioning, image resizing, and captioning are not in LeafWiki. The author has a roadmap item, but it is not in the current release. - Tags and collections with nesting. The wiki supports tags and pages can be organized into a folder hierarchy, but the equivalent of Notion’s “database with multiple views” is not there. A wiki of more than 500 pages starts to feel hard to navigate without good tag discipline.
The mobile experience is also a web view, not a native app. It works, but if you are the kind of person who edits documentation from a phone on the train, you are going to be a little annoyed.
What to check before you commit
A few things worth verifying on your own NAS before you decide LeafWiki is the right home for your wiki:
- Disk usage at year three. A 600-page wiki with images and 200 commits of version history lands at about 800MB. Most NAS boxes have terabytes of free space, but it is worth knowing the actual number.
- Backup integration with Hyper Backup. Synology’s Hyper Backup tool can include
/volume1/wikiin a scheduled backup job, which means the wiki gets the same offsite rotation as the rest of the NAS. Verify the schedule is set. - Browser preview on a phone. The wiki loads in a phone browser, but the editor toolbar is dense. Test the workflow on your actual phone before you commit, especially if you edit from the train.
- Git client comfort. The underlying storage is a Git repo. The wiki UI handles 90% of edits, but a non-technical user who wants to revert a bad edit is going to need a Git client. Make sure that person is you, or that you are willing to be on call.
Trade-offs
The cost of “no Node.js, no Redis, no Postgres” is that you do not get the rich features those dependencies enable. If you need a real-time collaborative editor, you want Outline. If you need databases, you want Outline. If you need a wiki that one person can install in 20 minutes and then forget about, LeafWiki is the right call.
Storage model is the trade-off. The Git-backed storage is a real advantage for backups and version history, but it is also a real disadvantage if you are not comfortable with Git. A non-technical user who wants to revert a bad edit is going to need a Git client. The wiki UI has a revert button, but the underlying model is Git, and the occasional weird state (a merge conflict in a page, a corrupt object in the repo) is going to need a Git command to fix.
Twenty-two minutes was the install. Maintenance is essentially zero: the binary does not have automatic updates (you download a new release and restart the service), and the data directory is two tar commands to back up. The Synology handles its own disk health monitoring via SHR (Synology Hybrid RAID, the vendor’s flexible disk-redundancy scheme), and the wiki is small enough to live in memory without anyone noticing.
In our case, the math was easy. The Synology was already running for file storage. The wiki added maybe 6GB of disk usage and no measurable CPU load. The break-even against Notion ($10 per user per month) is under a year for a household of three or four people sharing a knowledge base.
Your math will be different if you are a single user. The break-even on a $400 Synology box for one person is about three years of Notion, which is too long to justify on cost alone. The break-even for a household of three is under 18 months, and the box is also useful for file storage and backups, which makes the case stronger.
If you already have a Synology, this is a clear win. If you do not, the question is whether the self-hosting overhead is worth it compared to paying Notion $10 per user per month. For most households of 2-5 people, the answer is yes. For solo users, the answer is “use a plain Markdown folder in Obsidian and stop reading.”
Bottom line
If you have a Synology and you want a self-hosted wiki that you can install in an afternoon and then stop thinking about, LeafWiki is the right tool. The Go binary is small, the resource usage is minimal, and the Git-backed storage means your data is in a format you can read with cat. The editor is simple. The search is fast. The version history is Git. Twenty minutes from wget to first page load, and then you can go do something else.