/foːɾʲ/Irish, verbto help

The backend your agents build on.

Structured content and application data, managed together. Define your models; Fóir provides the API, editing tools, customer sign-in and tenant isolation.

Start buildingRead the docs

  1. The build

    Your backend starts as one config file.

    Write it yourself or ask a coding agent to. It names your models, their fields and how customers sign in.

    Fóir generates the API from it.

    Models, fields, lookups and customer sign-in are lines of config. One push turns them into a GraphQL API.

  2. Console

    Your team edits together, in a console built from your models.

    Every model gets an editor with typed fields, versions and a preview. Several people can work in the same record at once and see each other's cursors.

  3. Ask Fóir

    Ask Fóir a question about your data.

    The assistant in the console counts across your records, compares the steps and tells you what it found, with the numbers it used.

    Then ask it to do the work.

    It searches, writes and changes records through the same tools as you, and can do nothing your own role cannot. What it writes waits as a draft.

  4. Sign-in and roles

    Sign-in is built in.

    One hosted login for your team and your users: passkeys, two-step verification, and sign in with Google, Apple, Shopify or any OIDC provider.

    One set of users, in pools, with roles.

    A pool holds the people who can sign in to a project or to one organisation. A membership gives a user a role, and every role is built from the same list of permissions.

  5. Records

    The app reads with a publishable key.

    It runs on your own hosting and asks the API for the products anyone may see.

    Customers sign in, and a record can belong to one.

    Sign-in is hosted by Fóir. A model can make each record private to the customer who owns it.

    A write is safe to send twice.

    A weak connection makes the app send the order again. It carries the same idempotency key, so Fóir answers with the first result and changes nothing.

    Nobody else can read it.

    A second customer sends the same query and gets nothing. The rule is enforced in the database, so a check you forgot cannot leak a row.

  6. Publishing

    Content is edited from anywhere.

    An editor adds an image from a phone. It is saved as a draft, so the app still shows the published page.

    Publish, and the app has it.

    Content resolves on every request, so the next read returns the new version. Nothing is rebuilt or redeployed.

  7. Personalisation

    Fóir decides which version each visitor gets.

    A website, an app and an agent send the same read. A visitor that no rule matches gets the default.

    It works out who is asking.

    Location comes from the request and segments from the customer's profile, on the server. This one has spent over £1,000, so the VIP entry is served.

    Rules combine, and priority settles it.

    This visitor is in Paris and has bought running shoes before. Three entries match, and the first of them is the one served.

    A variant can change one field and leave the rest.

    It can replace a whole record, or override a single field or one paragraph. Editors write each version in the same editor and preview it as the audience it is for.

    A visitor cannot claim to be someone else.

    Location and segments are never taken from the caller. Editing the request changes nothing, and the default comes back.

  8. Rollouts

    Schedule a campaign and ship it as one.

    A rollout publishes a set of records together at the time you choose. Pause it, retry what failed, or roll all of it back.

  9. Keys

    Each key sees only the API it was granted.

    A mutation a key cannot run is missing from the schema it is given, so there is nothing for a leaked key to discover.

  10. Organisations

    Turn the app you built into a SaaS.

    A second customer wants what you built for the first. Add them as an organisation: the same models and the same code, with their own data, their own members and their own sign-in.

    No customer can read another's data.

    The credential sets the boundary before a query reaches a row, and the rule runs as row-level security in the database. A check you forgot cannot leak.

  11. Paywall

    Add a paywall to your app.

    Give an operation a quota per user or per organisation. When someone reaches it they can pay, through Stripe on the web or an app store on a phone, and their subscription raises the limit. The money goes straight to your own account.

  12. Operations

    Your logic runs in code you own.

    Describe what you need and Fóir drafts the contract, then hands your coding agent a prompt. The agent writes it and deploys it to your hosting. Fóir never holds your code.

    Every call arrives signed and scoped.

    Fóir works out who is calling and what the operation may touch, and sends that with the call. Its typed client turns anything outside the grants into a compile error. Each run is recorded, and a retry carries the same idempotency key so nothing happens twice.

  13. Secrets

    Secrets stay in the vault.

    Your code holds a reference and never the key. Fóir fills it in when it calls your function, only for the project the call belongs to, and logs every read.

    When an agent needs a key, it asks a person.

    The agent files a task in Work and waits. Someone adds the key from their phone, it goes straight into the vault, and the agent carries on with a reference it can use and a value it never sees.

  14. Hooks

    React when something happens.

    A hook runs an operation when a record is created, changed or published, or when another operation finishes. Delivery is at least once, and any delivery can be sent again.

  15. Notifications

    Tell customers the moment something changes.

    A notification goes out as a push and into the app's own inbox. Each customer chooses the categories they hear about, and Fóir honours the choice.

  16. Email

    Email that reads your data.

    A template fills in from your records at the moment it is sent. Send it about one record or to a whole segment, on a schedule, with consent applied and opens tracked.

  17. Media

    Upload an image once. Every screen gets its own.

    An image field returns WebP and AVIF in the sizes a screen asks for, with a blurhash to show while the picture loads.

  18. Search

    Search by meaning, inside what the caller may read.

    Records are embedded as they are written. A question finds the closest match, and a private record never turns up for someone else.

  19. Nearby

    Find what is nearby.

    A geopoint field makes records searchable by distance, so an app can ask what is within two kilometres of where someone stands.

  20. Work

    A note on your live site becomes a task.

    Anyone you allow can leave a note on a page. It is anchored to the record behind the page, so it arrives in Work with the right thing attached.

    People and agents decide what ships, in one place.

    Assign the task to a teammate or hand it to Fóir. The agent writes drafts freely, and nothing goes live until a person approves the publish.

  21. Agents

    Give an agent a standing job.

    A long-running agent watches what is happening and keeps your content current through MCP. Its key bounds what it may change, so it acts on its own inside those limits.

  22. Your app in the console

    Your app's own admin, inside the console.

    An app declares a page and the exact permissions it acts with. The console shows it in its navigation and hands it a token, so no password or cookie crosses over.

  23. Integrations

    Connect the systems you already run.

    An integration app maps another system's fields onto your models and keeps the records in step. A change there updates the same record here.

  24. Export

    Your data is yours to take.

    One command exports every record to a Postgres database you own.

  25. Start

    Create a project and define your models.

    The rest is already there.