Project isolation
A project is one product inside your workspace: a site, a store, an app. Its content, its users, its files, its API keys, its secrets and its sign-in domains are its own, and nothing is shared between two projects.
One key, one project
An API key is created inside a project and serves that project alone. The database will not store a public or secret key without one. When a request arrives, the project is read from the key's own record, never from a header, and a request that names a different project from its key is refused.
A custom API domain does not change this. The key still selects the project, and a key presented on a domain that belongs to a different project is rejected.
Team members scoped to a project
A role granted on one project counts only for that project's rows. A client with two sites gets a grant on each, and nothing they hold on one reaches the other. The same person can be an administrator of one project and have no access at all to the next.
The row rules
Every project-scoped table carries the project's id beside the workspace's, and its policy requires both to match the caller's session. For content, users and files the policy goes on to decide which rows the caller may see. For configuration, such as hooks, schedules and domains, the database guarantees containment, and the permission to change them is checked when the request arrives.
Staging and production
Fóir has no test mode and no second kind of key. A staging environment is a second project, with its own data and its own keys, and one config file can declare both and keep them in step.
Read the detail
The authentication guide explains each kind of key, what it can hold and how a request is tied to its project.