Bludit

Last reviewed Sep 13, 2026 · 824 words

Backup, migration and disaster recovery for a Bludit site are all the same command: copy one directory. Content, settings, users, themes and plugins live as JSON and files under bl-content/, there is no database, and a site with 300 pages fits comfortably on a 128 MB PHP host. That is the reason to choose it over WordPress for a small blog, a club site or a documentation page that gets edited monthly. It is also the reason not to choose it for anything that will grow into thousands of posts, because Bludit reads its index into memory on every request.

Installation is unzip, point PHP at it, load the page

Bare metal needs PHP with the mbstring, gd, dom, json and xml extensions and a web server that honours the bundled .htaccess (Apache with mod_rewrite) or the equivalent Nginx try_files rule from the docs. Unzip into the web root, open the site, pick a language and set an admin password. A Docker route exists through the linuxserver/bludit image with a single /config volume, which is what I would use on a homelab box already running other containers. Either way you are done in about 2 minutes, which the catalogue's Easy rating reflects.

Writing happens in a Markdown editor or a TinyMCE-style visual editor, switchable per site. Pages and posts are the same object with a flag, so a static "About" page and a dated post are managed in one list.

Backups are trivial, which changes how you run it

Because everything is in bl-content/, a nightly tar of that directory is a complete backup, and a restore is untar and reload. Version control works too: commit the directory to a private Git repo and every edit is a diff. Compare that with a WordPress backup, which needs a database dump, an uploads folder and a plugin that sometimes gets it wrong. For a site one person maintains, this is the single strongest argument for the flat-file class, and the CMS category has several members that share it.

The trade is performance at scale. Each request loads the pages index, so response times drift upward past a few hundred entries and the admin list gets slow before the public site does. A cache plugin or a CDN in front hides most of it, but if you are planning a 5,000-post archive, start with something that has a real query layer.

Themes and plugins exist, and the paid ones are where the polish went

The bundled themes are clean and mobile-friendly. Free community themes number in the dozens rather than the thousands, and the better ones plus a handful of plugins (backups, forms, galleries) are sold as Bludit PRO. The plugin API is small and readable PHP, so writing your own hook for a widget takes an afternoon rather than a course. The catalogue calls the ecosystem smaller and that is fair; think of it as "enough for a blog" rather than "a marketplace".

Security depends on you updating

Bludit has had authentication bypass and upload bugs in past versions, and a PHP application with a login form on a public site is a target for automated scanners. Three habits cover it: update when a release appears, because the project's cadence is slow enough that each release matters; keep the admin path behind HTTP basic auth or an access rule at the proxy if only you edit; and run it as a low-privilege PHP user with the web root read-only except bl-content/. None of that is unusual, but the "no database" simplicity can lull people into treating it like a static site, and it is not one.

Grav and Hugo are the neighbours to consider

Grav is the bigger flat-file CMS: the same one-folder backup story with a larger plugin catalogue, Twig templating, and a heavier admin. It is the safer pick if you want a flat-file site with room to grow or a designer who expects a proper theme layer. Hugo drops the admin panel entirely and generates static HTML, which is faster and safer still but requires everyone who edits to be comfortable with a text editor and a build step. Bludit is the compromise: a real login and editor for a non-technical author, with the operational simplicity of files.

What I'd do

For a personal blog, a club, or a small business page with one editor: Bludit in the linuxserver container behind a reverse proxy, bl-content/ in a Git repo with a nightly push, admin path restricted at the proxy, and a calendar reminder to check for updates each quarter. If a second editor arrives or the post count heads towards four figures, move to Grav before the migration becomes a project. And if nobody but you will ever edit, skip both and generate with Hugo.