Best Rust CMS in 2026: Pure Rust, Wasm, or Hybrid?
The best Rust CMS depends on what you want Rust to do. A headless API written in Rust, a Markdown site running on WebAssembly, and a PHP CMS that uses Rust for selected expensive operations solve different problems. The language alone does not tell you who can edit, how a draft becomes public, or what you must operate in production.
Our short answer: choose Pushword when you need a full PHP/Symfony CMS with optional Rust acceleration; evaluate NUR CMS for a Rust-first headless CMS; try RaisFast if you want an ambitious single-binary backend and can accept an early alpha; and choose Bartholomew when the target is a Markdown site on Spin. For a Git-authored static site, compare the Rust generator Zola with Hugo, which is written in Go, not Rust. Neither is a multi-user editorial CMS on its own.
This is Pushword’s blog, so our interest in the first option is obvious. We checked the projects' own documentation in September 2026; this is a guide to their stated architecture and current scope, not an independent benchmark or a certification of production readiness.
There is no fair single speed ranking across these products: they do not run the same workload, and their public documentation does not provide a controlled head-to-head test.
Feature differences that change the decision
| Product | How content is edited and stored | What visitors receive | Product boundary |
|---|---|---|---|
| Pushword | Browser admin; database, with optional flat-file sync | Dynamic pages or static export | Editing, users, media and an optional write API live in the CMS; Rust workers accelerate selected operations |
| NUR CMS | Vue admin; PostgreSQL | Rust REST API in Markdown, HTML or AST form | Headless content and media; the public website is yours to build |
| RaisFast | Embedded React admin; SQLite, PostgreSQL or MySQL | Rust API and built-in blog/backend modules | Broadest claimed backend scope here, with an explicit early-alpha warning |
| Bartholomew | Markdown files with TOML headers and a CLI | Pages rendered by a Wasm component on Spin | Templates and content serving; no conventional multi-user admin |
| Zola | Markdown files in a site repository | Static files produced by a Rust build | Site generation, not a content-editing service |
| Hugo | Content files in a site repository | Static files produced by a Go build | Site generation, not a content-editing service or a Rust project |
Editing and publication. An admin form is a practical difference, not a cosmetic one. Pushword exposes page and media editing in its admin, a token-authenticated REST API, and optional page history. NUR documents a Vue admin and REST output; RaisFast lists an embedded admin, roles, and workflow modules, but still calls itself early alpha. By contrast, Hugo has draft, publication and expiry dates in front matter, and Zola has a draft flag. These control what a build includes. Neither ships integrated editor accounts, approvals, or deployment workflows. Bartholomew also supports unpublished content and a documented preview mode, but its documented editing path is Markdown files and the bart CLI.
Content model and presentation. NUR is explicitly headless: its README lists Markdown, rendered HTML, and AST output, so a separate frontend decides how to display it. Pushword renders through Twig but can also expose content through its API. RaisFast advertises dynamic schemas and automatic CRUD APIs; validate the particular schema and permissions you need before treating those claims as equivalent to an established editorial workflow. Hugo’s content types, taxonomies, and page bundles organize files at build time. Its “headless bundles” expose unpublished content and resources to templates, not a live headless CMS API; a JSON output format is still generated during the build. Zola likewise offers sections and taxonomies for static pages. Bartholomew renders Markdown with Handlebars on requests to Spin, a different delivery model from either generator.
Media, languages, and extension points. Hugo can transform page-bundle images, build multilingual sites, and compose modules and an asset pipeline. Zola has image resizing, multilingual content, Sass and a build-time search index, though the search interface is left to the site. Those are substantial site features: calling either generator “just Markdown” understates it. NUR’s documented media upload/processing and Wasmtime plugins belong to a running CMS, while RaisFast advertises several plugin engines. Pushword’s media library and Symfony bundles address the same needs through its PHP application. The overlap in feature names does not erase the difference between generating an asset during a build and letting an editor upload it in an authenticated admin.
Pushword: a CMS with optional Rust on the hot path
Pushword remains a PHP 8.5 and Symfony 8 CMS. It has an admin, flat-file editing, and an API for agents and other clients. Its Rust integrations are separate, opt-in executables: the content worker can analyze rendered content and convert eligible Markdown blocks, while the static-generator package can minify HTML. PHP still owns routing, permissions, Twig, publication, and the fallback for native work that is unavailable or declined. Composer does not download a Rust binary. The architecture and setup are documented here.
This is useful when the team wants a CMS now, already knows PHP, or deploys to hosting where a native executable may not be possible. It is not a pure Rust CMS. Both native test suites run in CI and compare supported results with PHP. Pushword’s published timings measure particular content operations; they are not a promise that every public request or whole site becomes several times faster.
NUR CMS: Rust-first headless content
NUR CMS combines an Axum backend, PostgreSQL via SQLx, and a Vue 3 admin. Its README describes Markdown, HTML, and AST output, media processing, localization, REST endpoints, and Wasmtime-based plugins. The maintainer also describes using it as a library inside another Rust project.
That makes NUR the clearest fit here when you want content served through a Rust API and are happy to build the presentation layer separately. Evaluate its editing and deployment workflow with your own schema before adopting it; a feature list cannot tell you whether its admin fits your editors.
RaisFast: broad scope in an early alpha
RaisFast describes a Rust/Axum backend with an embedded React admin, dynamic content types, search, e-commerce, jobs, and JavaScript, Rhai, Lua, and Wasm plugin engines. Its README describes a single-binary deployment and support for SQLite, PostgreSQL, and MySQL. It also explicitly says Early Alpha and warns that the API may change before 1.0.
If your goal is an all-in-one backend rather than only a website CMS, that scope is interesting. Treat the feature list as a starting point for a pilot, not as proof that every module is ready for your production workload. Check the specific path you will use: content modeling, admin permissions, upgrades, and backup/restore matter more than the number of built-in modules.
Bartholomew: a micro-CMS for Spin
Bartholomew is a Rust component compiled to WebAssembly and run by Spin. Its content is Markdown with TOML headers, rendered through Handlebars templates; Rhai can add template functions. That is a coherent choice for a small, code-owned site already headed for Spin.
It is not a standalone native server or a conventional multi-editor admin. The deployment platform is part of the product choice. If editors need forms, media workflows, roles, or live preview, establish how you will provide those before choosing it on runtime grounds.
Visual and code-first projects to evaluate
My Rust CMS is centered on a visual page builder. Its repository describes a Rust/Axum backend, Yew/Wasm frontend, PostgreSQL, Docker setup, and drag-and-drop editing. It is the one to try if visual composition is your deciding requirement. The README calls it production-ready; we have not independently verified that claim, so test its editor and deployment path with real content first.
derived-cms takes the opposite approach: define Rust entities and generate an admin interface and headless API from those types. It fits a developer who wants to own the application model in code. It is a crate to build with, rather than a CMS that an editorial team can install and use without Rust development.
AvoRed Rust CMS describes Axum, SurrealDB, and a React admin in its README, but says many admin pages are still being redone and lists REST and GraphQL APIs on the roadmap. On that evidence, we would validate the exact API and admin features needed before selecting it as a headless production CMS.
Zola and Hugo: the static-site alternatives
Zola is written in Rust and uses Tera templates. It is a strong fit for a code-owned blog or documentation site: Markdown, taxonomies, image resizing, multilingual content, and a search index can all be produced by the build. Its draft flag keeps pages out of normal builds, but it does not approve a draft or deploy the result.
Hugo is a Go static site generator. It builds from content files and gives developers a broader set of built-in composition tools: content archetypes, page bundles, custom taxonomies, shortcodes, multilingual configurations, image transformations, modules, and the Hugo Pipes asset pipeline. Its front matter handles drafts and future or expired pages. These are real advantages if the team wants to assemble a complex static site without operating an application server. Hugo is not a Rust CMS, however, and its build-time JSON output or “headless” page bundle should not be mistaken for an authenticated content API.
Both generators shift publication to the repository and deployment pipeline. Adding a Git-backed editor such as Decap CMS is possible, but authentication, preview, review policy and build deployment then span more than one product. A simple site may benefit from that separation; a busy editorial team should test the complete workflow, not the generator alone.
How to choose
Start with a representative page and one real publishing task. Have a developer model content, an editor revise it, and an operator deploy and restore it. Then measure the operation that is actually slow: uncached Markdown conversion, media processing, publication, or public requests. A Rust implementation of one component does not by itself establish a faster whole-site experience.
If your priority is all-Rust ownership, start with NUR for headless content, RaisFast for a broad backend pilot, or Bartholomew for Spin. If you only need a Git-authored static site, compare Rust-based Zola with Go-based Hugo on the site features above; Hugo belongs in that decision even though it does not qualify as a Rust CMS. If your priority is an editorial CMS with optional native acceleration, start with Pushword.
Sources
The feature descriptions above come from project documentation and repositories, not a hands-on acceptance test of every editing flow.
- Pushword: admin, API, static generator, and native acceleration.
- NUR CMS: project README.
- RaisFast: project README and alpha notice.
- Bartholomew: Fermyon overview and quickstart.
- Zola: overview and content documentation.
- Hugo: documentation, front matter, and image processing.