Hexo

Last reviewed Aug 26, 2026 · 877 words

Hexo has no admin panel, no database, and no server process. Your "self-hosted blog" is a folder called public/ that any web server can serve on 256 MB of RAM, and generating that folder for a few hundred posts takes seconds. If you write in Markdown and are comfortable with a terminal and git, it is one of the least demanding things you will ever host. If you want a Write button in a browser, stop here and look at Ghost or WordPress, because Hexo will not grow one.

Four commands cover the whole workflow

Install the CLI, scaffold a site, write, preview:

npm install -g hexo-cli
hexo init blog && cd blog && npm install
hexo new "First post"
hexo server

hexo new drops a Markdown file with front matter into source/_posts/, and hexo server previews it at http://localhost:4000 with live reload. When you are ready, hexo generate (or hexo g) writes the finished HTML, CSS, and assets to public/. That is the entire runtime story: no cron, no PHP-FPM, no upgrade mail on a Tuesday. Site-wide settings (title, permalink format, timezone, pagination) live in one _config.yml at the root, and the Hexo docs list every key on a single page.

Serving it is a 4-line Caddyfile or an rsync

Because the output is plain files, hosting is any static host, and the self-hosted version is trivial. On the box that will serve it:

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

Caddy fetches the certificate itself. Getting public/ there is rsync -av --delete public/ server:/srv/blog/public/ from your laptop, or the hexo-deployer-git plugin pushing the built site to a repo that a Forgejo or Gitea Pages-style setup serves. Either way the server never runs Node; only your writing machine does. A blog served this way scores near-perfect on Core Web Vitals without effort, which the static-site performance post covers.

The theme decides more than Hexo does

The default theme, Landscape, is functional and dated. Almost everyone switches, and the 2 safe choices are NexT (minimal, enormous configuration surface, well maintained) and Butterfly (more visual, popular for photo-heavy blogs). Themes install as a folder under themes/ or as an npm package, and you activate one by setting theme: in _config.yml. Hexo also supports an alternate theme config file named _config.<theme>.yml at the site root, so theme upgrades do not stomp your settings. Use that, not the theme's own config file.

One thing to know before choosing: a large share of Hexo's user base and theme authors are Chinese-speaking, and several excellent themes document Chinese first. That is not a problem, but it does explain why some READMEs read the way they do.

Plugin rot is the real maintenance cost

Hexo has been around since 2012, sits at 41,772 stars, and the plugin ecosystem is large and uneven. Renderers (hexo-renderer-marked, hexo-renderer-ejs), generators (sitemap, RSS, search index), and deployers are all separate npm packages, and many were written for a Node version that no longer exists. The failure mode is an innocent npm update that breaks the build with a stack trace 40 lines deep.

Two habits prevent most of it. Commit package-lock.json and only bump versions deliberately, once or twice a year, after checking the plugin's last commit. And when output looks wrong after any change, run hexo clean before debugging; the generated cache (db.json) causes more phantom bugs than any plugin. Stick to the current Node LTS, not the newest release.

No admin UI is the design, not an oversight

The hexo-admin plugin exists and gives you a browser editor, but it has been lightly maintained for years and I would not build a habit on it. The Hexo way is any Markdown editor, a scaffolds/post.md template you customise once so every new post arrives with the tags and categories block you want, and git as the publishing button. Drafts go in source/_drafts/ and stay unpublished until hexo publish.

Hexo, Hugo, or Astro in 2026

Hugo is a single binary, builds faster, and needs no npm, which makes it the lower-maintenance choice if you have no other reason to run Node. Astro is the pick if you want components and a modern frontend toolchain around your posts; the Astro vs Hugo comparison covers that split. Hexo wins when you already live in Node, want a mature blog-specific theme ecosystem rather than a general site generator, or are inheriting a Hexo site that works. Nobody should migrate a working Hexo blog for the sake of it.

What I'd do

New blog, no Node elsewhere in my life: Hugo. Already using Node, or adopting an existing Hexo site: keep Hexo, install NexT, put the theme config in _config.next.yml, commit the lockfile, and deploy with rsync to a Caddy box. Budget one afternoon a year for the Node and plugin bump and otherwise never think about it, which is exactly what a blog engine should let you do.