I have been running the same Obsidian vault across three machines for two years and hating the sync step every time. Then a 200-line Docker container replaced the entire syncing rig, and I have not opened the official sync client since. The story is short. The point is not that the container is clever. The point is that plain text files plus a tiny web server are enough to be a personal wiki, and I should have done this years ago.
Why Obsidian kept getting in the way
Obsidian is a Markdown editor (an editor that writes plain text files with simple formatting marks like # heading and **bold**) with a local graph view. The editor is fine. What I was paying for, without naming it, was the sync, and the sync kept getting in the way.
The first problem was the official Obsidian Sync, which charges $4 per month for end-to-end encrypted sync (the sync server cannot read your notes) across devices. I tried it for six months. It worked, in the sense that the files showed up on the other machines. It also conflicted in ways that produced duplicate files with -conflict-2025-12-03T1507 suffixes, and I had to manually clean those up roughly once a month.
The second problem was self-hosting Obsidian’s syncing through any of the community plugins. The community has built several. The one I tried most recently was the “Remotely Save” plugin pointed at a WebDAV share (WebDAV is a protocol that lets you read and write files over HTTP the way you would on a local disk). It worked for about three weeks, then a single large file (a 12MB PDF embedded as a base64-encoded data URI, a way of embedding binary content as a long text string inside Markdown) corrupted the share, and the WebDAV server on my NAS refused to serve the file for the rest of the vault. I spent a Sunday rebuilding the share.
What I should have caught earlier was that the value I was getting from Obsidian was not the sync. It was the graph view (a force-directed graph that shows which notes link to which other notes) and the backlinks panel (a panel that shows every note that links to the note you are currently viewing). Both of those features work on a local folder of Markdown files. I did not need a sync service to get them. I needed the files to be on the same disk on all my machines, and a way to read and edit them when I was on a machine that did not have my home folder mounted.
What the container does
The container is a small Node.js app called Wiki.js. Wait, no. Let me back up. The container I actually run is requarks/wiki, which is the Wiki.js project’s own image. There are at least three alternatives I considered before landing on it: BookStack (a PHP app with a book/chapter/page hierarchy), DokuWiki (an older PHP app, no database required, writes everything to flat files on disk), and plain nginx serving a directory of Markdown files rendered with a small client-side script.
The one I picked is requarks/wiki because it has the two features I wanted from Obsidian built in: a graph view and a backlinks panel. The image is about 380MB. It runs as a single container with a Postgres database next to it (PostgreSQL, a popular open-source relational database). The whole stack comes up in about 90 seconds on my NAS.
I mounted the Markdown content directory from the host into the container at /wiki/data/content. That is the only volume I care about. The Postgres data is in a separate volume that gets backed up with the rest of my NAS snapshots, but I do not actually need it for the content. The Markdown files are the source of truth. The database is an index on top of them.
The container reads the Markdown files on disk, parses them into a page tree, and serves the rendered HTML on a web port. The web UI has the same graph view I was using in Obsidian, except it draws the edges in green instead of blue. The backlinks panel is in the right sidebar, same as Obsidian. The Markdown editor is a textarea with a preview pane. It is not as nice as Obsidian’s editor. It does the job.
How I actually use it day to day
The container runs on the NAS, which is on my home network. From any machine on the network, I open http://nas.local:8080 and I am in the wiki. From outside the network, I tunnel through Tailscale (a mesh VPN, a virtual private network that connects your devices directly without going through a central server) and reach the same URL. There is no public port forward. The wiki is not on the public internet.
Editing happens in the browser. The editor is a vanilla contenteditable div (a plain HTML element that the browser lets you edit in place, no JavaScript framework required) with a few keyboard shortcuts. I write notes in Markdown, save, and the file on disk updates. If I want to use Obsidian for editing on the same machine, Obsidian opens the same folder and reads the same files. Obsidian and the wiki container do not conflict, because Obsidian reads and writes the files directly, and the wiki container only reads them on page load.
For my phone, I use a different setup. I have Markor (an open-source Android Markdown editor) pointed at the same folder via Syncthing (a peer-to-peer file sync tool that copies files between your devices without a central server). Syncthing is the only sync tool in this stack, and it has not corrupted a file in two years. The phone does not have the graph view. The phone has a search box and a list of recent files. That is enough for note-taking on the go.
The total stack is four pieces: the wiki container, a Postgres container, Syncthing on the phone and the desktop, and an Obsidian install I keep around for the editor. The wiki container does not know Syncthing exists. Obsidian does not know the wiki container exists. They both read the same folder of Markdown files, and that folder is the source of truth.
Trade-offs
The wiki container is not free in setup time. The first run took about three hours, including pulling the image, configuring the Postgres connection, setting up the LDAP bind (LDAP, Lightweight Directory Access Protocol, is the protocol most companies use for centralized login) for authentication, and writing the nginx reverse proxy config. The reverse proxy alone took 40 minutes because I had to look up the websocket upgrade headers for the wiki’s live-preview feature, and the docs are sparse. If you are not comfortable debugging 502 Bad Gateway errors in nginx logs, plan for the first afternoon to be longer than you think.
The wiki container is not free in maintenance, either. Wiki.js ships a major version every 9 to 12 months, and each one has broken the LDAP config at least once in my experience. I pin the version in my docker-compose file (a YAML file that lists the containers, networks, and volumes for a Docker app) and I read the upgrade notes before pulling. The Postgres database has grown to about 1.2GB over two years, mostly from the version history the wiki keeps. Backups take longer than they used to.
Obsidian community plugin work is the biggest thing I gave up by moving to the container. There are thousands of community plugins for Obsidian, and the wiki container has none of them. If you rely on a specific plugin (Dataview for table-like queries against your notes, Excalidraw for hand-drawn diagrams, the templating system), you will feel the loss. I do not use any of those plugins, so the loss is zero for me. Your math will be different.
If you are running a single machine and you do not care about phone access, a folder of Markdown files plus Obsidian’s local-only mode is simpler than this whole stack. If you need to share notes with one other person, Syncthing plus Obsidian is also simpler. The wiki container earns its keep when you have three or more machines that all need read and write access, and you want a web view that works on any device with a browser. That is the case I was in, and the container is the right tool for it.
What I would tell past me
If I could send a message back to the version of me that first installed Obsidian Sync two years ago, I would say three things.
- The value in a personal wiki is the file format, not the editor. Any tool that reads and writes plain Markdown files will give you most of what you need. Pick the editor based on the device you write on most. Do not pay for sync.
- Self-hosting a small web app is cheaper than you think, and harder than you think, in roughly equal measure. The image is free. The Postgres database is free. The reverse proxy is the part that takes time. Budget an afternoon for the first setup, and an hour a year for upgrades.
- A backup is not a backup until you have restored from it once. Pull a copy of the Markdown folder to a USB drive every few months and try opening the latest note in a fresh Obsidian install. If you cannot, the backup is a comforting lie.
The Markdown files in my wiki folder are 4,200 of them, totalling about 38MB. They have survived two NAS rebuilds, three laptop migrations, and a move across the country. They are the most durable thing I have ever made on a computer. The container is just the way I read them.
What held up under two years of use
A few small habits that have paid for themselves in this stack, in case you go the same route.
- Pin the wiki image to a specific version tag.
requarks/wiki:2.5is much easier to debug thanrequarks/wiki:latest. The major versions change the database schema (the structure of the tables and columns Postgres uses to store wiki data), and you do not want a surprise migration at 2am. - Back up the Markdown folder separately from the database. The folder is small (38MB in my case) and survives almost anything. The database is bigger and changes with every version. A
tarof the folder to a USB drive is a 5-minute job and has rescued me twice. - Keep Syncthing on a separate schedule from the wiki container. The container does not need to know Syncthing exists. Let the two pieces of the stack fail independently. If Syncthing corrupts a file, the wiki will serve the corrupted file and you will notice quickly.
- Test the LDAP bind after every wiki upgrade. This is the one thing that has broken every single time I have upgraded. Plan for it. The fix is the same every time, but it is annoying.