Feature Requests

Problem / Use Case When running Terraform automation inside a meshStack workspace (e.g., via a private meshStack runner), there is currently no way for a Terraform configuration to introspect its own workspace context. If I want to reference my own workspace identifier — for example, to configure a resource scoped to my workspace — I have to pass it in as an explicit input variable. This is error-prone and creates unnecessary boilerplate. Other Terraform providers solve this cleanly. For example, the Azure provider offers: data "azurerm_client_config" "current" {} See: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/data-sources/client_config A similar pattern for the meshStack Terraform provider would be: data "meshstack_workspace" "current" {} This would allow a Terraform configuration to discover the workspace it is executing in, without requiring the caller to explicitly pass the workspace identifier as an input. Value / Impact Eliminates boilerplate: Platform teams no longer need to wire workspace identifiers through input variables when the runner already executes in that workspace context. Reduces configuration errors: Passing the wrong workspace identifier as an input is a common mistake; self-identification removes this risk entirely. Enables cleaner module design: Terraform modules that operate on the current workspace can be written without requiring consumers to supply context that the platform already knows. Consistent developer experience: Follows an established pattern familiar to engineers who work with cloud provider Terraform providers (AWS, Azure, GCP all offer similar self-identification data sources). Next Steps and Feedback If you would find this useful, please vote and share your use case in the comments: Which workspace attributes are most important to you in the data source? (e.g., workspace identifier, display name, tags) Do you need additional context beyond the workspace, such as the meshProject or platform tenant the runner is executing in? Feel free to reach out to our customer success team or contact us at support@meshcloud.io if you have questions.

currently there is the option to have User Permissions as input to a building block: Provides the user permissions from the parent meshObject (project or workspace) as a list of objects. The limitation that it can only be the parent object causes problems for us currently. We have a tenant level building block, but we need to trigger this building block, when Workspace owners have changed. We only have the option of getting the project level user permissions. Could you make this user permissions input more flexible, so that we are not limited to the parent meshObject? Regards, Fabian

When creating Building Block Definitions (BBDs) in the Admin Area, it is currently possible to end up in an inconsistent state where a BBD appears published and approved, while its initial version is still in draft. In this situation, the BBD looks correctly configured in the UI but does not appear in workspace marketplaces. This behavior is confusing and makes it difficult to understand why a seemingly published BBD is not consumable. The system should prevent or clearly surface such inconsistent states and ensure that the publication status of a BBD and its versions is transparent and aligned.

As a Cloud Foundation Team admin, I want to control which workspaces are allowed to use the Platform Builder (to create Building Block Definitions, platforms, etc.), so that I can govern who is contributing to the internal platform service ecosystem — not just who can publish. Current situation Today, workspaces can self-enable the Platform Builder via a toggle in their workspace settings. While admins can control publishing approval (i.e., whether a built service becomes available to others), they cannot prevent a workspace from accessing the Platform Builder in the first place. This means any workspace can start building and operating their own BBDs and platform instances without admin awareness or approval. Requested capability Admins should be able to decide — from the Admin Area — which workspaces are allowed to use the Platform Builder. This should be controllable per workspace.

Allow end users to change the landing zone of the tenants they own. A meshStack admin should be able to configure which landing zones and/or platforms are eligible for self-service tenant migration.

Problem / Use Case When I publish a building block using the Platform Builder and it requires operator input, the notification currently appears only in the Admin Panel. As a platform engineer managing building blocks through the Platform Builder, I need to see actions that require my attention directly in my workspace where the building block was created. Currently, there is no "Actions Needed" dashboard component in the Platform Builder area. This creates a poor user experience because: Platform engineers must switch to the Admin Panel to see notifications about their own building blocks. As more customers adopt the Platform Builder and drop their admin roles (following meshStack best practices), they lose visibility into actions required for resources they own. The Platform Builder experience feels incomplete compared to the admin experience, even though both roles need similar visibility into pending actions. Platform teams should have the same level of visibility and actionability within their workspace as admins have globally. Value / Impact Adding an "Actions Needed" dashboard to the Platform Builder provides: Consistent user experience : Platform engineers get the same quality dashboard as admins, encouraging adoption of the Platform Builder as the primary interface. Better visibility : Platform teams can immediately see and act on notifications for resources they own, without requiring admin permissions. Reduced context switching : Platform engineers stay within their workspace context instead of switching to the Admin Panel. Improved building block operations : Faster response to operator input requirements and other building block notifications. A workspace-scoped Actions Needed dashboard would show notifications filtered to resources owned by that workspace, such as building blocks requiring operator input, failed building block runs, or other platform resources needing attention. Context / Links Related post (narrower scope): https://feedback.meshcloud.io/admin/board/feature-requests/p/platform-builder-overview-should-show-bb-operator-inputs-required-ux

I would like to discontinue managing a tenant through meshStack. The tenant should remain intact in the cloud, but all artifacts created or managed by meshStack should be removed, specifically: Tags Role assignments Groups and roles

I want to see who opted out of a feature preview so I can reach out to them and ask why they decided to opt out. This helps me learn why users decided to do so.

At the moment when setting opt-in as default for a Feature Preview still shows the "Try the new Experience" / "Go back to the old Experience" buttons. When I, as an admin decide that the new experience should be the default I actually don't want any switching to be possible at all. I want the new experience to be hard enforced and to be the only possibility.

Use Case: As a Platform Operator, I want to group related Building Blocks (BBs) together using tags (e.g., from the tagging catalog) so that Application Teams can easily discover "sets" of services that belong to a specific platform offering. Example: I create an IDP with services K8s namespace, git repo, container registry and database -> they are designed to work together (but not necessarily dependent). I would tag them with "K8s IDP" and if I could switch on that filter in the marketplace (best via URL to also share it), I could point users to my specific platform BBs. It would be a first step towards the "Platform view" suggested elsewhere. Value Created: Improved Discoverability: Prevents specialized BBs from getting "lost" in a crowded marketplace. Enhanced Sales/Demo UX: Allows meshies and customers to demo a cohesive platform experience from the Developer Portal perspective rather than just the Platform Builder. Logical Organization: Aligns the marketplace view with the organization's existing tagging and governance structures.