Feature Requests

With the growing number of available Building Blocks in the meshStack Marketplace, it becomes increasingly difficult for users to browse, discover, and understand which Building Blocks are relevant for their use case. As a Marketplace user, I want a more structured and user-friendly overview of available Building Blocks, so that I can quickly identify relevant Building Blocks, understand logical groupings, and discover related or dependent offerings more easily. To improve usability, the Marketplace should allow Building Blocks to be grouped into custom categories or sections with configurable headings, similar to the existing “Featured” section at the top of the Building Block list. This would allow Marketplace administrators to group Building Blocks in a way that reflects their internal service portfolio, dependencies, or user journeys. Marketplace administrators should be able to: Create custom categories for Building Blocks Define a custom heading for each category Assign one or multiple Building Blocks to a category Control the display order of categories Optionally group dependent or related Building Blocks together Optionally control the display order of Building Blocks within each category

Currently requests to the bulk endpoints for building blocks (e.g. bulk-upgrade) run into timeout issues, because all selected building blocks are processed sequentially before generating the response. This easily leads to timeouts for those requests when bulk-processing multiple hundreds or even thousands of building blocks. It would be helpful to have an endpoint, which does not wait for calculating the response with a state of each of the building blocks, but rather only accepts the request and responds back immediately. The bulk operation (i.e. upgrade) on the building blocks can then be further be processed asynchronously in the backend.

Problem / Use Case When planning multi-year budgets, teams need to create payment methods in advance, one per year. Without a start date, there is no way to prevent a payment method from being used before its designated period begins, making it impossible to enforce correct budget allocation across time. Proposed Solution Add an optional active start date to payment methods. A payment method with a future start date cannot be assigned to or used by any project until that date is reached. This allows operators and workspace owners to pre-create a full set of time-bounded payment methods and rely on meshStack to enforce the correct one for each period.

As a platform team we'd like to monitor the health of deployed building blocks, especially whether there is any unwanted drift. Drift can occur due to side administration, immature terraform practices (e.g. missing lifecycle ignore_changes), or an unclear shared responsibility This ticket is to collect community feedback on common challenges you have with drift detection like choosing an automatic or manual reconciliation strategy for drift what kind of reporting on drift you'd like to see Related: https://meshcloud.canny.io/feature-requests/p/dry-run-on-terraform-building-blocks

As a Platform Team I am faced with certain limitation from the target platforms. In certain setups it is required to re-trigger a building block run to successfully provision the building block.

When you change e.g. the role mapping of a platform you might want to trigger the replication of all tenants of the affected platform. At the moment it's not possible to do that (apart from manually going through all the tenants). It would be helpful to have a button for that.

As a platform administrator, I want to manage meshPolicies as code. We need the ability to perform full CRUD (Create, Read, Update, Delete) operations on meshPolicies via the meshObject API. Value: Automation: We could fully automate our meshStack governance setup using tools like Terraform. Consistency: We could ensure our policies are applied consistently across a staging and production meshStack instance without manual steps in the UI.

As a Platform Team of one department (Platform on Platform), I want all cloud accounts belonging to the same department to be able to have a mandatory building block configured into the landing zone, depending on a tag, so that department-specific compliance/governance requirements are automatically and consistently enforced across all relevant accounts without manual intervention. We do not want to create a specific Landing Zone for this, since the complexity with additional Landing Zones would in our opinion increase the complexity. The actual proposal would be a policy condition in the Landing Zone if the building block is mandatory or not.

In order to prevent an accidental deletion e.g. of a Platform Instance (which also removes all tenants from meshStack for this platform) via the panel or external API. I want to have some sort of flag which can be set via the panel or meshObject API which then prevents any deletion operation. Only if this flag is manually updated before, the deletion is possible again.

Problem / Use Case meshPanel uses tabs in many places to switch between related views (e.g. in the Platform Builder under Building Blocks). The left sidebar is underutilized in these areas and gives no indication of what sub-views are available, requiring an extra click to discover and switch between them. Proposed Solution Expose tabs as dedicated sub-items in the sidebar wherever tabs are used today. This allows users to navigate directly to any sub-view in one click and get a clearer overview of available views at a glance. For example, in the Platform Builder the "Building Block Definitions" and "Building Blocks" tabs would appear as sub-items under "Building Blocks" in the sidebar.