Feature Requests

Problem / Use Case When importing a Building Block Definition (BBD) from meshStack Hub into the meshStack Admin Panel, I still have to manually configure inputs, output types, and variable mappings — even when the Hub module already ships a meshstack_integration.tf file that fully describes the BBD. For example, the version_spec of a BBD — which defines every input, its type (user-provided, static, tenant ID, etc.), validation rules, and outputs — is already expressed in the meshstack_building_block_definition Terraform resource inside meshstack_integration.tf . Today, the import wizard only partially reads this information, leaving me to manually fill in the rest through the UI. This manual step is especially painful when: Adopting a Hub module for the first time and there are 10+ inputs to configure Upgrading a BBD version and needing to re-enter unchanged metadata Onboarding a team that doesn't know Terraform but wants to use pre-built Hub modules Doing a live demo where every manual click breaks the "one-click" narrative Value / Impact A complete, zero-configuration import that reads all fields from meshstack_integration.tf would: Eliminate manual UI configuration entirely for Hub-sourced BBDs Reduce onboarding time from hours to minutes for teams adopting Hub modules Provide a compelling "one-click bootstrap" story for live demos and trials Ensure consistency between the Terraform definition and the Panel representation (no drift from manual re-entry) Automatically detect the correct input type (user-provided, static, tenant ID) from the Terraform variable's type and description — removing a common source of misconfiguration Context / Links Descriptor file for Building Block definitions in Git Repos — related in-progress request; the meshStack team is already working on using meshstack_integration.tf for import prefill Automatically set building block input type from terraform — specific ask for auto-detecting input types If you're hitting this today when importing Hub BBDs, reach out to our customer success team or support@meshcloud.io — we'd love to hear your specific scenario and help prioritize the missing fields.

meshStack's AWS integration for IAM Identity Center requires a SCIM token to manage groups and memberships. This approach presents two significant security challenges: Violation of Least Privilege: The SCIM token is overly permissive. It grants meshStack permissions beyond its actual needs (e.g., onboarding or modifying users), when it only needs to manage group creation and memberships. Requires manual/semi-automated secret rotation of the SCIM token AWS SCIM API only supports bearer tokens. This is a documented AWS limitation > IAM Identity Center SCIM implementation supports the bearer HTTP authentication scheme [...] Other authentication schemes described in the SCIM specifications are not supported at this time. If meshStack would use the AWS Identity Store APIs (e.g., identitystore:CreateGroup , identitystore:AddMemberToGroup , etc.) for its integration with AWS this would enable Enhanced Security (Least Privilege): Customers could attach a granular IAM policy to the role, limiting meshStack only to the specific Identity Store actions it requires. Simplified Operations: This would eliminate the need to securely store, manage, and rotate a long-lived SCIM token for the meshStack integration. Future-Proof (Secret-less): By moving fully to the AWS SDK (for both Identity Store and SSO Admin), we can enable authentication via Workload Identity Federation (WIF), allowing for a completely secret-less integration.

Use Case: As a Platform Operator, I want to group related Building Blocks (BBs) together using tags (e.g., from the tagging catalog) so that Application Teams can easily discover "sets" of services that belong to a specific platform offering. Example: I create an IDP with services K8s namespace, git repo, container registry and database -> they are designed to work together (but not necessarily dependent). I would tag them with "K8s IDP" and if I could switch on that filter in the marketplace (best via URL to also share it), I could point users to my specific platform BBs. It would be a first step towards the "Platform view" suggested elsewhere. Value Created: Improved Discoverability: Prevents specialized BBs from getting "lost" in a crowded marketplace. Enhanced Sales/Demo UX: Allows meshies and customers to demo a cohesive platform experience from the Developer Portal perspective rather than just the Platform Builder. Logical Organization: Aligns the marketplace view with the organization's existing tagging and governance structures.

As a user I don't know what a "meshProject" is, as it is mostly referred to by the name "Project". The term "meshProject" still appears in the project creation process in the "Tenant" step ("You could select multiple Cloud Platforms for your new meshProject"). I would like this to be renamed so it is consistently called "Project" everywhere. If there are other instances of the term "meshProject" visible to users, these should be renamed as well.

The aim is to enhance building block billing flexibility by allowing: Charging annual fees (for example, provisioning a Google Gemini AI license based on a yearly commitment). Defining diverse payment schedules (upfront payment or monthly instalments)

Problem / Use Case When running meshStack Building Block Definitions (BBDs) with an implementation type for GitHub Action Pipelines, meshStack passes the entire buildingBlockRun JSON as an input into the workflow. As user-provided input and metadata grow over time, this JSON can exceed GitHub’s documented limits for workflow_dispatch inputs (65,535 characters total and 10 top-level input properties). Once these limits are hit, workflows start failing in non-obvious ways, even though the underlying BBD logic itself would still work. Feature Request To avoid hitting GitHub’s input size limits, the pipeline should receive a buildingBlockRunUrl that points to the meshStack API resource for the building block run instead of passing the full JSON object. This way the pipeline can retrieve the full data as needed without being constrained by GitHub’s input size limits. Value / Impact Avoids hitting GitHub’s hard input-size limits while keeping existing BBD workflows functional. Makes BBDs more robust for tenants with large or evolving user input payloads (e.g. many parameters, user permission inputs). Reduces intermittent or opaque GitHub errors related to input size, especially on GitHub Enterprise installations which have even lower input size limits.

To make the marketplace better looking we should show all marketplace services in a grid view.

Centralized log management can greatly enhance end-to-end visibility and the security stance by enabling the extraction of audit logs/events from meshStack for import into an external tool such as a SIEM system.

The endpoint for retrieving workspace user groups ( https://docs.meshcloud.io/api/index.html#mesh_workspaceusergroup ) is currently available only to API users. It would be beneficial to extend support for API keys as well, enabling secure and more flexible access.

I want meshStack to forget about tenants that I have taken care of outside of meshStack. For this I need an option to tell meshStack to stop replication and set the tenant to "deleted".