Staging and production
One config file can declare several projects by name, such as staging and production. Each push goes to one of them, so the same commit can be applied to staging first and to production afterwards.
Several projects in one config
Your config file names each project beside a single manifest that describes the models, operations, keys and the rest. A push acts on one project per invocation, chosen with --project.
Ordinary, separate projects
Fóir has no test mode and no second kind of key. Each named project has its own data, users and keys, and the platform holds no record that they are related. A pipeline holds one key per project. A key used against the wrong project is refused with both projects named, and each project's minted keys are written to its own env file.
Only destinations may differ
On every push the CLI resolves the manifest for each declared project and compares the results. The values allowed to differ are the ones you declare as destinations, such as endpoints, redirect URIs, allowed origins, custom domains and sender details. Any other difference refuses the push and names the field and both values. A model that one project has and another lacks is such a difference.
Drift is reported
A push to a named project fails when that project holds a model, operation, hook, schedule or context dimension the config does not declare, usually something added in the console, and it names what it found. The --prune flag deletes it. foir projects status prints the config hash each project last had pushed, and its drift, side by side.
Going live is a release
A push writes drafts. Apart from a few additive changes, such as a new model, production keeps serving the published copy until a release.
Read the detail
The configuration reference covers declaring named projects, which fields count as destinations, env files and drift.