Hydra is now Inka

Our page builder has a new name. Why Hydra had to go, what Inka refers to, and why a tool meant to sit above several CMSes belongs with a foundation rather than with us.

The page builder we've written about here as Hydra is now called Inka. Same project, same repository, same commit history — a new name, a sharper description of what it does, and a home that isn't ours.

Why the name had to go

Hydra was a genuinely good name. Headless took the head off, and a hydra has many — which was the claim exactly: one editing experience across as many frontends as you need. The line outlived the name, and we still use it. Headless took the head off; we give it as many as you need.

Everything else the word carries was working against us. It is crowded in software. The idiom is unhelpful — a hydra is an intractable problem that grows back, which is not the association you want for your tooling. And for most people the first thing it brings to mind now is Marvel, not Greek myth. A name you have to keep explaining is costing you something.

Why Inka

Inka refers to Inca masonry: stones shaped to fit their neighbours rather than forced square, laid without mortar, still standing after five hundred years and repeated earthquakes.

That is the architecture, not the decoration. Inka's adapters are shaped to fit each backend instead of flattening every backend into one common shape, and the fit is load-bearing rather than something applied afterwards. Fitted, not forced.

On the reference itself: we use it because it is substantive rather than ornamental. Inka is a title rather than a living people's self-name, and the Quechua-derived spelling is the respectful one. We keep the visual language on the masonry-and-engineering side, away from ceremonial or mystical imagery.

Where it came from

Inka started here, as an answer to a problem we kept running into: the upgrade burden in monolithic CMSes. When the editing interface, the templates and the content store are one codebase, every upgrade touches all three at once, and a site's frontend is hostage to its CMS's release cycle. Rewrites get deferred until they are unavoidable, and by then they are enormous.

Dylan Jay proposed and mentored it as a Google Summer of Code topic, and Mohammad Hussain built the proof of concept — successfully. PretaGov then took it on as an internal project to produce the first real version. The first commit landed in May 2024, and there have been ten contributors since.

Why it speaks to more than one CMS

We have been migrating organisations off legacy CMSes since 2003, and we are not zealots about it. We have built and recommended Sanity, Strapi, Contentful, Drupal and Wagtail when the brief was right for them, and we have moved intranets off Squiz Matrix when it wasn't. Plone is what we reach for most, for reasons we have written about before, but it has never been the only thing we touch.

That experience is where the adapter architecture comes from. Any organisation of a certain size has more than one content store — the main site on one thing, an intranet on another, a register or a case system on something bespoke — and the honest answer is rarely to migrate all of it onto a single platform. It is to let editors work across all of it in one place, with the same design system rules applying wherever the content lives. Plone today, Drupal and WordPress next.

Inka itself started as Plone code — the editor grew out of Volto, which is why the Plone adapter is the one in service today. The adapter layer is what takes it past Plone: the same editing experience and the same design system rules, over whatever content store sits behind it.

Open source, and where the line is

We could have kept this closed, and we didn't. Inka is open source: you can read the code, run it yourself, and see where it is going.

That matters more than usual for something like this. A page builder that sits above your content stores is infrastructure — you are going to build your design system into it. You should be able to read it, fork it, and keep running it whatever we do next.

We would rather be precise than sound purer than we are. The editor, the adapter API and the conformance suite are open source. What you pay for is the set of things a compliance team asks for: reporting and evidence, the record of overrides, roles and approvals, shared rules across sites, and single sign-on. You install it on your own infrastructure — nothing phones home, no content leaves your network, and nobody else decides when you upgrade.

What works today

Inka works. It runs this site — the page you are reading was edited in it — and it is in production in client work we have delivered.

The NSW work is the clearest case for it. We built the NSW Digital Design System in Plone 6 and Volto — 16 theme components shadowed, 25 manage components shadowed — so agencies with independent branding could run compliant sites. Every one of those shadows is a place where a design system had to be forced into a CMS rather than fitted to it. We are converting our NSW government sites onto Inka now, where the design system is what the editor is built around rather than something layered over it. Here is what is in it today, and where we are taking it.

The plans are the point. A page builder that holds editors to a design system is useful on its own. One that does it across every content store an organisation already has, and holds AI agents to the same rules as people, is a different proposition — and that is where this is going.

Getting involved

The code, the issues and the roadmap are public — inka.sh has the current links. Two cases in particular are worth getting in touch about: you are an agency building a page builder for a client's design system, or you maintain a content store you would like an adapter for. Those are the two Inka is built for.