Feature Requests

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.

As a platform engineer, I want to create, list, and delete meshStack API keys programmatically via the meshStack REST API. Currently, API keys can only be created through the meshStack UI (Admin Area > Access Control > API Keys). This makes it impossible to automate API key lifecycle management, which is needed for: Automated provisioning of API keys as part of infrastructure-as-code workflows Programmatic key rotation for security compliance Self-service API key management integrated into CI/CD pipelines The ephemeral API keys feature (for Building Block runs) covers a narrow use case but does not allow creating persistent, named API keys with configurable permissions via the API. Requested capabilities: POST endpoint to create a new API key with specified name and permissions GET endpoint to list existing API keys DELETE endpoint to revoke/delete an API key Ability to set permission scopes on creation

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 )

As a Platform Engineer, I want to be able to retrigger an existing building block, for example to renew Service Principal credentials. Ideally, this could be done via an API.

As a platform engineer managing meshStack via Terraform, I want a data source that exposes metadata about the meshStack instance itself so that I can reference it in my automation. Currently, the meshStack Terraform provider offers data sources for workspaces, projects, tenants, and other domain objects — but there is no way to query information about the meshStack instance as a whole. Example usage: data "meshstack_instance" "info" {} This could expose attributes such as: API endpoint URL Panel URL meshStack version SSO / Identity Provider URLs Environment identifier (e.g. dev, staging, production) Use cases: Configuring downstream resources that need to reference meshStack URLs (e.g. callback URLs, webhook targets) Conditional logic in Terraform based on which meshStack environment (dev vs. prod) the automation is running against Documenting or tagging resources with the meshStack instance they belong to Avoiding hardcoded URLs across Terraform configurations

As an Enterprise Architect I would like to restrict the ability to create workspaces only to a limited set of users

Introduce a native feature in meshStack to track whether a resource is managed via Infrastructure as Code (IaC), specifically Terraform, and identify its provenance. On resource creation and updates, the TF provider should send this metadata to meshStack and should persist this metadata in its backend. Expose this information via the meshStack UI and API to make it easily discoverable. Goal: Enable users to quickly determine whether a resource is managed via Terraform, the originating Git repository and location as the source of truth for resource definitions Benefits: Improved traceability of resources managed via IaC Faster troubleshooting for administrators Enhanced transparency and governance for platform users

Problem / Use Case When configuring a Building Block Definition that clones a GitHub repository, meshStack currently only supports SSH keys. This is a significant operational burden for platform teams in many organizations because: SSH keys must be individually managed per Building Block Definition — every definition requiring its own key pair, with no way to share credentials across definitions. GitHub Apps and Personal Access Tokens (PATs) are the preferred, modern approach for automation in GitHub, offering fine-grained repository permissions, short-lived credentials, and centralized management without requiring a dedicated "machine user." As a result, platform teams working in GitHub-first organizations are forced to maintain workarounds or cannot adopt meshStack Building Blocks at all for their GitHub-based automation. Value / Impact Supporting GitHub App installations and/or Personal Access Tokens (PATs) as alternative authentication methods for cloning repos would: Remove a major adoption blocker for GitHub-heavy platform teams. Align meshStack with GitHub's own recommended authentication best practices (see GitHub Apps documentation and Managing personal access tokens ). Enable fine-grained repository access control without requiring a dedicated GitHub machine user. Support short-lived, automatically-rotating tokens through GitHub Apps, improving security posture. Allow one set of credentials to be reused across multiple Building Block Definitions in a workspace. Context / Links Related Canny requests that highlight the same pain for other git providers: Support Azure DevOps OAuth via Service Principal to checkout Git repositories One SSH-key for multiple Building Blocks If you're running into this issue or have a specific use case, please reach out to support@meshcloud.io — we'd love to hear the details.

Hey, it would be really useful to have a schedule feature that allows re-running building block instances. For example this would allow automatic, recurring rotations of secrets that are deployed by a BB without any additional infrastructure. Or this would make it possible to have BB instances automatically updated to the latest Terraform definition without further user interaction. I could imagine an extra option in the BB definition to allow running BB instances on a schedule by defining a Cron schedule or something like that. This should apply to all existing BB instances. Kind regards Martin

As a cloud foundation team, I want to be able to lock a workspace when action-required communications have not been resolved, so that I can enforce compliance actions instead of just requesting them. Currently, the Communication Center allows sending action-required communications to workspaces with a due date. However, these are purely informational -- workspace users can ignore them entirely and continue using the workspace without any restrictions. The email notification is easy to miss, and even when the communication is visible in the panel, it does not prevent any workspace actions. This limits the usefulness of action-required communications for enforcing compliance, security reviews, or mandatory acknowledgements. Requested behavior: Option to mark a communication as "blocking" when creating it When a blocking communication is unresolved (especially past its due date), workspace actions should be restricted (e.g. creating new projects, provisioning tenants, ordering building blocks) Workspace users should see a clear message explaining why their workspace is locked and what they need to resolve Once the communication is resolved, the workspace should be unlocked automatically Use cases: Enforcing security questionnaire responses before allowing continued cloud usage Mandatory acknowledgement of breaking changes or policy updates Compliance reviews that must be completed within a deadline