Workspace isolation
A workspace is your account with Fóir. It holds your projects, the people on your team, and the plan you pay for. Nothing in it is readable from another workspace.
How workspaces are kept apart
Workspaces share a database, and the separation is a policy on every row. Each governed row carries the id of the workspace it belongs to. The row-level security policy on its table compares that id with the workspace in the caller's session, and does so before any other rule is considered. A query made for one workspace returns none of another's rows.
Our tests include the direct case: two workspaces are created, and the second one's session is required to read nothing from the first.
Who gets a session in a workspace
A member of your team is given a session in a workspace only while they hold a live role in it. Roles are granted across the whole workspace or on a single project, and a workspace always keeps at least one administrator: revoking the last one is refused.
Our own staff come in by a separate route, support access by approval.
What belongs to the workspace alone
Some authority exists only at this level. Billing, creating and deleting projects, inviting people, the audit trail that spans projects and the export to Postgres all need a workspace role. Someone who administers one project and runs a query against billing gets no rows back, through the console, the API or the CLI.
Plan allowances are pooled across the workspace, so your projects draw on one set of limits.
Read the detail
The team members guide covers roles, grants, invitations and how support access is approved.