Feature Requests

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.

Problem / Use Case As a platform engineer or developer who wants to consume a building block definition via Terraform (using the meshStack Terraform provider), I currently have to manually look up the correct resource type, input variable names, types, and required vs. optional fields, write the meshstack_building_block resource block from scratch, and — most frustratingly — find the correct definition_uuid and definition_version UUID, which is not easily discoverable in the Marketplace UI. This is tedious and error-prone, especially for building block definitions with many inputs. Finding the right version UUID in particular is a common pain point that leads to trial-and-error and unnecessary support requests. Proposed Solution In the meshStack Marketplace, each building block definition's detail page should display a pre-generated Terraform code snippet that can be copied directly into a Terraform module. The snippet would include: The correct meshstack_building_block resource block with all inputs pre-populated as placeholders Required vs. optional inputs annotated via comments The correct definition_uuid and definition_version already filled in — no more hunting for UUIDs A minimal working example showing how to reference a meshstack_project or meshstack_workspace as the parent Value / Impact This dramatically lowers the barrier to consuming building blocks via Terraform/IaC, accelerates automation of meshStack, and reduces support requests caused by misconfigured provider resources or hard-to-find version UUIDs. Especially valuable for customers building IDP automation layers on top of meshStack.

we are deploying our building block definitions via terraform. the order in which inputs are defined in terraform is not respected deployed building block definition. this is currently only supported in the UI and not exposed via the public API but i would like the full building block definition state to be inside terraform.

Problem / Use Case Building Block Definitions can produce outputs — such as connection strings, API keys, tokens, or passwords — that are sensitive by nature. Currently, all outputs are treated equally and displayed in plain text wherever they are surfaced (e.g. in the meshStack UI, in chained building block configurations, or in audit logs). Platform engineers who provision infrastructure via Building Blocks often generate secrets as outputs (e.g. database credentials, service account keys, storage access tokens). There is no way to flag these values as sensitive so they are protected from casual exposure in the UI or stored securely. Value / Impact Marking an output as sensitive would allow meshStack to: Mask the value in the UI (e.g. show •••••• with a reveal toggle) so it is not exposed to users who do not need it Prevent the value from appearing in audit logs or being serialized into non-encrypted storage Signal to downstream consumers (e.g. parent building blocks referencing this output) that the value should be handled securely This is especially important for compliance-conscious customers who need to demonstrate that secrets generated during infrastructure provisioning are not leaked through the platform UI. Context / Links Related Canny post (inputs): https://feedback.meshcloud.io/admin/board/feature-requests/p/hide-building-block-inputs-from-end-users

Problem / Use Case When building custom platforms with meshStack building blocks, a common requirement is to create and manage IAM groups in central directories — such as Entra ID, Azure AD, or LDAP — so that these groups can be used in downstream systems that sync from those directories (e.g. Azure DevOps, GitHub Enterprise, or other third-party platforms). Today, meshStack already replicates groups through its native replicator as part of workspace/project lifecycle management. However, this replication is tightly coupled to the platform integration and cannot be used as a standalone, composable step in a custom platform building block chain. Platform engineers building bespoke automation workflows have no way to invoke group replication on-demand or as a discrete building block output. Value / Impact Exposing group replication as a building block would allow platform engineers to compose group creation into custom platform workflows alongside other building blocks, support at-a-distance use cases where a group must exist in a central directory before a dependent platform can use it via sync, reuse meshStack existing proven replication logic rather than reimplementing it in custom Terraform or scripts, and configure naming patterns, group membership mapping, and scoping declaratively per building block definition. Proposed Approach The building block would accept the standard user_permissions input (providing workspace members and their roles) and replicate groups to a configured target directory according to a naming convention pattern. Possible implementation paths: a managed runner type offered by meshcloud as a service (no customer infrastructure needed), or a first-class building block type in the meshStack catalog (similar to how Terraform runner type works today). Configuration options: naming pattern templates, target directory (Entra, LDAP, etc.), role-to-group mapping. Note: as raised in the related request below, a locking or deduplication mechanism would be important. If multiple building block instances depend on this replication step, the replication should only be triggered once per project to avoid race conditions. Context / Links Related request (same building block direction, different motivation): https://feedback.meshcloud.io/admin/board/feature-requests/p/workload-identity-federation-for-global-marketplace-replicator-or-replacement-by Related request (user_permissions as BB input): https://feedback.meshcloud.io/admin/board/feature-requests/p/building-block-user-permissions-not-only-from-the-parent Prior art (shipped): https://feedback.meshcloud.io/admin/board/feature-requests/p/replicate-groups-to-entra-id-administrative-units

We have a requirement from our Identity team to enforce strict Access Settings. Currently, with meshcloud it seems new groups are being created with the Google default access settings. We would like to be able to define this at the meshcloud platform level. https://support.google.com/a/answer/9007750?hl=en

We would the ability to apply security labels to groups as they are created. This comes as a requirement from our Identity/Security teams. https://support.google.com/a/answer/10607394?hl=en https://cloud.google.com/identity/docs/how-to/update-group-to-security-group

I am a platform engineer working at a large organization. I currently use the shared runner provided by meshStack to run my building blocks, which is also used by other platform teams. I would rather run my own runner infrastructure and register it with meshStack. This could work similarly to how GitHub does it with their GH Action Runners Update: Please note that private runners operated by meshcloud are available as a solution to have runners in a private networking configuration. See https://docs.meshcloud.io/meshstack.building-blocks.private-runners for more details. However, it is currently not possible to self-host the runner on your own without support by meshcloud as we have not made the necessary APIs available yet have separate runners for separate platform teams as requested in this feature request. Runners are currently shared between all building block definitions in a meshStack

Problem / Use Case Finding the right resource in a large meshStack deployment is harder than it should be. When you manage dozens of workspaces — each with multiple projects and tenants — there is no single place to type a name, identifier, or tag value and jump straight to what you need. Today the only option is navigating workspace by workspace and using the search in the workspace overview. Concrete scenarios this affects every day: A platform engineer needs to find a specific tenant by its cloud account ID (e.g., AWS Account ID, Azure Subscription ID) and has no idea which workspace or project it belongs to. An operator wants to find all objects tagged with a specific value (e.g., a cost center, a MarcID, an owner email) — across all workspaces — to investigate a billing anomaly. A user knows their project name but is assigned to many workspaces and can't easily surface it in the workspace switcher. Value / Impact A global search bar — accessible from any screen in meshStack — would let platform engineers and end users: Find any workspace, project, or tenant by name, identifier, or tag value in seconds. Navigate directly to the right object without drilling through the hierarchy. Reduce the number of support tickets raised to cloud foundation teams just to locate a resource. This mirrors the experience platform engineers expect from tools like the Google Cloud Console, AWS Console, or Azure Portal — all of which provide a top-level search box as a first-class navigation element. Scope ideas (for discussion) Search across: workspaces, projects, tenants, building blocks Search by: name, identifier, tag key/value (e.g., cost center, owner) Role-aware results: users only see objects they have access to; admins see all Quick-navigate: clicking a result takes you directly to that object's detail page

As a platform engineer, I want to manage my entire meshStack Admin Area configuration through the Terraform provider so I can treat my meshStack setup as code and replicate it consistently across environments (e.g. dev, staging, production). The meshStack Terraform provider has made great progress covering core domain objects like platforms, landing zones, building block definitions, tag definitions, workspaces, projects, and tenants. However, several Admin Area sections still require manual configuration through the UI and have no API or Terraform support. What is still missing: Policies -- create and manage compliance policies as code API Keys -- create, list, and delete API keys programmatically Project Role Definitions -- manage custom project roles Runners -- configure building block runners Settings -- General (Message of the Day, support URLs), Appearance (email branding), Compliance (recertification periods, API key expiration), Management (SCIM, invitation tokens), Financials (currency conversion) Communication Center -- manage notification templates Admin Access -- manage admin role assignments Service Brokers -- register and configure OSB service brokers Why this matters: Enables full GitOps for meshStack configuration -- no more manual UI steps Makes it possible to consistently replicate a meshStack setup across dev and production environments Reduces configuration drift between environments Enables disaster recovery by having the complete configuration in code Allows platform teams to review changes to meshStack configuration through pull requests Related existing tickets (open): meshPolicies via meshObject API and terraform provider ( https://meshcloud.canny.io/feature-requests/p/meshpolicies-via-meshobject-api-and-terraform-provider )