Fóir as an alternative to Sanity
Both are hosted platforms that model content as structured data and serve it over an API. The difference is how much of the application around that content you still have to build.
Side by side
| Capability | Fóir | Sanity |
|---|---|---|
| Price | £0.99, £29 or £99 a month | $15 per seat a month, plus $999 per extra dataset |
| Content management | Standard | Standard |
| Query language | Typed GraphQL, generated | GROQ, or GraphQL you deploy |
| Tenant isolation | Enforced beneath your code | Separate datasets you wire up |
| Personalisation | Built in, resolved per request | Plugin, resolved in your app |
| Hosted auth | Sign-in, roles and tokens included | Editors only, not your users |
| Backend beyond content | Operations, hooks, schedules, secrets | Hosted functions, triggers and cron |
| Media | Library, transformations, access rules | Library and transformations |
| Agent access | Content and control plane | Content over MCP |
| Data ownership | Postgres export, access rules included | Export as documents |
| Pricing shape | No per-seat charge to invite an editor | Per seat, then usage |
Price
- Fóir
- £0.99, £29 or £99 a month
- Sanity
- $15 per seat a month, plus $999 per extra dataset
Content management
- Fóir
- Standard
- Sanity
- Standard
Query language
- Fóir
- Typed GraphQL, generated
- Sanity
- GROQ, or GraphQL you deploy
Tenant isolation
- Fóir
- Enforced beneath your code
- Sanity
- Separate datasets you wire up
Personalisation
- Fóir
- Built in, resolved per request
- Sanity
- Plugin, resolved in your app
Hosted auth
- Fóir
- Sign-in, roles and tokens included
- Sanity
- Editors only, not your users
Backend beyond content
- Fóir
- Operations, hooks, schedules, secrets
- Sanity
- Hosted functions, triggers and cron
Media
- Fóir
- Library, transformations, access rules
- Sanity
- Library and transformations
Agent access
- Fóir
- Content and control plane
- Sanity
- Content over MCP
Data ownership
- Fóir
- Postgres export, access rules included
- Sanity
- Export as documents
Pricing shape
- Fóir
- No per-seat charge to invite an editor
- Sanity
- Per seat, then usage
Sanity's behaviour is taken from its published documentation, current at August 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.
Sign in the people who use what you build
Sanity signs in the people who write the content. The people who use what you build are your problem, so most teams end up running an auth service beside the CMS and keeping two sets of identities roughly in step.
Fóir signs in both. Your customers get registration, password and one-time-code login, social and OIDC providers, roles and refresh tokens, on your own domain, and the content rules already know who they are.
One query language, generated for you
GROQ is expressive and it is also another language for everyone on the team to learn, with types you keep in step by hand.
Fóir generates a typed GraphQL schema from your models. Change a model, regenerate, and the compiler tells you what broke rather than a runtime response you did not expect.
Personalisation that resolves before it reaches you
Sanity has a personalisation plugin, and it leaves the resolving to your front end: fetch the variants, work out which applies, render it. Every consumer repeats that, and they can disagree.
In Fóir an audience is a model you own and the API returns the content already resolved for the request. A native app and a website get the same answer because neither of them decided it.
Isolation you do not wire up
Sanity separates work into datasets, and keeping them apart is routing and tokens you arrange yourself in every app that reads them.
In Fóir a project is the boundary, enforced beneath your code, so a read that forgets a check comes back empty rather than complete.
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.