A project per client
Give each client a project of their own inside your workspace. You administer all of them from one place, and a client you invite runs their project and reaches nothing else.
What belongs to a project
Content, API keys, users, the apps registered for hosted sign-in with their login domains, and the branding and sending address for emails all belong to one project. Every public and secret key is created inside a project and serves that project alone, so a deploy that reads two projects holds two keys. A user account belongs to one project, and the same person can be a user of two clients' projects independently. Project isolation describes how the boundary is enforced.
One workspace administers them
Members, roles, invitations, projects and billing sit at the workspace. From the CLI, foir projects list shows every project you can reach and foir projects create adds one.
A plan's allowance is the total across the workspace's projects. A project cap fences one project's share of it (records, media storage, seats, active users, sign-in emails and AI credits), so one client cannot use up the whole allowance. How many projects you can hold depends on your plan.
Granting a client their project
You hold the Workspace administrator role. Invite the client and grant them Project administrator on their project. They run it completely: its content, schema, webhooks, keys and users. They reach nothing outside it, neither your invoice nor another client's project. A client with several sites gets one grant per project.
When clients share a schema
Nothing is shared between two projects. For clients that should share one schema, the alternative is organisations inside a single project. The two shapes combine: a project per client, each split into organisations of its own.
Read the detail
The team members guide walks through the agency set-up, from the two roles to a grant scoped to one project.