Fóir: the backend your agents build on
Fóir gives an application its whole backend from one config file: a GraphQL API, a console for your team, sign-in and roles, and the isolation between your customers' data. A coding agent can write the config and run the project through an MCP server, so the app it builds is ready for real customers.
This is the plain version of foir.io, for agents and for anyone who would rather read than watch.
Create a project: https://platform.foir.io/signup
Start with an agent
Connect the MCP server and read the contract from there. It lists the tools your role allows and searches the documentation.
foir mcp- MCP setup: https://docs.foir.dev/ai/mcp
- Documentation index for agents: https://docs.foir.dev/llms.txt
- Full documentation in one file: https://docs.foir.dev/llms-full.txt
Why teams choose it
- One config file gives you the backend you would otherwise assemble from separate services: database rules, sign-in, a content editor, media delivery, notifications and billing.
- Customer isolation is enforced in the database. Access rules compile to row-level security, so a check someone forgot cannot leak a row.
- The API is generated from your models, so there is no hand-written endpoint to get wrong.
- Content resolves on every request. A new language or audience is a field you set, and nothing is rebuilt.
- It is fully managed. There is nothing to host, patch or scale.
- You stay in control. Your code runs on your own hosting, payments go straight to your own Stripe account, and every record exports to a Postgres database you own.
- Agents work safely in it. Writes land as drafts, tokens carry only the permissions you approved, and a person signs off what goes live.
- Its authorisation engine, Demesne, is open source: https://foir.io/demesne
Who it is for
- A product sold to many customers. Each customer is an organisation with its own data, members and sign-in, on shared models.
- An app built with a coding agent that is ready for real sign-in, roles and data isolation.
- An agency running many client projects on one platform.
- A content-led site or app that wants drafts, scheduled campaigns and personalisation.
What you get
| Capability | What it does |
|---|---|
| Generated API | A GraphQL API built from your models. |
| Console | An editor for every model, with versions, live collaborative editing and preview as an audience. |
| Ask Fóir | An assistant in the console that answers questions about your data and makes changes as drafts, inside your role. |
| Sign-in | One hosted login: passkeys, two-step verification, and Google, Apple, Shopify or any OIDC provider. |
| Users and roles | One set of users in pools, with memberships and roles built from one list of permissions. |
| Organisations | Turn an app into a SaaS: each of your customers gets a boundary enforced as row-level security. |
| Keys | Publishable, server and admin keys. A key's schema contains only what it was granted. |
| Records | Records can be private to the user who owns them. Updates take an idempotency key, so a retry is safe. |
| Publishing | Writes land as drafts. Publishing needs no rebuild. Rollouts ship a campaign together and can be rolled back. |
| Personalisation | Variants chosen on the server from location, segments and your own dimensions. A variant can replace a record or one field. |
| Operations | Your own code, called through the API with a signed, scoped token. Every run is recorded. |
| Secrets | A vault. Functions and agents hold a reference and never the key. |
| Hooks | Record and operation events run operations, with deliveries you can send again. |
| Paywalls | A quota per user or organisation on any operation, raised by a subscription bought through Stripe or an app store. |
| Notifications and email | Push and inbox notifications with per-person preferences. Email templates filled from records at send time. |
| Media, search, location | Images served as WebP and AVIF at each screen's size. Search by meaning. Distance queries. |
| Work | Notes left on a live page become tasks. Agents draft and people approve. |
| Agents | A long-running agent keeps content current over MCP, on a key that bounds what it can change. |
| Apps | Your app's own admin pages inside the console, and integrations that keep another system's records in step. |
| Export | Every record exports to a Postgres database you own. |
Generated API
- What it does
- A GraphQL API built from your models.
Console
- What it does
- An editor for every model, with versions, live collaborative editing and preview as an audience.
Ask Fóir
- What it does
- An assistant in the console that answers questions about your data and makes changes as drafts, inside your role.
Sign-in
- What it does
- One hosted login: passkeys, two-step verification, and Google, Apple, Shopify or any OIDC provider.
Users and roles
- What it does
- One set of users in pools, with memberships and roles built from one list of permissions.
Organisations
- What it does
- Turn an app into a SaaS: each of your customers gets a boundary enforced as row-level security.
Keys
- What it does
- Publishable, server and admin keys. A key's schema contains only what it was granted.
Records
- What it does
- Records can be private to the user who owns them. Updates take an idempotency key, so a retry is safe.
Publishing
- What it does
- Writes land as drafts. Publishing needs no rebuild. Rollouts ship a campaign together and can be rolled back.
Personalisation
- What it does
- Variants chosen on the server from location, segments and your own dimensions. A variant can replace a record or one field.
Operations
- What it does
- Your own code, called through the API with a signed, scoped token. Every run is recorded.
Secrets
- What it does
- A vault. Functions and agents hold a reference and never the key.
Hooks
- What it does
- Record and operation events run operations, with deliveries you can send again.
Paywalls
- What it does
- A quota per user or organisation on any operation, raised by a subscription bought through Stripe or an app store.
Notifications and email
- What it does
- Push and inbox notifications with per-person preferences. Email templates filled from records at send time.
Media, search, location
- What it does
- Images served as WebP and AVIF at each screen's size. Search by meaning. Distance queries.
Work
- What it does
- Notes left on a live page become tasks. Agents draft and people approve.
Agents
- What it does
- A long-running agent keeps content current over MCP, on a key that bounds what it can change.
Apps
- What it does
- Your app's own admin pages inside the console, and integrations that keep another system's records in step.
Export
- What it does
- Every record exports to a Postgres database you own.
Each of these has a page in the documentation: https://docs.foir.dev
How a project starts
- A person creates an account at https://platform.foir.io/signup. This step needs a browser.
foir workspaces create --name acme --select- Write
foir.config.tswith your models, thenfoir push. - Run
foir mcpso an agent can work in the project as the signed-in person.
Good to know
- Location, sign-in state and segments are worked out on the server, so personalisation cannot be spoofed by editing a request.
- A response that contains a resolved variant is marked private, so a shared cache never serves one visitor's version to another.
- How Fóir compares with Supabase, Firebase, Sanity, Payload and others: https://foir.io/compare
- Pricing: https://foir.io/pricing