Bashblog

Last reviewed Sep 13, 2026 · 779 words

Bashblog is not something you host; it is something you run. One script, bb.sh, sits in a directory. You type ./bb.sh post, your $EDITOR opens, you write, you save, and the script writes an HTML file for the post, rebuilds the index page, regenerates feed.rss, and updates the tag pages. The output directory is a finished website. Copy it to any web server and you have a blog with no PHP, no database, no admin login, and nothing to patch. That is the entire appeal, and for a certain kind of person it is the last blog engine they will ever try.

Where it sits in the stack

Think of it as the smallest possible static site generator. It lives on the machine where you write, which can be the server itself over SSH or your laptop with an rsync step. The web server is separate and can be anything that serves files: Caddy, nginx, an object-storage bucket, GitHub Pages. There is no runtime to keep alive and no attack surface beyond the web server's own. Compared with Hugo it has no themes, no templating language and no build pipeline; compared with WriteFreely it has no server process and no federation. The blogging category is full of tools that do more. Bashblog is for the person who wants less.

The workflow, start to finish

git clone https://github.com/cfenollosa/bashblog.git
cd bashblog
./bb.sh post          # opens $EDITOR with a template; save and quit
./bb.sh list          # shows every post with its filename
./bb.sh edit my-first-post.html
./bb.sh rebuild       # regenerate everything after a config change

The first post also drops a .config file. Edit it before the second post: global_title, global_url, global_author, global_email, global_license, and markdown_bin if you want Markdown. Posts are HTML by default; install Markdown.pl (or anything that reads Markdown on stdin and writes HTML on stdout), set markdown_bin to its path, and ./bb.sh post opens a .md file instead. Tags go on the last line of the post as Tags: homelab, zfs, and the script builds a page per tag. Answer no to the "post this?" prompt after saving and the file goes to a drafts folder instead of the index.

If you write on a laptop, deploying is one line:

rsync -av --delete --exclude '.config' --exclude 'bb.sh' --exclude 'drafts' ./ user@server:/srv/blog/

What it generates, and what it will not

You get one HTML page per post, index.html with the latest posts, all_posts.html, all_tags.html, a page per tag, feed.rss, and a single stylesheet you can replace. Pages weigh a few KB and load in one request. The Core Web Vitals piece on static sites explains why that is worth more than any plugin.

You do not get comments (embed a third-party widget or go without), search, image handling beyond copying files into the directory and writing an <img> tag, pagination beyond "index shows N posts", a theme system, or any mobile editing story. Those are not gaps waiting to be filled; the script is 14 years old and deliberately stayed small. If you find yourself wanting three of them, that is the signal to move.

Serving it

blog.example.com {
    root * /srv/blog
    file_server
    encode gzip
}

That is the whole Caddy site block, with automatic TLS. Bashblog has no server component, so the proxy choice is purely about certificates and convenience. On a shared box, the output directory only needs read permission for the web server user; keep bb.sh and .config outside the served path or exclude them as above.

Getting out later

Posts are plain HTML files with a predictable structure. Moving to Hugo means a small script that strips the header and footer and adds front matter; people have written them, and it takes an afternoon for a few hundred posts. Your URLs are /post-title.html, so set redirects when you leave. Nothing is locked in, which is the other half of why 1,927 people starred a shell script.

What I'd do

If you already write in a terminal and you want to publish a paragraph without opening a browser, install Bashblog on the server, set global_url on day one, turn on Markdown, and serve it with Caddy. Commit the directory to git so the posts have a history. Use it until the day you want a theme or a search box, then export to Hugo, which will take less time than reading Hugo's docs. For everyone else, start with Hugo and skip the detour.