What are Bitbucket workspaces and how do they organize repositories?

Think of a workspace like a company's office building. The building (workspace) has floors (projects), and each floor has rooms (repositories). Everyone who enters the building needs a badge (workspace membership), and different floors may have different access levels.

A Bitbucket workspace is the highest level of organization in Bitbucket Cloud. Every repository lives inside a workspace, and every workspace has a unique slug (URL-friendly identifier) like 'acme-corp.' Workspaces replaced the older 'team' concept in 2019, providing a cleaner separation between organizational structure and individual accounts. Within a workspace, you create projects to group related repositories. For example, an e-commerce company might have projects like 'Backend Services,' 'Frontend Apps,' and 'Infrastructure,' each containing multiple repositories.

Internally, workspace-level settings cascade down to all repositories. You can configure default merge strategies, required reviewers, branch restrictions, and pipeline settings at the workspace level. Workspace administrators manage membership, granting users one of several roles: member (basic access), collaborator (external contributor), or admin (full control). Billing is also managed at the workspace level, so build minutes and LFS storage are shared across all repositories in the workspace.

In production, teams typically structure workspaces to match their organization. A large company might have one workspace per department or per product line. Within each workspace, projects group repositories by domain. This hierarchy becomes important when configuring permissions: you can grant a contractor access to a single project without exposing the entire workspace. Repository variables (secrets like API keys) can be set at the workspace level and inherited by all repositories, or overridden at the repository level for environment-specific values.

A common beginner mistake is creating multiple workspaces when projects within a single workspace would suffice. Each workspace has separate billing, separate user management, and separate settings. If a developer needs access to repositories across multiple workspaces, they need to be invited to each one individually. Over-fragmenting into many workspaces creates administrative overhead and makes cross-project visibility harder.