I built mkblog because I wanted blogging to feel small again.

That does not mean blogging has to be simplistic. It means the basic act of publishing words, code, notes, and terminal demos should not require a stack of rented services, a complicated deployment story, or a heavy runtime framework just to put a few pages on the web. A blog can still be a directory of files. That is a feature, not a limitation.

Too much of the modern web assumes publishing is something you lease from a platform. You sign up, accept the product boundaries, hope the pricing stays reasonable, and treat your own writing like data living inside somebody else's software. Static site generators push back on that. They turn source files into plain output you can keep, copy, host anywhere, and understand without reverse engineering a vendor's idea of content management.

That is the part I find democratic. If your site is just generated HTML, CSS, and assets, then publishing stops being reserved for people willing to run a large application stack. You do not need a third party to host your files. You do not need a fancy server framework. You do not need to keep a database and an admin panel alive forever just to preserve old posts. You can build the site locally and ship the result wherever ordinary files can live.

mkblog is my version of that idea: a small CLI that reads Markdown with YAML front matter and produces a static site. The interface is intentionally direct:

go run ./cmd/mkblog build
go run ./cmd/mkblog serve --watch

That shape matters to me. A command-line tool is honest about what it does. You point it at content, it emits a site, and the output remains yours.

I also wanted terminal-native publishing to be part of the tool instead of an afterthought. mkblog has built-in Asciinema support, so local cast files can live beside the rest of your content in content/casts/ and be embedded in posts with the shortcode system. That means terminal demos do not need to be bolted on through a separate blog platform or outsourced to some other publishing workflow. If the post is yours, the cast can be yours too.

The workflow is intentionally simple. Put a recording at content/casts/demo.cast, add these tags {{< >}}, and inside add this:

{{< asciinema "/casts/demo.cast" theme=amber loop=true autoplay=true speed=1 rows=3 cols=70 >}}

That shortcode points at a local file that ships with the rest of the site. No external embed host is required. You can set a player theme such as amber, solarized-dark, or none, and you can tune behavior with parameters like loop, autoplay, speed, rows, and cols. In this post I am using the amber player theme and shrinking the terminal window to 3 rows by 70 columns so the embed reads like a compact terminal aside instead of a full-height session.

Here is the existing demo.cast embedded in this post:

There is a small Unix argument hiding in all of this. Unix culture has always had a useful suspicion of unnecessary layers: text files, composable tools, simple interfaces, outputs you can inspect. mkblog is not literally old Unix software, but it is trying to preserve some of that spirit. The teletype-* themes lean into it on purpose. They are a nod to paper terminals, command lines, and text-first computing, but also a reminder that plain text still travels well.

I do not think everyone needs to publish this way. But I do think the option matters. Static site generators keep the floor low enough that one person with a text editor and a shell can still make a durable home on the web. That is good for hobbyists, good for independent writers, good for small technical blogs, and good for anyone who wants their site to outlast the fashion cycle of web tooling.

If blogging is going to stay open, it helps to keep the machinery legible. mkblog exists because I wanted a tool that treated publishing like a file problem, not a platform subscription.