Raneto

Last reviewed Sep 13, 2026 · 807 words

Raneto is a folder of Markdown files with a search box and a sidebar in front of it, and that is the whole product. The point is that there is nothing else: no database, no migrations, no user table, so the entire knowledge base backs up with git commit and restores with git clone. If you already keep docs in Markdown, Raneto is the fastest way to give a team a browsable, searchable web version of them. If you want people to write documentation in a browser, you will be happier elsewhere, and I say which elsewhere below.

The file tree is the information architecture

Drop files into content/ and Raneto renders them; directories become sections, filenames become page titles unless you override them. Ordering and metadata live in a comment block at the top of each file:

/*
Title: Restoring the Postgres backup
Description: Step-by-step for the nightly dump
Sort: 2
*/

First, stop the application and check free disk space.

That is the full authoring model. Because content is plain files, every tool you already own works on it: your editor, grep, pull requests, a CI job that checks links. Screenshots go in the same tree. A 200-page internal runbook is a 5 MB directory that anyone can read even when the server is down.

Themes are a template folder; the default is clean enough that most installs never touch it. Raneto has been around since 2014 and its MIT-licensed codebase is small enough to read in an afternoon, which is the correct amount of complexity for a tool whose job is to render files.

Running it: Node, one folder, port 3000

Raneto is a Node.js application. Clone the repository, npm install, npm start, and it listens on port 3000 serving whatever is in content/. The repository ships a Dockerfile, and the container needs exactly one volume:

services:
  raneto:
    build: https://github.com/ryanlelek/Raneto.git
    ports:
      - "3000:3000"
    volumes:
      - ./kb-content:/app/content
    restart: unless-stopped

Configuration is a single config.js: site title, base URL, the content path, and a few switches. The catalogue's 256 MB minimum is generous; on an idle box it uses a fraction of that. Full-text search is built in and indexes the files on request, which is instant for hundreds of pages and still fine for thousands.

Authentication and the web editor are the optional 20 percent

Two switches change the character of the install. authentication: true puts a login in front of the site with credentials from the config file, which is enough to keep a personal or small-team knowledge base private; for anything more, put Authentik or a reverse-proxy auth in front instead of relying on one shared password. allow_editing: true adds a browser-based editor so logged-in users can create and edit pages without touching the filesystem.

The editor is basic, and the catalogue's "basic editing workflow" con is fair: a textarea with preview, no concurrent editing, no revision history beyond whatever version control you run underneath. It works for fixing a typo from a phone. It is not how you want to write 40 pages.

When BookStack or MkDocs is the better answer

The wikis category splits along one axis: do authors write in a browser or in files? BookStack is the bigger project for browser-first teams, with a WYSIWYG editor, permissions, revision history and a proper database, and if your colleagues are not comfortable in a text editor, choose it and stop reading. MkDocs is the files-first alternative that generates a static site, so it needs no Node process at all and hosts anywhere, at the cost of a build step and no live web editing.

Raneto sits between them: files-first like MkDocs, but served live so a saved file shows up immediately, with the small web editor for emergencies. That niche is real. It is a solo operator's runbook, a small engineering team that keeps docs next to code, a support team publishing 50 articles that one person maintains. The community is small, so expect to read the source when something odd happens, and expect releases to be infrequent rather than absent.

What I'd do

Keep the knowledge base in a git repository, mount it into the container above, and deploy updates by pulling the repository on the server with a cron job or a webhook. Turn on authentication only if the content is private, and leave the web editor off unless someone specifically asks for it. If more than three people will write regularly, or any of them will resist Markdown, run BookStack instead and accept the database. For a one-person or docs-as-code team, Raneto is the least infrastructure that still gives you search.