Open-source platform · Rust + WebAssembly

open.blog

A self-hosted blogging platform: write Markdown files, get a fast static site with feeds, search, themes, scheduling, and an optional browser-based publishing studio.

My role: Creator · Maintainer

Live demo GitHub

The live site is a working open.blog instance. Try search, the light/dark toggle, or a post with runnable code. The publishing studio runs locally: install the CLI, add a user, then run openblog serve --admin.

The problem

Hosted blogging platforms own the database, the theme, and often the audience. Moving a blog later means exporting, converting, and hoping links and formatting survive.

The solution

open.blog keeps every post as a plain Markdown file in a folder you control and builds a static site from it, with RSS, JSON Feed, sitemap, structured data, and client-side search. Themes are JSON design tokens compiled to CSS custom properties, and the optional publishing studio edits the same files.

My contributions

Designed a Cargo workspace that separates an I/O-free core engine (parsing, rendering, themes, feeds, search) from its WebAssembly bindings and the openblog command-line tool.
Compiled search and live Markdown rendering to WebAssembly, so the same Rust code renders posts at build time and previews them in the browser editor.
Built themes as inheritable JSON design tokens, plus native Web Components for search, code copying, light/dark mode, recipe scaling, and runnable Rust lessons.
Added a login-protected publishing studio with drafts, scheduling, themed previews, accessibility and SEO review, and Git-based publishing to GitHub Pages.

Behind the project

The platform behind my own writing at Journey to Code. I wanted a blog I fully own: content in Git, a site that reads well with JavaScript turned off, and enough built-in structure for tutorials, recipes, and research posts without plugins.

Engineering decisions

Every enhancement has to degrade gracefully. Posts render as complete, semantic HTML first; Web Components only add behavior on top. Content checks flag accessibility items that need human review, such as table structure, instead of claiming automated compliance.

Testing

CI runs cargo fmt, Clippy with warnings denied, the workspace test suite, Node tests for the web components, a documentation link checker, example-site builds, and Playwright browser tests. I built the CLI and served the example site and publishing studio locally to capture these screens.