Fóir as an alternative to EmDash

EmDash is an open-source CMS that runs inside an Astro site, on a stack you look after. Fóir is managed and serves any front end over an API. The differences are what you operate and what your content can reach.

Side by side

Price

Fóir
£0.99, £29 or £99 a month
EmDash
Free to license, then hosting, patching and security on you

Content management

Fóir
Standard
EmDash
Standard

Keeping it running

Fóir
Managed, nothing to patch
EmDash
Database, storage, backups and upgrades, on you

Front end

Fóir
Any framework, or none
EmDash
Astro only

API

Fóir
Typed GraphQL, generated
EmDash
REST, or query functions inside Astro

Hosted auth

Fóir
Sign-in, roles and tokens included
EmDash
Sign-in you host, five fixed roles

Personalisation

Fóir
Built in, resolved per request
EmDash
Build it yourself

Agent access

Fóir
Content and control plane
EmDash
Content, schema and settings

Extensions

Fóir
Apps, from a marketplace or a URL
EmDash
Plugins, with a sandbox you configure

Backend beyond content

Fóir
Operations, hooks, schedules, secrets
EmDash
Plugin hooks and routes, run on your stack

Many sites

Fóir
A project each, one workspace
EmDash
A deployment each

Search and vectors

Fóir
Full text, embeddings, geo
EmDash
Full text

Data ownership

Fóir
Postgres export, access rules included
EmDash
Self-managed database

EmDash's behaviour is taken from its published documentation, current at October 2026. Where we say a thing is absent we mean absent from the product and its official plugins, not impossible to build. Corrections are welcome and we will make them.

What a free licence costs to run

EmDash costs nothing to license. The cost is the software you now run: a database, media storage, backups, and each upgrade and security patch that follows. Its documentation makes your team responsible for all of it. A missed patch or an untested backup puts your own data at risk, and your clients' with it.

Fóir is managed, for £0.99, £29 or £99 a month. You have no database to run and no release to apply, and security updates are our job.

Any front end, and more than one

EmDash runs inside an Astro application and serves its admin from the same deployment as the site. A project built in another framework cannot use it, and its documentation says it is unlikely to fit when several front ends need one content service.

Fóir is a hosted API. A website, a native app and an agent read the same typed GraphQL schema, generated from your models, whatever each one is built with.

Apps for the console, operations for your logic

EmDash plugins come in two formats. A native plugin runs in the same process as your site, with full access to it. A sandboxed plugin needs a runner you configure, and on Node.js that is a second process your server starts and you keep running.

A Fóir app puts a tool in the console beside the content it works on, and the install preview shows what each of its operations can read or write. Your own logic is an operation: you register an endpoint, and Fóir calls it with a signed payload, retries a failure and records every run.

Built for agents as well as people

EmDash serves MCP from a route on your own site, covering content, schema and settings. The endpoint an agent connects to is part of the deployment you secure and keep current.

Fóir runs a hosted MCP server that reaches the control plane as well as records: models, hooks, schedules, keys and configuration. An agent works inside the permissions of the person who connected it, and its writes to a model with publishing land as drafts. A read-only grant stays read-only whatever the agent reads later.

Every client from one workspace

Each EmDash site is its own deployment, with its own database and media storage. Twenty client sites means twenty of each to upgrade and back up.

Fóir gives each client a project inside your workspace, administered from one place, with keys that serve that project alone. Tenants who should share a schema live as organisations inside one project and inherit its models.

You can still leave with everything

The usual reason to run a CMS yourself is that the data stays yours.

It does here too. One command produces a Postgres database you own, with a table per model, references as real foreign keys, and your access rules translated onto it.

What you would otherwise assemble

A content API is the smallest part of what an application needs. These come with it.

Publishing

Drafts, full version history, revert, publish at a future time, and bulk rollouts when a batch has to go live together.

Model behaviour

Per model: versioning, publishing, variants, or none of them. Records can be plain data, owned by a customer, or public.

Permissions

Roles for your team and roles for your customers, plus per-record visibility and grants to a named person.

Hosted sign-in

Password, one-time code, and social or OIDC providers, on your own domain, with tokens and refresh handled for you.

Media and assets

An asset library with upload, transformations and responsive renditions, and the same access rules over files as records.

API keys

Each key reaches exactly the models and operations you allow, against a schema generated for that project.

Automation

Cron schedules, lifecycle hooks on publish and change, outbound operations, and a vault for the keys they need.

Notifications

Transactional email and push to web, iOS and Android, from the same events your content already emits.

Notes and tasks

Comments anchored to the record they concern rather than to a page, assignable to whoever has to act on them.

Ask Fóir

An assistant that works your content through the same tools and permissions your team has, staging its edits for review.

Work that carries on without you

Assign a task to Fóir and it works while you are away, coming back on the note when it needs an answer or is done.

Extensions

Install apps that add your own tools to the admin, beside the content they operate on.

Search and vectors

Full-text search, and embeddings generated for your records so you can retrieve by meaning rather than by keyword.

Geo

Store coordinates on any model and query by proximity: what is near this point, ordered by distance.

See it against your own models

Create a project, define a model, and read it back over the API.