Shared Workspaces
Organize your dbt projects into workspaces with flexible sharing controls. Keep personal experiments private, share team resources with specific people, or open a workspace to your entire organization.
Why Shared Workspaces
| Challenge | How Shared Workspaces solve it |
|---|---|
| Everyone sees everyone's projects, creating clutter and confusion | Private workspaces keep your sandbox hidden until you are ready to share |
| New team members struggle to find the right project to work on | Shared workspaces surface the team's canonical projects front and center |
| Onboarding a colleague means pointing them to a repo URL and hoping they figure out setup | Copy an existing project into a shared workspace - connection, branch, and environment carry over |
| There is no clean separation between "my experiments" and "the team's production models" | Workspace visibility (private, people, org) makes the boundary explicit |
| Creating a new project requires navigating to a separate settings page | "New Project from Git" and "Blank Project" options are available inline from any workspace |
Workspace Visibility
When you create or edit a workspace, choose who can see it:
| Scope | Who can access | Best for |
|---|---|---|
| Just me (private) | Only you | Personal sandboxes, experiments, learning |
| Specific people | Named members and/or roles you select | Team-scoped collaboration, domain squads |
| Entire org | All members of your organization | Shared team resources, onboarding templates |
The workspace list in the sidebar shows a lock icon for private workspaces and a people icon for shared ones, so visibility is clear at a glance.
Creating a Workspace
- Click + New Workspace in the sidebar
- Enter a name (e.g., "Revenue Models", "Data Quality")
- Choose visibility:
- Just me for a private sandbox
- Specific people to share with selected members or roles
- Entire org for full visibility
- If sharing with specific people, use the member picker to search and add individuals or select by role (Admin, Member, Viewer)
Creating Projects in a Workspace
Each workspace can contain multiple projects. Two creation paths are available:
From Git
Clone an existing repository from your connected Git provider. This is the standard flow for team projects backed by version control.
Blank Project
Start with an empty project - useful for prototyping, learning, or building something from scratch before connecting to a repository.
Both options are available directly from the workspace header, so you never need to navigate away.
Editing Workspace Sharing
After creating a workspace, you can change its sharing settings at any time:
- Right-click the workspace in the sidebar (or click the workspace menu)
- Select Edit sharing
- Adjust the visibility scope or add/remove specific people and roles
- Click Save sharing to apply
Removing access takes effect immediately. Existing members who lose access will no longer see the workspace or its projects in their sidebar.
Organization owners and admins can edit the sharing settings of any org-shared workspace, not just the ones they created, so team resources stay manageable as people come and go. The same applies to the projects inside those workspaces: owners and admins can update or remove an org-shared project even if a teammate originally created it, so nothing is orphaned when someone leaves.
Workspace Settings
Open a workspace's settings drawer from the sidebar to personalize and manage it in one place:
- Rename the workspace as its purpose evolves
- Icon and color: pick an icon and accent color so each workspace is instantly recognizable in the sidebar. Your choice is saved and shown everywhere the workspace appears
- Delete: remove a workspace you no longer need. Deletion is limited to the workspace owner, so a shared workspace cannot be removed out from under the people relying on it
Changes you make apply live: rename a workspace or change its appearance and the editor's workspace selector updates immediately, without a page refresh.
Git Credentials in Shared Workspaces
When a shared workspace is backed by a Git repository, dbdeux uses the organization's connected credential by default for branch, commit, push, and pull operations. This keeps collaboration working without every member needing their own token. If you prefer, you can opt in to using your personal token for your own actions instead.
Copy to Shared Workspace
Turn a private experiment into a shared team resource:
- Open the project selector in the sidebar
- Click Copy to Workspace
- Choose the target workspace (or create a new one)
- Optionally rename the copy and adjust sharing settings
- The copy includes the project configuration - connection, environment, and branch references carry over
This is especially useful for:
- Promoting a prototype to the team after validation
- Creating a starter template that new members can fork
- Moving projects between teams when ownership changes
How It Compares
| Capability | dbdeux Shared Workspaces | dbt Cloud | Other tools |
|---|---|---|---|
| Private sandboxes | Built-in - every user can create private workspaces | Projects are visible to all account members | Varies |
| Granular sharing | Per-workspace, by user, by role, or org-wide | Account-level access only | Usually all-or-nothing |
| Copy projects | One-click copy between workspaces with config intact | Not available | Manual re-setup |
| Blank projects | Create without a Git repo for prototyping | Requires a Git connection | Varies |
| Visual indicators | Lock/people icons show visibility in the sidebar | No visibility indicators | Varies |
| Inline creation | New project options embedded in every page header | Separate project creation flow | Varies |