Feature Requests

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.

When using the JSON input type for building blocks, the generated form currently has gaps around guiding and constraining the consumer at the per-field level: Per-property immutability: there's no way to mark a single property inside a JSON Schema input as "settable once, then frozen." Whole-input immutability exists via updateable_by_consumer on a Building Block input, but that freezes the entire JSON object, not an individual field within it. Today the only workaround is splitting out the field that needs to be immutable into its own separate, sibling input outside the JSON schema. Custom validation messages: validation error messages are fixed, generic strings per JSON Schema keyword (e.g. "The value has an invalid format." for any pattern mismatch). There's no way to provide a custom, field-specific message, e.g. "Must be a valid Azure resource group name: lowercase, 3-63 characters, no spaces." Formatted descriptions: the description field only renders as plain text. Line breaks ( \n ) are collapsed and no markdown/formatting is supported, so multi-point guidance (e.g. a bulleted list of constraints) can't be displayed clearly to the consumer. Together these make it hard to build well-guarded, well-documented JSON Schema inputs: consumers get no clear upfront guidance for multi-constraint fields, no actionable feedback when validation fails, and no way to protect a single field from being changed after it's first set without breaking it out of the JSON form entirely. Suggested improvements: Support marking individual properties within a JSON Schema input as immutable after first submission (write-once per field, not just per whole input). Support a custom error message per validation rule (similar to the errorMessage keyword pattern from ajv-errors), surfaced in the generated form instead of the generic keyword message. Render description with line breaks preserved (and/or basic markdown support) so multi-point constraints can be communicated clearly.

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.

Problem / Use Case When a Building Block depends on another Building Block Definition that is configured to be assignable only "Once" per project/tenant/workspace, and exactly one instance of that dependency already exists in scope, users still have to manually pick it from a dependency selector showing a single option. Proposed Solution If a dependency's Building Block Definition is scoped to "Once" and only one matching instance exists in the relevant scope, pre-select it automatically in the ordering form instead of requiring a manual pick.

Problem / Use Case Technical helper and enabler building blocks clutter the marketplace for standard users, who have to wade through irrelevant services to find what they need. Proposed Solution Let administrators define a default tag-filter set that's applied automatically when a user opens the marketplace. Users still see a curated catalog on first load but can modify/clear filters themselves.

Problem / Use Case Platform teams want to curate featured/starter services in the marketplace, but today this can only be set manually in the UI, not managed as configuration. Proposed Solution Expose the "Featured / Mark as featured" setting on a Building Block Definition through the meshStack Terraform provider, so it can be version-controlled and applied consistently across environments.

Problem / Use Case Today, a building block instance page mainly shows what it depends on. It doesn't show what can or does depend on it, and there's no way to jump straight into creating a valid follow-up service. Users have to leave the page, search the marketplace, and hope they pick a compatible definition. Proposed Solution Add a "Related services" view on the building block instance page that shows: Dependencies: what this instance requires Dependents / related services: definitions that can depend on this instance, with a pre-filtered "Create related service" action Example: from a Cloud SQL instance, create a database; from a GKE cluster, create an additional namespace.

Problem / Use Case When reviewing a Building Block run (e.g. before approving a tofu plan), there's no way to see an at-a-glance summary of what's changing. Platform engineers have to dig through the raw plan output to figure out how many resources will be added, changed, or removed, which slows down review and makes it easy to miss a destructive change. Proposed Solution Show a compact summary on the BB run/plan view with counts of resources to be added, changed, and removed (similar to the standard terraform plan summary line), so reviewers can assess the blast radius of a run before approving it.

Problem / Use Case Building Block Definitions can already be backed by a Git repo, but the git experience today has several gaps that force manual steps and create traps: BBDs pin to a "Git Reference" that can be a floating branch name. Merging a feature branch into main does not update the BBD, it silently keeps running the old branch until someone remembers to repoint it. There is no way to see what a change to a Building Block's Terraform code will actually do before it merges or before it upgrades a live instance. Every plan is only visible at apply time, after the fact. Creating a new Building Block Definition version after a code change is a manual step today. Repo access is limited to inline SSH keys, there is no GitHub App or PAT-based integration, so meshStack cannot receive repository events (PRs, releases) or post status back to GitHub. As a result, teams cannot get a normal "branch, PR, merge, release" workflow for their Building Blocks the way they would for any other Terraform module, entirely without needing their own CI/CD pipeline to plug meshStack in. Proposed Solution Introduce a meshStack GitHub App (or equivalent for other Git providers) integration that drives the whole Building Block lifecycle without a platform engineer needing to write or maintain any GitHub Actions/CI of their own: Immutable version pinning : released BBD versions must pin to a commit hash or tag, never a floating branch. Warn or block promotion out of draft if the Git Reference doesn't match a hash/tag pattern. PR-time plan check : on PR opened/updated, meshStack runs a plan-only Building Block run on its own infrastructure against a dedicated canary instance (representative dummy inputs), and posts the result back as a GitHub Check Run under the meshStack App's identity. No customer-authored workflow file involved. Automatic BBD versioning : on merge or GitHub Release published, meshStack automatically creates the next Building Block Definition version pinned to the new commit/tag, no manual "create version" step. Traceable upgrades : when a live instance upgrades to a new BBD version, the run and its plan link back to the exact commit/tag/PR that produced it. Known gaps to close (linking related requests already tracked): Floating branch references / no warning on unpinned BBDs: Building Block definition and working with branches ("stuck BB definition") No GitHub App / PAT-based repo authentication (needed for webhook delivery and posting check runs, beyond just cloning): Support GitHub App and Personal Access Token authentication for Building Block repo cloning

We would like a workspace Building Block input that: Displays the active Payment Methods of the target workspace as a dropdown. Provides the selected identifier or meshObject reference to the implementation. Validates that the Payment Method belongs to the workspace. Supports selection when creating or updating the Building Block through meshPanel and the API.