What’s behind the name

Fri, 06 Nov 2026 00:00:00 GMT

There are only two hard things in Computer Science: cache invalidation and naming things.

— Phil Karlton

One down. Ask us about the cache in a year.

How hard could it be?

We wanted something nice and short. A little fun, but not a joke. Technical enough for developers to take seriously, friendly enough to get it right away. The kind of word you type into a terminal without wincing and say in a meeting without explaining.

That’s half of it. A developer product’s name also has to be available in surprisingly many namespaces:

domain name
CLI command
npm package and scope
Ruby gem
Python package
Homebrew formula
GitHub organization
X handle

It also should not step on anyone’s toes: not already someone’s company, product, library or trademark.

We went through hundreds of candidates. Bless AI automation! Of course, the good ones were taken. Some almost did it, but in the end it turned out there is a popular OSS library with that name or a registered trademark.

Head·less

head·less /ˈhɛd.ləs/ adjective

without a head.
computing running without a screen or interface: a headless server, a headless browser.
of a CMS storing content and serving it over an API, leaving the website to you.

Riffing on the word headless, we landed on Nohead. Loved it. Checked the list: available (almost) everywhere. Card out, domain secured!

The product does what a headless CMS does, and more: it’s a full-featured data layer, a superset of a CMS, if you like. You define collections of typed fields. People edit the content in the editor, while apps and agents work with it through the API, the SDKs, the CLI or the MCP server. Search, images, roles and the full history of every change are built in. That’s why neither “headless” nor “CMS” made it into the name.

The logo

The logo concept almost came bundled with the name: a figure lifting its head off. Simple, and a little fun. We’re not into mascots, but it could play one if asked.

The .io part

It was available, and it fits perfectly. In tech circles, .io reads as I/O: data in, data out. That’s what the product is about. Content goes in through the editor, the API, the CLI or an agent. Data comes out through the API to whatever shows it. And you can export all of it as plain files.

No-head. One word. Capital N.

Written by a human, with an AI agent drafting through Nohead’s own MCP server. It lets agents read your schema, write and publish records, and compare or revert revisions, within their API key’s permissions.

Why we’re building Nohead

Mon, 02 Nov 2026 00:00:00 GMT

“The CMS landscape is pretty bleak.”

— A teammate, discussing what to power our next project

It wasn’t for lack of choice: there are more content management systems than ever. It was that each came with a catch, usually one of the same few.

Off the shelf

Some had an editor people dreaded writing in. Others were pleasant enough but only understood pages and posts, so anything else had to be dressed up as a page: a product catalog, a list of job openings, the settings behind an app. Images could be uploaded, but resizing and delivering them was somebody else’s problem.

The capable ones were heavy. Weeks to learn, a platform to run, and usually an opinion about the whole site: its themes, its routing, its page builder. Many of them were built for a single website. The moment an app, a script or an agent needed the same content, the API was an afterthought, or ours to build. Where there was AI at all, it was a chat box in the sidebar.

And then the price: seats, locales, environments and API calls, each metered on its own, until the system holding the content cost more than the product it served.

But git?

So we did what plenty of teams do. We kept the content in the repository as Markdown files, with an open-source editing interface on top.

It worked well enough to ship. Living with it was another matter. Every edit went through the same process as code: fixing a typo meant a pull request, a wait for CI, a review and then a build. Anyone with a post to publish needed write access to the codebase, and a paid seat with our host, since their commits triggered deploys.

The content itself fared no better. Editors still wrote raw Markdown and front matter, where one stray colon breaks a page. A post pointed at its author by filename and trusted that the file was there; nothing checked. Images sat next to the code at whatever size they came in, and every version of every image stayed in the repository’s history for good.

Git is excellent at what it was built for: code changes, made by developers. Content is changed by different people, at a different pace, for different reasons.

But vibe coding?

There’s a third option now: describe what you need to an agent and let it build you a content system. We build with agents every day, and an afternoon really does get you something that works.

Something that works is the easy part. A content system lives in its details: validation, permissions, history, uploads, two people editing the same record. Around it sits the infrastructure: hosting, a database, file storage, image processing, a CDN. Then come the ways the content gets out: an API for your site and apps, a search index, access for agents. All of it has to be kept running, patched and backed up, long after that afternoon.

What we’re building instead

Nohead is the content system we kept wishing for, and more: a data layer for your apps, agents and website, structured like a database and comfortable to write in like a CMS. You define your data as collections of typed fields, and everything around it comes in one place:

a web editor for the people who write, with roles instead of repository access
a REST API with a public OpenAPI contract, and SDKs for TypeScript, Python and Ruby
a CLI and an MCP server, so scripts and coding agents work with your data too
webhooks, so your site rebuilds or your app reacts when content changes
file storage behind a CDN, with images resized and converted by URL
search with typo tolerance and filters, through the API or straight from your site
version history for every record and every schema change, including which client made it

The rule that holds it together:

Everything the editor does with content and schema can also be done through the API, the CLI, the SDKs or MCP.

The editor is just another client, and so is an agent: it uses an API key with the scopes you give it, goes through the same validation as a person, and every change it makes is attributed to it in the history.

It’s also deliberately not your whole backend: no page builder, no end-user accounts or arbitrary SQL, and no built-in AI you didn’t ask for.

	Off-the-shelf CMS	Git	Build your own	Nohead
Editing for non-developers	Varies	Repository access	Build it	Yes, with roles
Data beyond pages	Squeezed into pages	Files, by convention	Yes	Any collection
Relationships	Varies	Filenames, unchecked	Build it	Checked on save
Images and files	Often add-ons	In the repository	Build and host	Included
Search	Often basic	A separate service	Build and host	Included
History of every change	Varies	Commits	Build it	Content and schema
An API for apps and agents	Second to the editor	Build it	Build it	API, SDKs, CLI, MCP
Who keeps it running	Them, or you	You and your host	You	We do

From zero to an API

A backend for your data is a few commands away:

nohead login
nohead collections create posts
nohead fields add posts title --type text --required
nohead fields add posts body --type rich-text

And your site reads it like any other API:

import { Nohead } from "@nohead/sdk"

const nohead = new Nohead({ richText: "html" }) // reads NOHEAD_API_KEY

for await (const post of nohead.records.list("posts")) {
  console.log(post.data.title)
}

This blog runs on exactly that. Its posts live in a Nohead project, and the site reads them at build time with a published-only key, so a draft never reaches the page.

Your data stays yours

Everything you put in can come back out. nohead export writes plain files: your schema as YAML, one JSON Lines file per collection, and, if you ask, every original file and every record’s history. The SDKs and the CLI are MIT-licensed. The engines underneath are named rather than hidden: search runs on Meilisearch and images on imgproxy, so your site uses their own documented options, not a wrapper we made up.

Where to start

Quickstart: create a project, publish a record and fetch it from your code
The editor: what writing in Nohead looks like
Agents: coding agents and your own, working with your data
Docs: guides, the SDKs and the API reference
Pricing: the plans, including Free

Sign-up is open. If you’ve ever called the CMS landscape bleak yourself, we’d love to hear what you were looking for: write to hello@nohead.io.

Nohead blog