This guide walks you through the practical steps of managing your Workspaces. Here, you’ll learn how to create, edit, and delete Workspaces, as well as how to manage access by assigning teams and resources like Environments, Designs, and Views to them.
If you’re new to the concept of Workspaces, we recommend starting with the Workspaces Overview to understand what a Workspace is and how it relates to key components like Environments, Designs, and Teams.
The Workspaces page is where you can see all of the workspaces within the currently selected organization.
To suit different workflows, you can switch between two distinct layouts: a visual grid view and a detailed table view.
The grid view offers a card-based layout, perfect for quickly identifying workspaces at a glance. Each card displays essential information, and you can flip it to reveal management options like editing or deleting and get audit history.
The table view provides a dense, list-based format that is ideal for managing a large number of workspaces. This view allows for sorting and gives you more control over the specific details you see.
To customize the information displayed, click the View Columns icon and select the attributes you want to see, such as Owner ID or Created Date.
Creating a new workspace allows you to manage resources, and define team access.
To create a workspace:
You can modify a workspace’s name and description at any time after it has been created.
You can delete a single workspace or multiple workspaces at once.
To delete a single workspace:
To delete multiple workspaces (Grid View only):
When a Workspace is deleted:
Assigning teams is the way you grant users access to a workspace. Once a team is assigned, its members can access all of the Designs, Views, and Environments linked to that workspace.
You can open the team management Dialog from either the grid or table view.
Inside the assignment Dialog, you will see two lists: Available Teams on the left and Assigned Teams on the right.
When you link an Environment to a Workspace, you make all the connections (like those to Kubernetes clusters or databases) grouped within that Environment available. This means any team members with access to that Workspace can then deploy their applications or configurations to the resources.
The process of linking environments is almost the same as assigning teams.
Unlike Environments, every Design and View must belong to exactly one Workspace at all times.
When you create a new Design, it is automatically added to your current Workspace. Therefore, you don’t “link” them in the same way you link an Environment; instead, you move them from one Workspace to another.
Meshery keeps a detailed audit log for each workspace, allowing you to track all significant events. This is useful for maintaining security and troubleshooting issues.
The activity log captures a variety of events, including:
At the bottom of the log, you will also find timestamps for when the workspace was initially created and when it was last updated.
There isn’t a single “best” way to organize your workspaces, as structure depends heavily on team dynamics and project needs. Instead, we recommend a flexible, multi-layered approach to maximize workspace effectiveness. Below are common usage patterns:
1. The Project Hub
Dedicate a shared workspace to each project. It becomes a central hub where your team can co-develop designs, share reusable components, and align with specific environments (e.g., staging or production). This keeps all your environments, history, and resources in one place
2. Your Personal “My Drive”
Think of a private workspace as your personal Google “My Drive.” You can use it for anythingβfrom important, confidential designs to just playing around with new ideas in a “sandbox.” It’s more than just a place for quick tests; it’s also where you can build and polish your professional work before it’s ready to be shared.
3. Template Library
Create a separate, access-controlled Workspace to serve as your organization’s internal, private template library. This is for storing non-public, organization-specific, or sensitive patterns.
This practice complements the public Catalog, which is used for sharing generic, non-sensitive designs with the community. A dedicated Organization Catalog feature is also planned for the future.
4. The Team Space
You can also organize long-term workspaces around specific teams, such as a “Developer Hub” or “QA Workspace.” This simplifies resource management and makes it easy to monitor team-wide activity.
5. The Environment-Specific Space
For teams requiring strict separation between environments, this pattern is essential. You can create dedicated workspaces like a “Production Workspace,” which would exclusively contain designs approved for deployment and link only to production clusters. This approach builds a secure barrier between your development, staging, and production assets.
A key restriction is that a user, even with a Workspace Admin role, cannot manage a Design they do not own. This action requires Organization Admin or Organization Owner permissions.
Other members of a Workspace can view and edit your Design, but they cannot delete it. The permission to delete a Design is exclusive to its Owner.
Yes. A Workspace can simultaneously contain Designs that are private, public, and published.
Currently, it is not possible to receive direct notifications or see a collaborative audit trail of changes made by other users. While a Version History feature exists for Designs, it currently only tracks changes made by you, not changes from other collaborators.
No. A user with whom you share a private Design cannot re-share it with others.
Currently, there are no specific space or file count limitations for Workspaces. However, this may be subject to change in the future and could be tied to different subscription plans.
To make a Design available to everyone but in a read-only state, you should Publish it. A Published design can be viewed and cloned by any user, but the original cannot be edited by others.
To share a design exclusively with a select group:
This grants members of the assigned Team exclusive access and the permission to edit the design.
This functionality is not fully implemented yet. Users might occasionally observe that designs and views are preserved after Workspace deletion. ↩︎