Config as code

What the file declares

foir.config.ts declares models, API keys, hooks and sign-in providers. It also covers operations, schedules, placements, segments, roles for your users, app installs, design tokens, locales, context dimensions, the variant catalogue, email copy and project settings. For an API key, the committed file holds the declaration: its name, type, scopes and the environment variable to use. The CLI provisions the key during a push and writes its value into your env file under that variable.

A push stages a draft

foir push starts with a dry run on the server, so a refusal arrives before anything is written. It then writes drafts, and production goes on serving the published copy until a release. New models, new operations and added optional fields are released with the push. Everything else waits for you to publish.

A push is a three-way merge of the file, the project's current state and your last push. Where the same field changed in the file and in the console, it stops and reports the conflict.

Staging and production from one config

A config can declare several named projects from one manifest, which is how staging and production are held identical. Only values declared as destinations may differ: endpoints, redirect URIs, origins, domains and sender addresses. Any other difference refuses the push and names the field and both values. A push also fails when the project holds a model, operation, hook, schedule or context dimension the config does not declare.

Removing a field

Taking a field out of the config does not drop its data at once. The field is kept as deprecated for 30 days, and the push writes a decision file asking what to do with the stored values: rename, convert or drop.