Feature Requests

Problem / Use Case Dependency selectors currently appear at the bottom of the Building Block form. Users often fill in all other inputs first, only to discover at the end that a prerequisite dependency hasn't been provisioned yet (e.g. selecting a GKE cluster before configuring a namespace, selecting a Cloud SQL instance before creating a database, or realizing a required enabler is missing). This forces them to abandon the form and repeat their work after provisioning the missing dependency. Proposed Solution Make dependency placement within the form configurable. Moving the entire dependency section to the top of the form would already resolve the current use cases; there is no identified need to position individual dependencies separately within the form.

Problem / Use Case Building Block A depends on Building Block B. Building Block B produces an output that is a list of parameter values (e.g. available sizes, names, or IDs). Today, Building Block A's input cannot be populated with this list; the user has to manually type in one of the valid values, which is error-prone and creates a poor user experience for the Platform Team's end users. Proposed Solution Allow a Building Block input to be configured as a dropdown (single-select) whose options are dynamically sourced from a list-type output of a dependent Building Block. When Building Block A is run, the dropdown should automatically show the current values from Building Block B's output instead of requiring free-text entry.

As an Platform Engineer I want use one ssh-key instead reupload the same ssh key on multiple Building Blocks for cloning the repos. Mostly the same key has access to a bunch of repos. Maybe a select option if a ssh key is uploaded in the workspace where also the BBs are

Problem / Use Case Building Block Definitions today only support whole-number versions. Even a minor Terraform implementation fix (e.g. a small bugfix with no user-facing input/output changes) requires publishing a new whole-number version, making it hard to distinguish patch-level fixes from major, user-facing changes to a definition. Proposed Solution Support semantic versioning for Building Block Definitions, allowing minor and patch version segments (e.g. v1.1 , v1.1.1 ) in addition to major versions, so implementation fixes can be released without forcing a major version bump.

Problem / Use Case When a new version of a Building Block is available, workspace users currently have to wait for the platform team to coordinate and trigger the upgrade. This creates scheduling overhead for platform teams and blocks users from getting the latest version on their own timeline. Proposed Solution Allow platform engineers to opt in (per Building Block Definition) to letting workspace users trigger a version upgrade themselves. This gives users self-service control over when they upgrade, while keeping platform teams in control of whether that option is available at all.

As an engineer, I want to be able to provide temporary, run-specific information to a Building Block that can be used during that run without permanently changing its configured state. The implementation could be per-run metadata, temporary input overrides, or a one-off input change. The information should be available to the Building Block for that specific run and does not affect subsequent (manual) runs. Use case: We have a Building Block orchestrator that triggers scheduled runs in different modes. The orchestrator needs to provide additional information or partial input changes, so the Building Block can determine how it should execute. These orchestrated runs should: appear normally in the Building Block's run history, provide the temporary information to the Building Block during execution, allow the Building Block to use that information to select its execution mode, and leave the Building Block's previously configured state unchanged for the next run. The goal is to support one-off, orchestrated executions with temporary context or inputs, without requiring a second run to restore the Building Block's normal configuration.

Expose payment method consumption status via the meshObject API Problem / Use Case The meshObject API currently returns a payment method's configured budget ( amount ), but not how much of that budget has been consumed. To build automation on payment method consumption (for example, alerting or automatically deprovisioning workspaces once a budget is exhausted), I have to separately query usage/cost data and aggregate it myself against the payment method's budget. This is extra work that duplicates logic meshStack already runs internally, as evident by the panel showing consumed and remaining budget in the Workspace Overview's Budget card. Proposed Solution Include consumption status directly on the meshPaymentMethod object returned by the API (for example, consumed amount, remaining amount, and/or a percentage against the budget). This mirrors what the meshPanel UI already shows in the "FinOps > Payment methods" budget view, so API consumers get the same computed status without re-aggregating usage reports themselves.

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.

Problem / Use Case Our credential rotation policy requires rotating long-lived credentials at least every 90 days (or immediately when someone leaves the team). Today there's no way to rotate the runner's encryption keypair without either manually updating every Building Block input that was encrypted under the old public key, or sending us your old private key for a one-off re-encryption, which we don't want to do, it breaks the guarantee that only your runner can read your secrets. Proposed Solution Let the runner accept an optional "previous" private key for a configurable grace period alongside its current key. During that window, the runner can decrypt inputs still encrypted under the old key, then re-encrypt them with the new public key and submit the update through the existing input-update API, so you don't need to build custom automation to touch every input by hand. After the grace period, the old key can be retired runner-side.

As a platform engineer, I want to set how often drift detection runs for each building block definition. ## Problem Drift detection currently runs once every 24 hours. For security-relevant resources like storage buckets or Key Vaults, that gap is too long. If someone changes such a resource by hand, for example in the Azure Portal, it can stay misconfigured for up to 24 hours before meshStack notices. A storage bucket accidentally made public or a weakened Key Vault access policy can cause a serious security incident in that time. ## Proposed solution Let platform engineers set the drift detection interval on each building block definition, e.g. every 15 minutes, hourly or daily. Keep the current 24h interval as the default, so existing definitions behave the same. Optionally, allow a shorter interval for selected building blocks only, to keep load and cloud API costs under control. ## Value Misconfigurations on critical resources are found within minutes instead of hours. Platform teams can match the detection frequency to how critical each resource is. Helps meet compliance requirements that ask for timely detection of configuration changes, e.g. ISO 27001, BSI C5 and DORA.