Feature Requests

As a Platform Team I want to ensure that the Project Name (Display Name) within my GCP Organization is syned (replicated) to keep consistency between the meshTenant in meshStack and the actual GCP Project. At the moment the Display Name in the GCP Project can be edited in GCP directly. This will not be overwritten by our replication. This also is a different behaviour to the replication steps for AWS with the AWS Account Alias and Azure with the Subscription Name.

Problem / Use Case With WIF for Building Block Runs now available, platform engineers configure their backplane (e.g. an AWS IAM role trust policy or GCP WIF pool) to trust the specific subject claim for a Building Block Definition (BBD): system:serviceaccount:<meshstack_id>:workspace.<workspace_identifier>.buildingblockdefinition.<bbd_uuid> When using the meshStack Terraform provider to manage BBDs as infrastructure-as-code, setting up this trust is currently cumbersome and error-prone: The BBD UUID is only known after the BBD has been created (it is assigned by meshStack). Platform engineers must manually construct the subject string from multiple components ( meshstack_id , workspace_identifier , bbd_uuid ) and pass it to downstream Terraform resources that configure WIF trust. This creates a chicken-and-egg problem: to get the UUID you must create the BBD first, but configuring the WIF backplane trust may be needed before (or alongside) creating the BBD version spec. Today, this requires splitting terraform apply into multiple steps. There is currently no computed attribute on meshstack_building_block_definition that exposes the full WIF subject claim. Workarounds exist (see GCP Storage Bucket example and AWS S3 Bucket example ), but they require manually composing the subject string and splitting the Terraform apply into multiple steps. Value / Impact Adding a computed workload_identity_federation_subject (or workload_identity_federation.subject ) attribute to meshstack_building_block_definition would: Allow platform engineers to reference the WIF subject directly in Terraform without manual string construction: meshstack_building_block_definition.my_bbd.workload_identity_federation_subject Eliminate string composition errors and make backplane trust configuration declarative and repeatable. Bring the developer experience in line with the meshstack_integrations data source, which already exposes WIF info for platform replication. When does a single terraform apply work? If your backplane is structured such that the resources consuming the WIF subject (e.g. an IAM role trust policy or GCP WIF pool condition) are separate from the resources that provide static inputs to the BBD version spec , Terraform can resolve the dependency graph in a single apply pass. In that case, the computed workload_identity_federation_subject attribute is all you need. When is an additional resource split needed? If your backplane configuration (e.g. an IAM role ARN or a GCP pool ID) must also be passed back as a static input to the BBD version spec , a true circular dependency arises that Terraform cannot resolve in a single pass — even with the computed attribute. In that scenario, fully automating the setup in one terraform apply would require a future building_block_definition_version_spec resource that separates BBD creation from BBD version spec creation. See this follow-on request Context / Links WIF for Building Block Runs — shipped (Canny) meshStack Terraform Provider — meshstack_building_block_definition GCP Storage Bucket BBD workaround example AWS S3 Bucket BBD workaround example If you're hitting this issue, reach out to our customer success team or support@meshcloud.io — we'd love to hear your specific setup and use case.

Introduce building_block_definition_version_spec resource in meshStack Terraform provider Problem / Use Case The current meshstack_building_block_definition Terraform resource bundles the Building Block Definition (BBD) entity — which holds the stable UUID and WIF subject — together with its version spec (inputs, implementation config, release state) in a single resource. This creates an unresolvable circular dependency in a common Workload Identity Federation (WIF) setup: You create meshstack_building_block_definition to get the BBD UUID and its WIF subject claim. You configure your backplane (e.g., an AWS IAM role trust policy, a GCP WIF pool principal) to trust that WIF subject. The backplane outputs (e.g., the IAM role ARN or GCP pool ID) must then be passed back as static inputs to the BBD's version spec. Because the BBD entity and its version spec are coupled in a single Terraform resource, Terraform cannot: Create the BBD (to obtain the UUID/WIF subject), Configure the backplane using that UUID, Complete the BBD version spec with backplane outputs — ...all in a **single terraform apply **. The dependency graph becomes circular within a single resource boundary, forcing platform engineers to split the apply into multiple manual steps. This affects any WIF-secured BBD where the backplane provides both the trust configuration and a static input to the same BBD version spec — a common pattern in real-world platform engineering setups. Value / Impact Introducing a separate building_block_definition_version_spec resource (decoupled from meshstack_building_block_definition ) would allow Terraform to resolve the full dependency graph in one pass: meshstack_building_block_definition creates the BBD and exposes its UUID and WIF subject as computed attributes. Downstream backplane resources (IAM roles, WIF pool providers) consume the WIF subject. meshstack_building_block_definition_version_spec consumes backplane outputs as static inputs — referencing the BBD created in the same configuration. This unlocks: **Single-pass terraform apply ** for the complete BBD + backplane setup, even when backplane config flows back as a static input to the BBD version spec. Full GitOps automation — the entire BBD lifecycle (definition, version spec, backplane trust) is declared in one Terraform configuration, without manual sequencing. Reduced operational risk — no more partially-applied states from multi-step apply workflows. Natural alignment with the meshStack API , which already models meshBuildingBlockDefinition and meshBuildingBlockDefinitionVersion as separate objects. This is especially impactful for platform teams managing many BBDs with WIF-secured backplanes, and for reusable Building Block Hub modules where full automation is a key requirement. Context / Links Add WIF subject attribute to the Building Block Definition Terraform resource (Canny) — parent feature request; the building_block_definition_version_spec split is the follow-on for the general case WIF for Building Block Runs — shipped (Canny) meshStack Terraform Provider — meshstack_building_block_definition meshStack API — meshBuildingBlockDefinitionVersion If you're hitting this issue, reach out to our customer success team or support@meshcloud.io — we'd love to understand your specific setup and help prioritize this.

Reactivate (restore) a previously deactivated platform type As a platform engineer, I want to be able to reactivate a previously deactivated platform type so that I can restore it without having to create a brand-new one from scratch. Current behavior Platform types can be deactivated (soft-deleted) in meshStack. Once deactivated: The platform type is no longer selectable when creating a new platform or building block definition (BBD). The identifier is permanently blocked — it cannot be reused or restored through the UI. The only workaround today is a manual backend operation (hard-delete or reactivation) performed by meshcloud support. Desired behavior Provide a "Reactivate" action for deactivated platform types in the meshStack Admin UI and/or API, so that: A deactivated platform type can be restored to active status. The platform type becomes available again for selection when creating platforms or BBDs. No support ticket or manual backend intervention is needed. Why this matters Platform engineers may deactivate a platform type by mistake or during early setup, before any platform instances, tenants, or building block definitions have been created against it. Currently there is no self-service way to undo this. Reactivation is a natural complement to deactivation and removes a frustrating dead end. Next steps and feedback If you've hit this issue, please upvote and share your use case in the comments. We're especially interested in: How often does this happen in your environment? Do you need reactivation via the UI, the API, or both? Reach out to us at support@meshcloud.io if you need help with a deactivated platform type in the meantime.

Problem / Use Case When a Building Block in meshStack uses the Public API with an ephemeral API key to create a project, tenant, or nested building block, that resource is effectively managed as-code via Terraform. The meshStack panel currently shows a standard "Delete" action for these resources — with no indication that they are Terraform-managed and no guardrails to prevent bypassing the Terraform lifecycle. This creates two concrete problems: Infrastructure drift: deleting a resource from the panel does not clean up the Terraform state, leaving the Building Block run in an inconsistent state or causing errors on the next run. Confusing UX: platform users and engineers have no indication that a resource was created by a Building Block, and no guidance that the correct deletion path is through the parent Building Block instance — not through the panel's delete button. Value / Impact Prevents accidental infrastructure drift when Building Blocks manage resources via the Public API. Gives platform engineers a clear, guided deletion path: remove the Building Block instance that created the resource, and Terraform will handle cleanup automatically. Reduces support tickets from users stuck in inconsistent or permanently "pending deletion" states. Builds naturally on the already-implemented ephemeral API key infrastructure to deliver a coherent "managed as-code" experience end-to-end. Proposed Behavior When a project, tenant, or building block instance is created via an ephemeral API key (i.e., from a Building Block run), meshStack records this origin. In the panel, attempting to delete such a resource should replace or annotate the delete action with a clear warning and a direct link to the parent Building Block instance: "This resource is managed by [Building Block Name]. Remove the Building Block instance to trigger proper cleanup via Terraform." Admins may optionally be given a force-delete option with explicit acknowledgement of the risk. Context / Links Related: Automatically delete building blocks on tenant/project deletion ( https://feedback.meshcloud.io/admin/board/feature-requests/p/automatically-delete-building-blocks-on-tenant-project-deletion ) — planned, 15 votes Related: Building Block Deletion Approval ( https://feedback.meshcloud.io/admin/board/feature-requests/p/building-block-deletion-approval ) — open, 5 votes Related: Keep building block runs for deleted building blocks ( https://feedback.meshcloud.io/admin/board/feature-requests/p/keep-building-block-runs-for-deleted-building-blocks ) — open, 7 votes

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 a meshstack user, I don't want to be aware of the mandatory building blocs in a landing zone in order to order platforms more hazzlefree. Actually, as an end user, the bb name has to be confirmed, althoug I do not know the purpose and the meaning of the building block since it comes automatically with the landing zone.

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.