Feature Requests

Problem / Use Case When a tenant fails replication, end users see no actionable explanation in the Project UI — no error reason, no next step. Operators get email alerts (already shipped), but users are left with a silent failed state and must contact their cloud foundation team. Value / Impact Reduces support load on cloud foundation teams Aligns with building block failure UX, which already surfaces system messages to end users Replaces a confusing silent failure with a clear, self-serviceable message Context / Links Context / Links Closed predecessor: Project creation: Make replication more visible Related open: Replication History , E-Mail notification when replication stuck in progress

The AWS European Sovereign Cloud (ESC) is a separate AWS partition for European organizations with strict data residency and sovereignty requirements (GDPR, NIS2, public sector regulations). Like the AWS China partition, ESC uses different API endpoints, ARN formats, region identifiers (e.g. eu-isoe-west-1 in Germany), and has different service availability. meshStack currently does not support the AWS ESC partition explicitly and needs to add support for this, similar to the existing AWS China support. Value / Impact Adding AWS ESC support would enable platform engineers to: Manage AWS ESC tenants centrally from meshStack alongside standard cloud platforms, including the global AWS partition Apply consistent governance, access control, and chargeback across sovereign and standard AWS accounts Automate tenant provisioning and landing zone enforcement for AWS ESC accounts Especially valuable for German public sector organizations and regulated enterprises in finance, healthcare, and critical infrastructure. Context / Links AWS European Sovereign Cloud - Official AWS ESC page Implementation approach is similar to AWS China partition support already in meshStack. If you are evaluating AWS ESC and want to share feedback, please reach out to support@meshcloud.io or your Customer Success contact.

As the purchaser of a building block, I would like to change the display name of the building block retrospectively so that it is immediately clear what the building block belongs to, especially in the case of multiple provisions or if the building block parameters change during lifetime. It should be noted that a default name is generated when the first building block is provisioned.

## Problem / Use Case When a platform team releases a new version of a building block definition that grants the ephemeral API key more permissions than the previous version, there is currently no guardrail: the new version can be released and becomes active immediately without any review by the central admin team. This creates a governance and security risk. A building block with elevated permissions can take actions on behalf of the workspace — such as provisioning additional resources or modifying meshStack objects — and central administrators have no visibility or control over when these permissions are expanded. For example: a building block that previously only read workspace metadata is upgraded to a new version that can also create new building blocks or modify IAM configurations. Today, this change goes live without any admin awareness or approval. ## Value / Impact Introducing an approval gate for permission-increasing releases would: Give central admin teams visibility and control over when building blocks gain elevated access to the meshStack API. Reduce the risk of unintended or malicious permission escalation through building block version updates. Align the release lifecycle of permission-sensitive building block versions with the existing workspace services approval system, creating a consistent governance model. Enable platform teams to continue shipping non-sensitive updates (versions that do not increase permissions) without additional overhead. The approval requirement should only trigger when the new version's ephemeral API key permission set is a strict superset of the previous version — so routine updates remain frictionless.

Problem / Use Case When using the meshStack Terraform provider , authentication currently requires a long-lived API key (client ID + secret). This means every developer or platform engineer who wants to run terraform plan or terraform apply locally must either: Create and manage a personal API key, or Share a team/service-account API key — reducing auditability and violating least-privilege principles. There is no way to authenticate as your personal meshStack user (e.g. via SSO / Entra ID) when using the Terraform provider. This is a gap compared to other cloud provider CLI experiences, such as az login (Azure), gcloud auth login (GCP), or aws sso login (AWS), where a one-time interactive browser login gives the CLI and Terraform provider access to your personal identity. Value / Impact A meshCLI with a meshcli login command (or equivalent) would allow platform engineers and application team members to: Authenticate once using their corporate SSO identity (Entra ID, Okta, etc.) via a browser popup. Have the meshStack Terraform provider automatically pick up the resulting short-lived token — no long-lived secrets required. Improve auditability: all API calls and Terraform operations are attributed to the real user, not a shared service account. Reduce the operational burden of managing, rotating, and distributing API keys for local development workflows. This would bring meshStack's developer experience in line with modern cloud CLI tooling and support zero-standing-privileges / short-lived credential patterns.

As a Platform Engineer I want to provide application teams the possibility to trigger Azure DevOps Workflows in self-service.

As a platform engineer managing my internal developer platform as code, I want to configure recurring prices for my Building Block Definitions and Platforms (Tenant Fees) via the meshObject API — so I can keep pricing configuration in version control alongside my platform definitions, automate price changes across environments, and avoid manual UI steps. Current Situation meshStack supports setting prices for Building Block Definitions and Platforms (Tenant Fees) via the meshPanel UI today. However, these prices cannot be defined or updated via the meshObject API or Terraform provider. This means: When automating platform setup end-to-end (e.g., via CI/CD or Terraform), pricing must still be configured manually in the UI Pricing is disconnected from the rest of your platform IaC configuration (meshBuildingBlockDefinition, meshPlatform, meshLandingZone) Requested Capability Expose pricing configuration via the meshObject API for: Building Block Definitions ( meshBuildingBlockDefinition ): include a spec.prices field supporting recurring fees (hourly/daily/monthly) with currency and amount Platforms (Tenant Fees) ( meshPlatform ): include a spec.tenantFee or spec.prices field supporting recurring tenant fees per platform This would allow platform engineers to fully configure their service catalog as code and automate the entire platform setup lifecycle without UI interaction. Note: The pricing could also be exposed as a separated product catalog API, i.e. setting up pricing is separate from setting up the building block/platform itself. However this should allow for a clear workflow from terraform. Related Requests Manage Building Block Definition via API — already shipped, but product/pricing catalog was explicitly excluded meshPlatform configuration via API — already shipped, but product/pricing catalog explicitly excluded Building block fees based on the volume — complementary pricing model request Contact our customer success team or support@meshcloud.io if you have questions.

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

As a Platform Operator, I would like to have the option for a deletion approval when a user deletes a building block. This would be useful in cases where there are manual steps involved after deleting the building block. Similar to the process of platform operator inputs.