In production since 2025 · early access
A headless CMS.
One binary.
Content types as JSON5 schemas. Content as files next to your code — diffable, reviewable, in your Git history. Delivered through a REST API. No Node runtime, no mandatory database, no container zoo.
- 1
- process — API and admin UI on one port
- 3
- storage backends, migratable in both directions
- 0
- external services in the minimal setup
// types/article.json5 — drop the file in, the collection exists
{
name: "article",
fields: [
{ name: "title", type: "string", localized: true },
{ name: "text", type: "content" },
{ name: "image", type: "image" },
{ name: "author", type: "reference", to: "person" },
],
}# no build step, no migration run
$ curl rustycms.local/api/collections/article
{ "items": [ … ], "total": 42 }A CMS shouldn't be an infrastructure project
Most headless CMSs solve the editing problem and create an operations problem in return. RustyCMS turns that around.
Operations eat the margin
Node process, database, Redis, object storage, reverse proxy — five things that can break at night, for a website with 200 pages.
The content lives somewhere else
Code in Git, content in someone else's database. No diff, no review, no clean rollback. Staging and production drift apart.
The bill grows with you
Per seat, per project, per API call. With a SaaS CMS you pay the most exactly when the project finally works.
Three steps, nothing in between
- 01
Define a type
One JSON5 file in types/ describes the fields. Drop it in — the collection exists. No generator, no migration run, no restart ritual.
- 02
Editors get to work
The admin UI builds the form from the schema: lists with search and filters, conditional fields, sortable arrays, reference pickers, version history with one-click restore.
- 03
The frontend fetches it
REST with filters, sorting, pagination and full-text search. The OpenAPI spec generates your TypeScript types. Astro, SvelteKit, Next — your call.
What's inside
Not a kit you assemble first. This is the current state, running in production. Every item has its own page with details.
Model
- Schemas without migrations
- String, number, boolean, date, rich text, array, object, reference, multi-select, image, file, geo point, date range. Conditional fields, reusable partials.
- Inheritance
- Schema packs that extend collections — merged per field, overridable per environment.
- Multilingual per field
- Mark a field as localized; the API returns the requested language with fallback.
- Schema migrations
- Rename or delete a field across all entries and environments — with a dry run before anything happens.
Edit
- A real admin UI
- Forms generated from the schema, conditional fields, bulk actions, Cmd+K search across everything.
- Undo everything
- Every write is versioned: field diff, one-click restore, audit log across entries.
- Scheduled publishing
- published / draft / archived, plus publish-at and expire-at executed by a background loop.
- Full-text search
- Built-in index with prefix, phrase and field search — per language, no external search service.
- Media management
- Folders, tags, credits, upload tickets for phones, ingest optimization on upload.
Deliver
- Image pipeline
- On-the-fly resize and crop, AVIF/WebP by Accept header, focal point, DPR, blurhash placeholders, two-tier cache.
- Draft preview
- Signed short-lived links; the live preview streams the editor's unsaved form state.
- REST API
- Filters, sorting, pagination, reference resolution, ETags, batch endpoint, OpenAPI spec for type-safe frontends.
- Integration
- MCP server for AI tools, webhooks, Prometheus metrics.
- Access & keys
- API keys with roles per collection and space, sessions, CSRF protection, brute-force throttle.
Extend
- Many sites, one instance
- Spaces with their own content, their own languages and shared schema bundles.
- Pull in external data
- External collections map any HTTP JSON API in read-only, with cache and time-series history.
- Plugins
- Comments, forms, redirects, wiki — optional, compiled in per feature, each with its own admin page.
- Three storage backends
- Files, SQLite or PostgreSQL — same API, same schemas, switchable in both directions with store-migrate.
- Runtime configuration
- Change settings in the admin UI, hot reload without restart, every change versioned with rollback.
- Export, backup, Git mirror
- Whole instance out and in as ZIP, automatic backups, read-only copy of the content as a Git working tree.
Try the API
The same list query your frontend fetches make: filter, sort, page, pick fields. Click through the examples or write the query yourself.
Runs entirely in your browser against a demo dataset — no server, no sign-up. The query syntax is the one the real API uses.
Examples
GET /api/content/article?
Suffixes: _prefix · _contains · _min · _max · _in · _ne · _exists. System parameters start with _.
Response
The interface your editors work with
Included, not bolted on. Same process, same port.
Who it's built for
Developers & freelancers
You want a CMS you don't have to operate.
- One binary next to the frontend, done — no Node process, no compose stack
- Content lives in the Git repo: branch, diff, review, rollback like code
- Types come from the OpenAPI spec, the frontend stays type-safe
Agencies
You have twenty client projects and twenty hosting contracts.
- Spaces: several sites on one instance, separate content, shared schemas
- One host instead of one instance per client — operations don't scale with client count
- No per-seat pricing that eats your margin as soon as the team grows
Clubs, SMBs & municipalities
You need a website someone can actually maintain.
- Editing interface in plain language, no training week
- Runs on a server in Germany — your content stays with you
- No running license per editor, no lock-in to a vendor
Start small without walling yourself in
Three storage backends, one API, one schema format, one test suite. store-migrate moves an installation between all three — in both directions. The decision at project start is not a one-way street.
For those who want the details
Rust with Axum. A statically linked binary, API and admin UI on the same port. No Node at runtime, no interpreter, no mandatory database. Runs on the smallest VPS you can rent.
Files
One project, one server, content in Git
JSON5 on disk. Diffable, reviewable, deployable with rsync. No database service involved.
SQLite
When many entries tire out the filesystem
Same API, same schemas. One file, one backup.
PostgreSQL
Several instances, SQL queries, real load
Indexed, queryable with SQL, several processes on one database — plus a read-only mirror back into Git.
Already running
Not a prototype. These sites are maintained daily by non-developers, on a single VPS.
Early access
RustyCMS isn't generally available yet. Tell me briefly what you're planning — I'll get back with an honest assessment of whether it fits your project.
- · No newsletter, no tracking, no sharing.
- · Your request lands directly in my inbox — running on RustyCMS.
- · Pricing isn't settled yet. Early adopters get a say.
Questions that come first
- Is RustyCMS open source?
- Not currently. The source is closed and the license and pricing model aren't settled yet. Early adopters will be asked when that decision is made.
- What do I need to run it?
- A Linux server and the binary. In the smallest setup no database service, no Node, no Docker. If you want containers, there's an image.
- What do I build the frontend with?
- Whatever you like. RustyCMS only provides the REST API and an OpenAPI spec. Currently in use: SvelteKit and Astro.
- Can we get out again?
- Yes, and that's by design. In file mode your content is readable JSON5 in your Git — even without RustyCMS. Export and import exist on top of that.
- How much content can it handle?
- File mode carries normal websites with thousands of entries. Beyond that you switch to SQLite or PostgreSQL with store-migrate — same API, same schemas.
- Is there a demo?
- Not public yet. On request I'll show the admin UI on a real installation.