Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Proposal: Shared Workspaces#18992

stirby started this conversation inRFCs
Jul 22, 2025· 3 comments· 3 replies
Discussion options

We're excited to share our plans for workspace sharing and collaboration. This RFC outlines our approach to enabling multiple users to work together in shared development environments.

🤔 Problem

Many teams using Coder need shared development infrastructure but we currently lack native support for:

  • Group-owned infrastructure: Multiple developers connecting to shared workspaces for QA, on-call rotations, and collaborative development
  • Peer-to-peer sharing: Real-time workspace invitations for debugging, pair programming, and app reviews
  • Shared staging environments: Teams wanting collaborative access to staging and testing environments

Today, these workflows require workarounds likeshared ports, sharedcoder_apps or external tools. None of these provide a true collaborative experience in Coder workspaces.

✏ Proposal

We're designing a comprehensive workspace sharing system built on the ACL patterns from our existingtemplate permissions:

share-workspace

Core Functionality

  • Workspace ACL: Grant individual users or entire groups access to your workspaces
  • In-dashboard share button: Workspaces can be easily shared using the in-dashboard "share" option
  • Role-based permissions:
    • Use: Connect via SSH/apps, start/stop workspace, view logs and stats
    • Admin: All "use" permissions plus rename, update, and invite others (cannot delete)
    • Service account support: Administrators can use service accounts for group-owned workspaces
    • Automatic cleanup: Users lose Tailnet access when removed from ACL (workspace restart recommended)

Security & Governance

  • Kill swtich: Administrators can disable sharing organization-wide or deployment-wide
  • Audit logging: Track all workspace sharing grants and access
  • Hierarchical ACL: Template ACLs will always supersede workspace ACLs
  • Permission inheritance: New workspace.share permission required at organization member level
    • Can be revoked from default org members

User Experience

  • CLI integration: Simple commands like coder sharing share dev --user alice --group contractors
  • Dashboard visibility: See shared workspaces in workspace listings with filtering (shared:true)
  • Editor support: Shared workspaces appear in VSCode extension, JetBrains, and Coder Connect
  • Terraform integration: Control sharing policies via coderd_organization.workspace_sharing

Note on licensing

Shared workspaces will beavailable in OSS deployments. The RBAC controls to limit sharing (including custom roles) will be gated to premium deployments

🖼 Sneak Peek

User interface

workspace_acl> A mockup of the workspace "permissions" page to view guest users.

share-button

The new "sharing" action in the workspace page.

CLI

# Share workspace with user(s)coder sharing share dev --user alice# Share workspace with group(s)$ coder sharing share eve/dev --group=contractor,intern

🤝 Get Involved

This feature will fundamentally change how teams collaborate in Coder. We want to ensure we're building the right solution for your workflows.

Share your thoughts:

Which sharing scenarios are most critical for your team?
What security controls are non-negotiable in your environment?
How do you envision managing group-owned infrastructure?
Should sharing permissions expire automatically or persist until manually revoked?
How do you want shared infrastructure to be visualized?

You must be logged in to vote

Replies: 3 comments 3 replies

Comment options

Awesome. We would like to deploy some kubevirt vms and have multiple people access over the ui to the autodeployed vms in kubernetes.

You must be logged in to vote
1 reply
@stirby
Comment options

stirbyJul 29, 2025
Maintainer Author

Excellent to hear!

Comment options

And please make it if a user deletes a workspace that it is not automatically deleted but moves like to a trash folder where a admin can recover it (and only after 30 days or so is really deleted)

You must be logged in to vote
2 replies
@MrPeacockNLB
Comment options

the whole handling is unclear to me. What if a workspace owner deletes a workspace? This currently implies that the delete function removes all terraform deployed resources. How about unsaved data from other users? How can one ensure that no work get lost? What if the owner wants to delete the workspace? Does this mean all users must get notified and select "sure you can delete this workspace"? What if a user working on this workspace has left the company? Enforce deletion?

What about auto stop functionality?

Currently under Linux our user do have sudo power and can do what ever they want to do. But if we have a shared workspace, what about the secrets like tokens which are (or can be injected by accident) injected?

Do not get me wrong, I like the idea but I've some concerns regarding this feature.

Maybe I'm wrong...

@suse-coder
Comment options

Maybe that delete is not deleting it for some time?

Comment options

And how would this play together with external workspaces?

You must be logged in to vote
0 replies
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
RFCs
Labels
None yet
3 participants
@stirby@MrPeacockNLB@suse-coder

[8]ページ先頭

©2009-2025 Movatter.jp