Security and isolation
How Groundfloor keeps workspaces, secrets, files and credentials apart, and what is your responsibility.
This page describes how Groundfloor separates one workspace from another, and how it handles the credentials it creates for you. It covers only what the platform does today; it isn't a compliance statement. For anything not listed here, such as certifications, regions or recovery commitments, ask the Groundfloor team.
Who can do what
Every request to Groundfloor is checked against the caller's role in the organization and the workspace, whether it comes from the Client Portal, the gf CLI or the API. A role in one workspace gives no access to another workspace.
- Organization Owners and Admins have Admin access in every workspace of the organization. Organization Writers, Members and Partners can view them. A Billing admin has no workspace access. See Team and roles.
- Code gets only what you give it: an M2M client acts like a Writer in one workspace, and a workload identity only reaches the collections you grant it.
- People who sign in to your own apps are separate from your team and have no team role. See App authentication and Site access.
How workspaces are kept apart
| What | How it's separated |
|---|---|
| Data | Each workspace is registered as its own tenant in the data service. Collections are managed per workspace; see Data |
| Secrets | Secrets are kept in a dedicated secrets store, in a separate space for each workspace, with each environment kept apart inside it |
| Files | Every file is stored under a path for its workspace. Groundfloor chooses the path; a client can't pick another workspace's. Downloads use links that expire after one hour |
| Coderunners | Each environment runs in its own namespace on the cluster. Groundfloor sets the namespace; a deploy request can't choose it |
| LLM Gateway | Coming soon. Planned: each workspace has its own gateway key, and usage is recorded per workspace |
A frozen workspace refuses changes such as edits, deploys and new members; it can still be read and exported. A workspace scheduled for deletion is frozen until an owner restores it. See Delete a workspace.
How credentials are handled
| Credential | Handling |
|---|---|
| Secrets | Values are hidden in lists and returned only when someone reveals one or reads it with an M2M client that has Read secrets. Each reveal is recorded in the activity log |
| M2M client secrets | Shown once when you create or rotate them. Groundfloor stores a hash to check them, not the secret itself, and exchanges them for short-lived tokens |
| Workload identity refresh secrets | Shown once and stored as a hash. They're exchanged for short-lived tokens |
| LLM Gateway keys | Coming soon. Planned: shown once, and a leaked key can be revoked at once; see LLM Gateway |
| Deploy settings | Variables with secret-looking names are rejected, so credentials don't end up in a deployment's configuration. See Configuration and secrets |
Short-lived tokens limit the damage of a leak. M2M and workload identity tokens last about five minutes by default.
What you're responsible for
- Give people the lowest role that lets them work. Prefer Member or Partner at the organization level, and add roles in the workspaces they need.
- Keep secrets in Secrets and read them at runtime, never in code, a ZIP or a
.envfile. - Give each Coderunner the narrowest credential it needs, and rotate one you think has leaked.
- Review the activity log. It keeps events for 30 days by default, so export what you need to keep longer.