Dillinger

Last reviewed Aug 26, 2026 · 705 words

Dillinger edits one Markdown document at a time, previews it as you type, and exports it as Markdown, HTML or PDF. It does not organise, sync between people, or remember documents anywhere except your browser's local storage. Read that as a limitation and you will be disappointed; read it as a scope and it becomes a small, useful appliance that runs on 256 MB and never needs attention.

Why anyone self-hosts a text box

The hosted dillinger.io is free and has been since 2012, so the self-host case needs a reason. Mine is that the cloud integrations (GitHub, Dropbox, Google Drive, OneDrive, Bitbucket, Medium) each require you to authorise a third-party app against your accounts, and I would rather the OAuth client that reads my repositories be one I run. The second reason is the network: a Dillinger inside the LAN or behind Tailscale works when the internet does not, and pastes of confidential text never leave the building. The third is PDF export, which on the public instance is a shared resource and on yours is a dedicated headless browser.

None of those reasons apply if you just want to draft a README occasionally. Use the public site.

Running it is a single container

Dillinger is a Node.js Express app. The README's Docker instructions are the ones I use, and the unusual flag is the important part:

git clone https://github.com/joemccann/dillinger.git && cd dillinger
docker build -t dillinger .
docker run -d --name dillinger --restart=always \
  -p 8000:8080 --cap-add=SYS_ADMIN dillinger

The app listens on 8080 inside the container. SYS_ADMIN is there because PDF export drives a headless Chromium, which needs the capability for its sandbox; without it, export to PDF silently fails while everything else works. Cloud integrations are off until you drop an OAuth client id and secret for each service into the JSON files under configs/; leave the files out and the corresponding menu entries simply do nothing, which is the state I keep mine in.

There is no login. Anyone who can reach the port can use the editor, and what they type stays in their own browser, so the exposure is low, but put it behind your reverse proxy with a basic-auth rule anyway if it faces the internet.

What to pair it with, because it will not organise for you

Documents live in the browser's local storage. Close the tab and they are still there; clear site data or switch machines and they are gone. That makes Dillinger a scratchpad, not a store, and the useful pattern is to point the export at something that is. Save to a folder synced by Syncthing and you have a versioned Markdown collection. Push to a repository on Gitea and you have history and review. If you want the editor and the storage in one place, that is a different product: SilverBullet or the options in the notes category are editors that own their files.

Where it beats the alternatives and where it loses

Against StackEdit, the closest hosted rival, Dillinger is simpler to run and lighter, with a cleaner writing surface and a working distraction-free mode; StackEdit has better offline handling and a richer export pipeline. Against a real notes app it loses on everything except startup time. Against a desktop editor it wins only when you are on a machine that is not yours or is locked down, which for me is the honest use case: a browser tab on a work laptop where nothing can be installed, writing into a Markdown file that ends up in my own repo.

What I'd do

Run the container on whatever box already hosts your reverse proxy, map it to a LAN-only hostname, skip the cloud integrations, and use it as a fast preview-and-export surface for Markdown that lives somewhere else. Do not try to make it a notes system. If you find yourself wanting folders, search or a second device, you have outgrown it in the best way, and the migration is trivial because everything it ever produced was already a plain .md file.