Feature Requests

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.

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 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.

We would like to request the feature to retrieve information about all created building blocks in the workspace as part of a building block definition. A possible and probably elegant way to do that would be to extend the "context metadata" input variable types with a type for "Workspace Building Blocks". Comparable to other "context metadata" input types, this input would hold a list of building blocks that are currently booked under the workspace (probably including the one that contains the input itself in case that building block was created), and would dynamically trigger updates on the building block with this input as soon as new building blocks are created/updated/removed. The list of building block can then be iterated, filtered and processed inside the Terraform code. Having this kind of input would allow to handle relations between building blocks, that are currently very limited (one building block can only depend on one other), in the most flexible way. One building block might want to get information about other building blocks in order to implement certain permission structures or other "orthogonal" concerns.

As a new user, I have just received my first email from meshcloud, informing me that someone has added me to a workspace. However, I have no idea what meshcloud is, what this workspace is for, or why I was added. It would be great to receive an introductory welcome email from meshcloud including links to learning resources