Workspace
What it is
A workspace is a container for related work inside your organization. It is the level at which people get access and at which infrastructure is registered — so it is the natural boundary for "a team", "a client", or "a product line".
What it contains and scopes
- Projects and environments — its two main contents, side by side.
- Members — who can see and do what in this workspace, via workspace roles.
- Workspace tokens — the credentials controllers use to attach to its environments.
- Agent definitions and secrets scoped to the workspace, which every project in it inherits.
- Which Git connections may be used inside it.
Who creates it
You get one workspace named Default when you sign up, and it arrives stocked: a Scratchpad
project and three environments, one per role.
→ What signup creates If you were invited to an existing organization, you get whatever workspaces
your role gives you access to, and none is created for you.
Creating more workspaces is an organization-level ability: owner, admin and member roles can all create one. See Security and tenancy.
Lifecycle
Create, rename, delete. A workspace with contents is not something you delete casually — the projects, environments and history inside it go with it.
How it relates to projects and environments
A workspace is the parent of both. Projects and environments inside one workspace can be combined freely — any project can be launched into any environment in the same workspace. They cannot be combined across workspaces: that is what makes a workspace a real boundary rather than a folder.
The common mistake
Making a workspace per environment stage. "Dev workspace, staging workspace, prod workspace" is the wrong axis: it duplicates every project three times and means a project's history is split across three places. Environments are already the where-it-runs axis, and several of them live in one workspace happily. Split workspaces when the people or the code differ, not when the machine does.
→ Environment · Project