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 | Git, managed, and blank project options are available inline from the project selector |
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 & roles | Named members and/or roles you select | Team-scoped collaboration, domain squads |
| Whole organization | 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.
Shared Run and Test History
If you can see a shared workspace, you can see all of its run and test history, not just the runs you personally triggered. The Runs and Tests pages show every teammate's activity in that workspace, so a failing build is visible to whoever is available to fix it rather than only to the person who started it. Private workspaces stay private: only your own runs appear there.
Creating a Workspace
You always have at least one. On your first sign-in, a private workspace called My Workspace is created for you, so a new user is never stuck looking at an empty workspace list with project creation unavailable.
To add another:
- Open the workspace selector in the sidebar and choose Private workspace or Shared workspace
- Enter a name (for example "Revenue Models" or "Data Quality") and an optional description
- Choose who can see it:
- Just me for a private sandbox
- Whole organization for full visibility
- Specific people & roles to share with selected members, roles, or both
- If sharing with specific people, use the picker to search and add individuals or select by role (Admin, Member, Viewer)
Starting from Private workspace does not lock you in. You can widen the sharing scope later without recreating anything.
Creating Projects in a Workspace
Each workspace can contain multiple projects. Three 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. Public repositories clone without a credential; private ones use one of your saved Git credentials.
Managed
dbdeux hosts and stores the project files for you, so a team without a Git provider (or without permission to create a repository yet) is not blocked from starting. You can download the whole project as a zip whenever you want, so choosing managed never means losing access to your own work.
A managed project can be initialized with a starter dbt project: dbt_project.yml, a README, a .gitignore, two example models with schema tests, and the seeds, macros, tests, snapshots, and analyses folders. Pick the dbt version those generated files should target, or leave it on Latest so the project always runs on the newest supported engine. Uncheck the option to start completely empty and initialize later from the file explorer.
Blank Project
Start with an empty project - useful for prototyping, learning, or building something from scratch before connecting to a repository.
All three options are available from the project selector in the top bar, 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, with an impact-aware confirmation that shows what will be affected before you commit. Deletion is limited to the workspace owner, and for an org-shared workspace, organization owners and admins can delete it too, so team resources stay manageable while a shared workspace is never removed out from under the people relying on it by someone without the right to do so
Changes you make apply live: rename a workspace or change its appearance and the editor's workspace selector updates immediately, without a page refresh.
What Deletion Checks First
Before a workspace can be deleted, the settings drawer lists everything currently living in it: its projects and its warehouse connections. Nothing is guessed at, so you make the decision with the full picture in front of you.
If the workspace still holds warehouse connections, deletion is blocked and the drawer names the connections and points you to the Databases page. Connections carry credentials and are referenced by environments and jobs, so leaving them behind with no workspace would be a quiet way to break scheduled builds. Move or delete them deliberately, then the workspace can go.
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 |