Feature Requests

Problem / Use Case When a service broker is decommissioned or becomes permanently unavailable, it is not possible to purge the service instances it managed. meshStack may still attempt to contact the broker during deletion, leaving instances stuck and impossible to clean up. Proposed Solution Provide an administrative option to force-purge service instances regardless of broker availability - similar to cf purge-service-instance in Cloud Foundry. This would allow admins to remove orphaned instances from the marketplace without requiring broker connectivity.

Problem / Use Case When a building block requires a Terraform map variable (e.g. tags, simple key-value configuration), users currently have to provide it as raw JSON via the "Code" input type. This is error-prone and gives end users a poor experience. Proposed Solution Add a native map input type that renders a key-value editor in the UI, allowing users to add/remove entries without writing raw code. Supported value types: string , bool , and number . The input serializes to a Terraform-compatible map on execution. Nested objects are out of scope.

When working with parent/child Building Block relationships (e.g. a VNet parent with Subnet children), meshStack currently only surfaces the parent side of the relationship: The Public API exposes parentBuildingBlocks on a child BB, allowing child→parent navigation — but there is no reverse link : you cannot query which Building Blocks are children of a given parent. The meshPanel (UI) has the same gap: when viewing a parent Building Block instance, there is no list or indicator showing its child instances. What we are asking for: Panel/UI: When viewing a parent Building Block instance, show a "Child Building Blocks" section listing all dependent child instances (with links). This helps platform engineers and application teams quickly understand the full dependency tree — e.g. "which Subnets belong to this VNet?" Public API: Add child navigation support — either a childBuildingBlocks field on the Building Block resource, or a query/filter parameter on the List Building Blocks endpoint (e.g. ?parentBuildingBlockId=<id> ) to efficiently retrieve all children of a given parent without having to fetch all BBs and filter client-side. Why it matters: Complex automation use cases (e.g. Azure DevOps Pipelines, AWS Step Functions) need to enumerate all child BBs of a parent to collect outputs (e.g. CIDR blocks of all Subnet BBs under a VNet) for downstream operations like firewall rule updates. The current workaround — listing all Building Blocks in a tenant and filtering by parentBuildingBlocks — is inefficient and error-prone at scale. From a user experience standpoint, understanding which child BBs belong to a parent is also a day-to-day panel use case for operators managing complex landing zones. Related: "Create a dependent building block on the fly" (open, 9 votes) — related but focuses on ordering child BBs; not a duplicate.

Currently, chargeback only shows cost. We need to also display actual resource consumption (e.g. CPU/memory usage for containers) so platform operators can identify over-provisioned projects and right-size them to reduce costs.

Problem / Use Case As a platform operator, I want to control which types of email notifications meshStack sends to Application Teams on a per-event basis. Currently, meshStack only offers a global on/off switch for all emails — there is no way to disable specific event emails (e.g. "Workspace created") while keeping others enabled (e.g. "Workspace permission changed"). This creates noise for users: a "workspace created" email may be redundant if the workspace creation is handled through an automated or externally orchestrated process, while permission change emails remain valuable for security and access awareness. Value / Impact Platform teams can tailor the notification experience to their users needs, reduce email noise, and improve signal-to-noise ratio for important events like permission changes. Proposed Behaviour Operators should be able to toggle individual email notification types on/off in the meshStack operator config, for example: Workspace created Workspace permissions created/updated/removed Project permissions created/updated/removed Budget exceeded Building Block executed

Problem / Use Case The Workspace User Group API only supports read operations. There are no REST endpoints to create, update, or delete groups, forcing customers to use the declarative meshObject API for basic group lifecycle management. Proposed Solution Add POST , PUT / PATCH , and DELETE endpoints to the Workspace User Group API so groups can be fully managed via the meshStack REST API.

Why? We use the TAGS from input values for building blocks. At the moment we can only say that the TAG is mandatory or immutable by the end user. Both together is not possible. Yes, there is the option "Immutable", but in some cases it is important that at least the administrators could adjust the value. Current workaround is to adjust the config of the TAG, change it and then bring the TAG config back to the original state -> but this is time-consuming and cumbersome...

Problem / Use Case Unmanaged tenants are currently discovered exclusively through the metering service principal. Customers naturally expect tenant discovery to be part of replication — the component responsible for managing cloud tenants. This mismatch leads to empty unmanaged tenant lists even when the replicator is fully functional, causing confusion and unnecessary support cases. Proposed Solution Use the replicator service principal to discover unmanaged tenants. Metering can remain a secondary enrichment source (e.g. for cost data), but should not gate tenant visibility.

Feature Request meshTenant deletion for custom platforms should have similar functionality to normal meshTenant deletion — specifically, requiring admin approval prior to deletion . Motivation This is especially important when a custom platform has landing zones with mandatory building blocks , as these building blocks may require admin attention before the tenant can be safely removed. Without this approval gate, tenants on custom platforms could be deleted without proper review, potentially leaving orphaned resources or misconfigured building blocks unnoticed.

As enterprises manage increasingly hybrid infrastructure — with VMware vSphere estates sitting alongside public cloud — there's a growing need to bring on-prem VMware resources under the same governance, self-service, and chargeback umbrella as cloud platforms in meshStack. We're exploring what a VMware integration could look like for meshStack. This could include: Self-service VM provisioning via meshStack workspaces, backed by vSphere resource pools and folders RBAC integration — mapping meshStack workspace roles to vCenter permissions Quota & cost management — tracking vSphere resource consumption alongside cloud spend Landing Zone support — Terraform-based vSphere landing zones as Building Blocks Tenant isolation — vSphere folders/resource pools as the tenant boundary We'd love to hear from you: Is VMware vSphere part of your infrastructure today? What would a meshStack integration need to cover to be useful for your team? Vote and comment to help us prioritize!