One of the most common questions we get is simple:
“Which CMS does Frontmatter support?”
The short answer is:
none — in the core.
This is not a limitation.
It’s a deliberate architectural decision.
The real cost of shipping adapters
CMS adapters look harmless.
They promise:
- faster onboarding
- easier demos
- broader appeal
In practice, they introduce hidden costs.
Every adapter:
- couples your core to someone else’s roadmap
- imports a foreign data model
- creates compatibility expectations
- becomes a permanent support surface
Once an adapter lives in the core, the question is no longer “does this work?”
It becomes “why doesn’t this work with my setup?”
That’s not a technical problem.
It’s a product trap.
The core needs a single responsibility
Frontmatter Core does one thing:
It turns frontend code into a stable data contract.
That contract is the product.
The moment the core starts:
- talking to CMS APIs
- generating CMS-specific config
- adapting to editor workflows
…it stops being a contract and starts becoming an integration layer.
Integration layers never stop growing.
Adapters invert the ownership model
Most CMS-first workflows assume this:
The CMS defines structure.
The frontend adapts.
Frontmatter inverts that:
The frontend defines structure.
The CMS adapts.
If the core ships adapters, ownership quietly shifts back to the CMS.
Suddenly:
- the CMS becomes the source of truth
- the frontend is constrained again
- the IR becomes an internal detail instead of a contract
That defeats the entire purpose.
A stable IR is more valuable than any adapter
Adapters age.
CMS APIs change.
Editor features evolve.
Integrations break.
A stable Intermediate Representation does not.
By keeping the core CMS-agnostic:
- the IR stays boring
- adapters stay optional
- experimentation stays cheap
- failure stays local
You can:
- write your own adapter
- fork an existing one
- throw it away entirely
The core doesn’t care.
Reference implementations are not commitments
Frontmatter uses CMS integrations as reference implementations, not guarantees.
They exist to show:
- how the IR can be consumed
- what a mapping might look like
- how far you can take the workflow
They do not define the product.
The core does not promise:
- compatibility
- support
- completeness
- coverage across CMS ecosystems
That boundary is explicit.
This keeps the project honest
Not shipping adapters in the core forces discipline.
It prevents:
- roadmap drift
- integration sprawl
- accidental product promises
It also attracts the right users:
- developers who value explicit contracts
- teams comfortable owning their tooling
- people who prefer boring infrastructure over magic
If you’re looking for a tool that “just plugs into everything”, this isn’t it.
The trade-off is intentional
Yes, this approach is stricter.
It assumes:
- a code-first workflow
- comfort with build-time tooling
- a willingness to wire things together explicitly
In exchange, you get:
- no runtime dependency
- no CMS lock-in
- no hidden coupling
- no forced abstractions
The core stays small. The surface stays sharp.
The rule we don’t break
Frontmatter does not adapt to CMS.
CMS adapt to the IR.
That rule keeps the project coherent. Breaking it would make adoption easier in the short term — and impossible to sustain in the long term.
We choose the long term.