This release includes the following issues:
Audience: User
We extended the meshBuildingBlock API with new capabilities for managing building blocks and their runs.
You can now update building block inputs in place using a PUT request, without having to delete and recreate the building block. After updating inputs, you can retrigger a new run via a dedicated action endpoint. This enables automation workflows that modify building block configurations and apply changes incrementally.
We also added a new endpoint to list building block runs filtered by building block, and an extra endpoint to download logs on individual runs that returns structured step including status and messages.
When runTransparency is enabled on a building block definition, workspace-scoped API keys can retrigger
runs and access full run logs including system messages. The building block response also includes input definition metadata
such as assignment type and value type.
Upgrading to meshStack 2026.23.0 requires upgrading the Terraform provider to v0.21.0. If you use the
meshstack_building_block_v2 resource with sensitive inputs, you should also replace value_string or
value_code with the new value_string_sensitive or value_code_sensitive attributes - these store the
value masked in Terraform state and transmit it securely.
See the known issue post for the full upgrade guide: https://feedback.meshcloud.io/knownissues/p/meshbuildingblock-api-update-requires-terraform-provider-upgrade-to-v0210
Audience: User
You can now trigger dry runs for your OpenTofu building blocks, with no special configuration required. A dry run previews what changes would be applied to your infrastructure without making any actual modifications, helping you validate changes safely before applying them.
Navigate to an OpenTofu building block and open the Runs tab. Use the "Trigger Run" split button and click the dropdown arrow to select "Dry Run".
Audience: User
We improved the default sorting order in the building block table. Building blocks are now automatically sorted first by their Building Block Definition name, then by the definition version number, and finally by the building block name. This provides a more predictable and useful overview when browsing building blocks in the Administration area.
Audience: User
We improved the API reference for the Building Blocks meshObject API v2-preview. When you list Building Blocks, the response schema now documents the full Building Block structure. Previously the list response was only described as a generic array, which made it harder to discover the available fields.
Audience: User
When a draft version of a building block is in use, a "(Draft)" indicator is now shown next to the version name on the building block instance view and the building block card. Previously, the version appeared without any indication that it was still a draft, which could cause confusion about whether the version had already been released.
Audience: User
We added a Building Blocks shortcut to the workspace actions menu in the Administration area. Administrators can now jump directly from any workspace row in the workspace table to its associated building blocks with a single click.
Audience: User
We fixed a bug in the API documentation where the API version selector was not shown for GET endpoints. You can now select the desired API version for all endpoint types, including GET endpoints, and see the correct Accept header value to use in your API requests.
Audience: User
Building Block run lists now show why a run started and who triggered it. This helps you understand whether a run was started manually or by an automated meshStack change.
Audience: User
You can now reorder inputs and outputs in building block definitions using drag-and-drop. Simply grab an item and drop it in the desired position - the new order is saved when you save the definition. This makes it easier to organize inputs and outputs in a logical sequence without having to delete and re-add them.
Audience: User
Some meshObject API resources require a minimum version of the terraform-provider-meshstack. This is especially relevant for preview-versioned APIs, which receive breaking changes before reaching general availability. When your provider version is below that minimum and a request to such a resource fails, the error response now includes a resolutionHint field telling you exactly which version you need to upgrade to.
Audience: User
We fixed a bug where the loading spinner in the building block run Summary box kept spinning even after the run had already reached a final state (e.g. failed or succeeded). The spinner now correctly disappears once the run is complete.
Audience: User
When configuring building block definition outputs, the available assignment type options are now filtered based on the selected output type. For example, INTEGER and BOOLEAN outputs only support "None", while STRING outputs support all assignment types. This prevents invalid combinations and reduces configuration errors.
When editing a building block definition version, navigate to the Outputs section. After selecting an output type, the assignment type dropdown will automatically show only the options that are valid for that type. If you change the output type to one that no longer supports the currently selected assignment type, the assignment type will reset to "None" automatically.
Audience: User
We improved the building block and run pages with three visual updates:
Audience: User
Building block runner selection now includes a Refresh button to reload the available runners without reloading the page. Additionally, we've added helpful guidance explaining when to use shared runners versus creating your own: use the shared runner for quick setup, or create your own runner to access internal networks, meet compliance requirements, or isolate sensitive workloads.
Audience: User
You can view deleted building blocks in the overview table. They are shown by default, but you can also filter specifically for them by selecting the "Deleted" status filter.
You can also open them, view their past runs and inspect their logs.
Audience: User
When a platform is configured with "Skip User / Group Permission Cleanup", we now correctly preserve existing user permissions even when a tenant is in a pending deletion state (e.g. pending approval or pending resource deletion). Previously, meshStack would still remove all user permissions from the platform during these intermediate deletion states, which is not the intended behavior when this option is enabled.
Enable "Skip User / Group Permission Cleanup" in the replicator configuration of the affected platform. meshStack will then leave all existing group and permission assignments on the platform intact throughout the entire tenant lifecycle - including deletion states - so that the platform operator can clean them up manually at a later point.
Audience: User
We improved compatibility for two additional SCIM PATCH operation formats for groups. First, you can now remove a specific group member using a filter expression in the path, e.g. members[value eq "meshIdentifier"]. This lets SCIM clients target individual members without sending a full value array. Second, you can now update group attributes (such as displayName or externalId) using a replace operation without an explicit "path" field, by embedding the attribute name directly inside the value object.
]]>This release includes the following issues:
Audience: User
When upgrading a building block that requires single-select or multi-select inputs not yet set, you now see a proper dropdown with the available options in the panel instead of a free-text field.
Audience: User
We refreshed the building block runs view to use a table, so it's consistent with other run views in meshStack. You can now filter runs by status or run type (dry run vs. regular run) to quickly find what you're looking for. The table also shows whether each run was a dry run or a regular run.
Audience: User
meshStack now tracks the version of each building block runner whenever it reports for work. We display the last known version in the runner details page and the runner overview table, making it easy for you to verify that your runners are up to date.
Audience: User
The meshServiceInstance v2 API now includes the service broker identifier in the response. You can use this
field to identify which service broker is managing a given service instance without having to perform
additional lookups. You can also filter the list of service instances by service broker identifier using
the new serviceBrokerIdentifier query parameter.
Audience: User
The workspace overview welcome state now displays featured services when available, making it easier for new users to discover and access the most relevant resources for their workspace. The redesigned welcome screen prominently showcases featured services alongside quick links to browse the full marketplace and create projects.
Audience: User
We fixed a bug where the delete button in the admin area was incorrectly hidden for runners that belonged to other workspaces. Admins can now delete any custom runner regardless of which workspace owns it. Runners shipped with meshStack are protected and will continue to show a lock icon instead.
Audience: User
We updated how you reference targets when creating building blocks via the meshObject API. Since meshBuildingBlock is still in preview, we made this breaking change to align target references with the standard meshObject API conventions. This ensures consistency across the API as the feature matures.
For tenant-scoped building blocks, use uuid to identify the target tenant:
"targetRef": {
"kind": "meshTenant",
"uuid": "<tenant-uuid>"
}
For workspace-scoped building blocks, use name to identify the target workspace:
"targetRef": {
"kind": "meshWorkspace",
"name": "<workspace-identifier>"
}
The previously accepted identifier field is no longer supported in targetRef.
Audience: User
We consolidated the building block overview into a single table with fewer columns for a better overview. Tenant-level and workspace-level building blocks now appear together, giving you one place to manage everything.
Search also got better: a new combined column allows you to search building blocks over name, definition name, definition version and the corresponding UUIDs. Another new hierarchy column lets you filter by workspace, project, and platform using names, identifiers and UUIDs. You can also filter by multiple statuses at the same time.
All search fields accept multiple terms separated by spaces or commas - results will match all of them.
Audience: User
meshStack no longer sets or manages AWS account aliases during replication. The "Account Alias Pattern" and "Enforce Account Alias" configuration fields still exist in the API and are persisted for backward compatibility with existing configurations (e.g., Terraform provider). However, their values are ignored - meshStack will not create, update, or enforce account aliases on AWS accounts. These values were intended for an old removed IdB flow. As account aliases need to be unique across AWS, the removal of these fields increases project name reusability.
If you relied on meshStack to set AWS account aliases, you will need to manage account aliases yourself going forward. Existing account aliases on your AWS accounts are not affected by this change - meshStack will simply stop updating them.
If you use the Terraform provider or manage platform configuration via the meshObject API, your existing
configurations remain valid. The fields accountAliasPattern and enforceAccountAlias can still be
submitted and will be accepted, but their values will have no effect on replication behavior.
Audience: User
We have removed the meshIdB IAM type for AWS platform integration from meshStack. This integration type used the
meshStack-internal identity provider (Keycloak / meshIdB) as a SAML IdP for AWS IAM, and was previously deprecated.
All AWS platforms must now use either the AWS IAM Identity Center (SSO) or the AWS Identity Store API integration type. If your platform was still configured with the meshIdB type, meshStack will automatically remove the obsolete configuration. Please reconfigure your platform to use one of the supported IAM types.
We recommend migrating to the AWS Identity Store API integration, which supports Workload Identity Federation (WIF) and does not require a long-lived SCIM token. For further details, see the deprecation notice.
]]>This release includes the following issues:
Audience: User
We fixed a bug where building blocks that were deleted or marked for deletion still appeared in the workspace resources view. You will now only see active building blocks there.
Audience: User
The meshObject API now supports filtering building blocks by lifecycle state, allowing you to also retrieve soft-deleted building blocks via the API.
By default, only active (non-deleted) building blocks are returned, preserving backward compatibility. Please refer to our public API documentation for details on how to use this filter.
Important: To ensure building block deletion works correctly, you must upgrade the Terraform provider to version 0.20.9 or later. Building block deletion will not succeed with older provider versions.
Audience: User
We now correctly enforce that building block definition versions using the manual implementation type can only use PURGE as their deletion mode. Manual building blocks have no deletion automation, so DELETE - which implies running automated cleanup - is not a valid option for them.
If you use the meshBuildingBlockDefinitionVersion API to create or update a manual building block definition version, make sure to set deletionMode to PURGE. Requests that specify DELETE will now be rejected with a validation error.
Audience: User
After creating a new building block runner, meshPanel now takes you directly to the runner's setup page. There you find a ready-to-use Docker configuration and a docker run command tailored to your runner. Once the container is running, meshPanel automatically detects when the runner connects and shows you a confirmation - so you know everything is working without having to check manually.
Audience: User
When you open a runner's detail page, you can now find a ready-to-use Docker setup guide directly on the page.
The guide provides a pre-filled configuration file and a complete docker run command tailored to your runner,
so you can get a self-hosted runner up and running without leaving meshPanel.
Audience: User
We now prevent API key permission groups from containing the same action more than once for the same scope. This keeps permission lists unambiguous and fixes the Building Block Runs group.
No action is needed. API key permissions now show distinct actions within a group, so you can select the intended permission without duplicate entries.
Audience: User
You can now provide a plain RSA public key (PEM-encoded, BEGIN PUBLIC KEY format) when creating or updating a building block runner, in addition to the previously required X.509 certificate. This simplifies the key generation process - you no longer need to create a self-signed certificate and can use a standard RSA key pair instead. Existing runners using X.509 certificates continue to work without any changes.
The updated help dialog in meshPanel now guides you through generating a simple RSA key pair and explains the commands step by step.
Audience: User
You can now freely edit the inputs and outputs of a building block definition version while it is in draft state, even if building block instances using that version already exist. Previously, any existing instance would block all input and output changes, forcing platform engineers to delete instances or work around the restriction. Note that removing an input will also remove it from all existing building blocks using that draft version once you save. Changing an output that another definition depends on as an input may break building block execution for the affected workspace - you will need to manually fix that dependency connection.
]]>This release includes the following issues:
Audience: User
The building block runner detail and create screens now have a consistent page header, matching the style of the building block definition detail view. The header shows the runner's name and UUID for quick reference, along with a "Back to Runners" navigation link so you can easily return to the runners overview.
Audience: User
We fixed limitations when wiring building blocks together. String-compatible output types (string, code, single-select, multi-select) can now be used as the source for string or code inputs on dependent building blocks.
For manual building blocks, single-select inputs now automatically produce a string output, and multi-select inputs produce a code output. This means you can chain manual building blocks that use selection inputs into downstream building blocks without hitting type mismatch errors.
We also fixed a bug in the building block definition version API that allowed invalid output types to be set on manual building block definition versions. The API now validates that outputs match the types derived from their corresponding inputs.
Audience: User
We resolved an issue that caused errors when sending updates to building block deletion runs. Updates to deletion runs now complete reliably without unexpected errors.
Audience: User
We improved how you create and manage building block runners in the platform builder. When creating a new runner, a selection dialog now guides you through choosing the right runner type before filling out the form.
We also introduced a clearer distinction between meshcloud-managed runners (pre-deployed with meshStack) and self-hosted runners (created by your workspace team). meshcloud-managed runners are read-only and cannot be edited or deleted, making it easier to identify which runners you own and can configure.
Audience: User
When creating a new building block runner, you now get step-by-step instructions for generating the required public key right inside the form. A "How to generate a key" button next to the Public Key field opens a modal with clear, OS-specific commands for macOS, Linux, and Windows, and automatically selects the right tab based on your operating system.
Audience: User
We fixed an issue where date selector dropdowns in tables were cut off. You can now fully interact with date pickers without any visual clipping.
Audience: User
We fixed an issue where the platform metering status could show as "Failed" due to carbon footprint data collection results, even when the BigQuery table for CO2e was not configured on the platform. meshStack now ignores the carbon footprint collection status when determining the overall metering status if carbon footprint reporting is not configured for the platform.
Audience: User
The spec.supportedPlatforms field in the meshBuildingBlockDefinition API has changed from a
plain list of strings to a list of meshPlatformType references.
This makes the field consistent with how other meshObject API fields reference meshStack entities, and ensures that the values are clearly typed and validated.
Previously, you would specify supported platforms as a plain string array:
"supportedPlatforms": [ "AZURE" ]
Now each entry must be a meshPlatformType reference object with a kind and name field:
"supportedPlatforms": [ { "kind": "meshPlatformType", "name": "AZURE" } ]
The name corresponds to the metadata.name of the meshPlatformType.
Audience: User
We've improved the building block runner management screens to make them cleaner and easier to use. Implementation types (such as Terraform, GitHub Workflow, or GitLab Pipeline) now display with recognizable icons throughout the runner overview and detail screens.
Audience: User
As part of our work to finalize the meshBuildingBlock API for GA, we moved lifecycle information for building blocks in the meshObject API from the metadata section to the status section, where it belongs according to our API conventions.
The status.lifecycle object now contains the building block's lifecycle state (e.g. ACTIVE
or MARKED_FOR_DELETION), its creation date (createdOn), and, if applicable, when and by
whom it was marked for deletion (markedForDeletionOn, markedForDeletionBy).
The metadata.createdOn, metadata.markedForDeletionOn, and metadata.markedForDeletionBy
fields have been removed. Since the meshBuildingBlock API is a preview version, this is a
breaking change. Please update your integrations accordingly.
Audience: User
You can now set the IAM type to 'None' when configuring an AWS platform in meshStack. In this mode, meshStack still replicates and manages AWS accounts, but skips all IAM permission and group replication in AWS IAM Identity Center.
This is useful when you want meshStack to handle account provisioning without managing user access via IAM Identity Center, allowing you to set up access control separately without interference from meshStack's replication. It also allows you to iteratively set up an AWS platform in meshStack without worrying about IAM replication until you're ready to enable it.
]]>This release includes the following issues:
Audience: User
We fixed an issue where using input types like single select or file with the manual building block runner caused meshStack validation of the run to fail. Manual building block runs now correctly complete for all input types.
Audience: User
The meshObject API now provides a new preview resource type meshApiKey.
The API key clientSecret is returned when the key is created or when expiresAt changes and cannot be retrieved again afterwards.
Privilege escalation is prevented by ensuring that a new API key can only receive permissions that are a subset of the calling API key's permissions.
Audience: User
Workspace API keys with the BUILDINGBLOCKDEFINITION_LIST permission can now list building block definitions across all workspaces by setting the includeAllPublished=true query parameter. This enables cross-workspace discovery of published building blocks, e.g. a platform team publishing BBDs that application teams in different workspaces can consume via Terraform. Only released and published versions are visible for definitions owned by other workspaces. The optional ownedByWorkspace query parameter can be used to scope results to a single workspace.
Audience: User
Breaking Change (Preview API): The meshBuildingBlockDefinitions list endpoint query parameter
workspaceIdentifier has been renamed to ownedByWorkspace for consistency with other endpoints.
If you are using this parameter, please update your API calls accordingly.
Audience: User
We removed support for Azure Blueprints from meshStack. Microsoft has officially deprecated Azure Blueprints and scheduled them for retirement on July 11, 2026. Our metrics confirmed that no customers are actively using Azure Blueprints, so we proactively removed the feature ahead of Microsoft's retirement date. As a result, we removed Azure Blueprint configuration from landing zones, platform configuration, and the meshObject API. This is a backwards incompatible change. If you are using the meshStack Terraform provider (see: https://registry.terraform.io/providers/meshcloud/meshstack/latest/docs), please update it to the latest version before applying any changes. Older provider versions may still reference the removed Azure Blueprint fields and cause your Terraform runs to fail with an API error. If your landing zones or platform configurations currently reference Azure Blueprints, you should migrate to alternative solutions such as mandatory building blocks on your landing zones, which provide similar governance capabilities with a supported and actively developed feature set.
Audience: User
We removed support for OpenShift template instantiation from meshStack. OpenShift templates can no longer be configured in landing zones and will no longer be applied to OpenShift projects during replication. We also removed the OpenShift template property from the meshObject API landing zone configuration. This is a backwards incompatible change. Our metrics confirmed that no customers were actively using this feature, and it had been previously announced as deprecated. If you are using the meshStack Terraform provider (see: https://registry.terraform.io/providers/meshcloud/meshstack/latest/docs), please update it to the latest version before applying any changes. Older provider versions may still send the removed openShiftTemplate landing zone property, causing your Terraform runs to fail with an API error.
Audience: User
We now visually distinguish resources that are pending deletion in the workspace overview. Projects and resource cards that are awaiting deletion appear greyed out with reduced opacity, and their interactive elements (links and buttons) are disabled. This makes it immediately clear which resources are no longer active, helping you avoid confusion when managing your workspace.
Audience: User
You can now manage building block runners programmatically via the new meshBuildingBlockRunner API. The API supports listing, retrieving, creating, updating, and deleting building block runners.
Note: This API is currently in preview and is subject to change without prior notice. We do not guarantee backwards compatibility for preview versions. Please wait for the stable release before relying on this API in production workflows.
The API endpoints are accessible at /api/meshobjects/meshbuildingblockrunners. Refer to the API
documentation for details on available fields and operations.
Audience: User
When you delete a tenant or project, meshStack now automatically removes all associated building blocks for you. You no longer need to manually clean up building blocks before initiating deletion.
The deletion page now shows a list of building blocks that will be automatically removed, so you have full visibility into what will be cleaned up.
Navigate to the tenant or project deletion page as usual. If there are building blocks associated with the tenant(s), they will be listed under the resources that will be automatically removed. Simply confirm the deletion - meshStack takes care of the rest.
Audience: User
When users are created via the SCIM API, we now automatically generate event logs that capture the user creation action. This improves audit capabilities and provides better visibility into user provisioning activities from SCIM integrations.
Audience: User
The meshStack API documentation now includes a more intuitive version picker that allows you to easily switch between different versions of an endpoint. The version picker synchronizes request and responses and displays a notice banner when selecting a preview version of an API endpoint.
The notice banner now links to the "Preview API Limitations" section in the documentation. This section provides important information about preview APIs, including unnaounced breaking changes and their exclusion from our usual support SLA resolution guarantees.
Audience: User
The event log search by author filter has been fixed. Previously, searching for event logs by author returned no results even when matching logs existed. You can now reliably search event logs using author information (username, email, or name for human users, or system/API key identifiers), making it easier to audit and track activity in your workspaces.
]]>This release includes the following issues:
Audience: User
We fixed an issue where building block cards could display broken resource links when the output value was not yet available. The card now correctly filters out resource URL outputs that have no value, so you only see links that actually work.
Audience: User
You can now create global groups via SCIM without providing the "members" attribute in your request. The group will be created with an empty membership list, which you can later populate using SCIM PATCH operations. This improves compatibility with SCIM clients that omit the "members" attribute when creating groups.
Audience: User
The SCIM API now correctly handles PATCH operations without an explicit "path" field, as defined in RFC 7644 section 3.5.2.3. Previously, these operations would fail with an error. With this fix, meshStack supports both PATCH operation formats, improving compatibility with a wider range of SCIM clients. While there are no visible changes for current SCIM users at this time, this improvement is an important step toward fuller SCIM compliance and enables support for more standards-compliant SCIM clients in the future.
Audience: User
The SCIM API now exposes the /Schemas, /ServiceProviderConfig and /ResourceTypes discovery endpoints through the SCIM API root, making it discoverable alongside other SCIM resources like Users and Groups. This enhancement improves SCIM client compatibility by allowing clients to discover all available SCIM resources through a single discovery mechanism. While there are no visible changes for current SCIM users at this time, this improvement is an important step toward fuller SCIM compliance and enables support for a wider range of SCIM clients that rely on standard discovery mechanisms in the future.
Audience: User
The workspace services admin table was displaying items in a different order when you reloaded the page. We fixed the underlying pagination logic to ensure consistent, deterministic ordering across page reloads. The table will now maintain the same item order every time you load or refresh the page.
Audience: User
We fixed an issue where search boxes in meshStack were completely unresponsive on the latest version of Safari. You can now use search as expected across all supported browsers.
Audience: User
When importing a building block definition, inputs with no default value were incorrectly prefilled with the string "null" instead of being left empty. We fixed this so that inputs without a default are now correctly omitted from the prefill.
Audience: User
You can now configure the default project quota for workspaces directly from the Admin Area under Settings > Compliance Settings > Workspace Quotas. Previously, this required a Dhall configuration change and a redeployment of meshStack. The new default applies to all newly created workspaces. Existing workspaces retain their current quota and can still be adjusted individually via the workspace quota settings.
Audience: User
SCIM PATCH requests that attempt to change a user's userName to one already used by another active user are now rejected with a 409 Conflict error. This prevents a data integrity issue where duplicate userNames could be created in the system, which would subsequently cause server errors (500) when querying users by that userName.
Audience: User
We added project identifiers to the workspace overview project list. You can now see each project's identifier alongside its display name and click it to copy to clipboard.
]]>This release includes the following issues:
Audience: User
You can now write up to 5,000 characters in the Communication Center message body, up from the previous limit of 1,000. This gives you much more room to communicate detailed instructions, remediation steps, or announcements to your workspace users.
Audience: User
The SCIM API now returns the correct HTTP status code (400 Bad Request) when receiving invalid requests, such as unsupported filter fields, instead of returning a generic 500 Internal Server Error. This allows SCIM clients to properly distinguish between client errors and server errors, enabling better error handling and debugging.
Audience: User
We fixed a bug where creating a building block via the API was rejected even though the API key held the admin-level permission (e.g. the ability to list workspace bindings across all workspaces). Previously, the permission escalation check only accepted an exact match of the workspace-scoped permission required by the building block definition. Now, admin-level permissions are also accepted, so you can implement cross-workspace automation scenarios.
Audience: User
We fixed a bug in the workspace creation flow where the duplicate cost center warning was shown when you initially entered a valid cost center value. The warning now only appears when the cost center is really already in use by another workspace.
Audience: User
You can now filter API keys in the panel. This helps you quickly find the key you need when managing many API keys.
Audience: User
We fixed a display issue across several tables in the panel where long cell content was clipped or truncated instead of wrapping to the next line. This affected tables such as the building block list, runner list, building block definition list, and others. Cell content now wraps to the next line, making the full value visible without any extra interaction.
Audience: User
We improved the responsiveness of the welcome page and landing page layouts. Text, logos, icons, and buttons now scale gracefully across different viewport sizes, preventing content from being clipped or overflowing on narrower screens.
Audience: User
When ordering a Building Block from the marketplace or the Building Block creation dialog, the suggested Building Block name is now displayed as a prominent title at the top of the form. You can edit it inline by clicking the pen icon next to the name. A warning hint reminds you that the name cannot be changed after creation.
Click the pen icon next to the Building Block name in the ordering form to edit it. Press Enter or click the checkmark to confirm, or press Escape or click the X to cancel.
Audience: User
We improved our SCIM API compliance for PATCH requests. When a PATCH operation provides a value that is incompatible with the target attribute's type, the API now correctly returns a "invalidValue" error instead of the misleading "immutable" error. This makes meshStack more compliant with RFC 7644 and helps SCIM clients better understand the actual cause of a rejected request.
Audience: User
When using the simplified workspace overview feature preview, the back button on the building block details page incorrectly navigated to the old building block list instead of the workspace overview. This has been fixed and the back button now consistently returns you to the workspace overview.
Audience: User
Building block names now update live while you configure a new building block. When the building block
definition name contains mustache-style placeholders like {{ repoName }}, meshStack fills them in
automatically from your input values and non-sensitive static values. Duplicate names are still handled
by appending numeric suffixes such as (1).
Set your building block definition name to a template such as GitHub Repo {{ repoName }}, where
repoName is one of the definition's user inputs. When a user orders this building block and types
my-service into the repoName input, the building block name is set to GitHub Repo my-service
in real time. If that name already exists on the same tenant, meshStack appends a suffix automatically,
e.g. GitHub Repo my-service (1).
Audience: User
Communication Center notification emails now clearly display the workspace name. This helps you identify which workspace a notification applies to, especially when you are a manager or owner of multiple workspaces. Previously, recipients received identical-looking emails without workspace context, making it difficult to understand which workspace each notification related to.
Audience: User
When editing the inputs of a workspace-scoped building block definition, we previously showed input sources that are not applicable to workspace building blocks, such as "Project Identifier", "Full Platform Identifier", and "Platform Tenant ID". These options are only meaningful for tenant-scoped building blocks.
We fixed this so that only the correct input sources are available when configuring inputs for workspace building block definitions.
Audience: Operator, User
meshPlatform v2 now exposes optional spec.accessInformation via the public
meshObject API, and this value is consumed by the Terraform provider to expose
platform access information.
Tenant access views now render this field as Markdown. Plain-text notes with
newlines now render as a single line.
This release includes the following issues:
Audience: Operator
We updated the HashiCorp public signing key used by the Terraform building block runner when downloading Terraform binaries.
This mitigates an upstream key-rotation/expiry change in HashiCorp release signing that could otherwise cause Terraform binary verification failures.
With this update, Terraform binary installation continues to work for both older supported Terraform releases (for example 1.4.x/1.5.x) and current releases signed by the same HashiCorp key family.
]]>This release includes the following issues:
Audience: User
We fixed a bug where deprecated platforms were still visible and selectable when creating new tenants or projects, and remained visible in the marketplace catalog. This contradicted the documented behavior that deprecation prevents further tenant creation.
Deprecated platforms are now correctly hidden from the marketplace, tenant creation wizards, and project creation flows. Attempting to create a tenant on a deprecated platform via the API is also rejected. Existing tenants on deprecated platforms remain unaffected.
Audience: User
We fixed an issue where Building Block runs could get stuck in an "in progress" state indefinitely without ever being executed. Previously, aborting these stuck runs was also not possible. Both issues are now resolved - runs will no longer get stuck, and can be properly aborted if needed.
Audience: User
We fixed a widespread display bug where tables throughout the admin and user area would overflow their containers on smaller screens or when many columns were shown. This caused broken horizontal scrollbars that spanned the entire page, making content hard to read and navigate. All tables now scroll horizontally within their own containers, keeping the rest of the page layout intact.
Audience: User
When sorting the workspace services table by workspace, the page failed to load with an internal error. We fixed this so you can now sort workspace services by workspace without issues.
Audience: User
We fixed a regression where deploying a workspace building block from the platform builder always showed a tenant selection dropdown, even though workspace building blocks do not require a tenant.
Audience: User
When creating a new workspace, single-select workspace tags with default values were not being pre-populated correctly. If the default value's name contained a substring that matched another tag option, the wrong option would be selected instead. For example, with options "dev", "dev-restricted", and a default of "dev-restricted", the tag would incorrectly pre-fill with "dev".
Audience: User
When importing a building block definition from meshStack Hub, we now prefill more fields from the Terraform configuration and apply sensible defaults for the fields missing from the configuration.
Audience: User
We fixed a race condition that could cause concurrent landing zone creation requests to fail with HTTP 500 errors. This issue affected landing zones with mandatory building blocks when using OpenTofu or other tools to create multiple landing zones on the same platform simultaneously. The system now properly serializes these requests to prevent conflicts and ensures all landing zones are created successfully.
Audience: User
We fixed a bug where the text editor for CODE-type inputs was not rendered during building block upgrades when the input was newly added in the target version. This prevented users from entering required values, making the upgrade impossible to complete.
Audience: User
We improved the authentication mechanism for building block Terraform runs. The runner now uses a short-lived, per-run ephemeral token instead of long-lived credentials, reducing the security exposure of each run.
If you use the meshStack-managed Terraform HTTP backend, OpenTofu 1.7.2 or later is required to support this change.
Audience: User
When creating a new platform instance, you can now see and browse all available platform types. Previously, the list was limited to the first 50 entries, which could hide platform types if many were configured.
Audience: User
We improved the internal handling of building block run triggers. Building block runs are now triggered more efficiently. This reduces the risk of stale or inconsistent data being used during building block runs and makes the overall triggering more resilient.
Audience: User
The "Reason" column in the Access Requests table on the Admin Access Control page now properly wraps long text instead of overflowing horizontally. This improves readability and ensures all access request details are visible within the table layout.
Audience: User
We improved the internal mechanism used to trigger tenant replication. The new approach prevents data inconsistencies and race conditions that could previously cause tenant replications to temporarily fail in rare cases.
Audience: User
The event log now shows a meaningful author display for all events, including older ones. Previously, the improved author column (with an icon indicating the author type (user, API key, or system) and a readable name) was only visible for events created after November 2025. Older events showed a cryptic UUID instead. We've extended this improvement so that all events, regardless of when they were created, now benefit from the same clear and informative author display. You can also hover over the author icon to see a tooltip with the author type.
Audience: User
The meshObject API now returns 400 Bad Request instead of 500 Internal Server Error when importing workspace or project bindings that reference a non-existent workspace, role, or project. This makes it easier to diagnose and fix invalid binding import requests.
Audience: User
The meshObject API now returns 400 Bad Request when creating a building block whose targetType (e.g. meshTenant or meshWorkspace) does not match the provided target reference. Previously, inconsistent target information was accepted and could cause errors during processing.
Audience: User
The dashboard now shows building block definitions and platforms sorted by last modification date, with the most recently changed items appearing first. This makes it easier for you to quickly see what's been updated at a glance, without having to search through an alphabetical list.
Audience: User
Previously, meshStack emitted a "building block runner changed" event every time a building block runner was updated via the API - even when nothing actually changed. This meant the event log showed change entries with no visible diff. We fixed this so that meshStack now skips the event entirely when the runner configuration is identical to what was already stored.
Audience: User
When you renamed an output of a parent building block definition which is in draft state, any child building block definition in draft state that had an input referencing that output would silently lose its connection. You had to manually find and fix the broken input reference. This relation now updates automatically.
Audience: User
We extended the input validation for building block definition versions to also cover sensitive inputs
of type CODE. When providing a sensitive CODE input via the API, the plaintext value must be a plain
string. If you pass a raw JSON object instead, the API now returns a clear error message explaining
what went wrong. Please refer to our API documentation for details on the correct format.
Audience: User
When you create a new building block and a block with the same name already exists in the same workspace or tenant, meshStack now automatically suggests a unique name for you - for example, "My Block (1)" or "My Block (2)". The name field switches into edit mode so you immediately see the suggestion and can adjust it further before deploying.
Audience: User
This fixes a bug where building blocks using the "User Permissions" input type were not re-triggered in all affected workspaces when a user was disabled or enabled (e.g. via SCIM).
Previously, building blocks were only re-triggered in workspaces where the user had a direct binding. If the user's access came via group membership, those workspaces were silently skipped - so those building blocks kept running with outdated permission data until the next unrelated change in that workspace.
Building blocks that use the "User Permissions" input type will automatically receive updated role data the next time a user in the affected workspace is disabled or enabled. You can also trigger any affected building block manually to apply the correct data immediately.
]]>This release includes the following issues:
Audience: User
We fixed a display bug in the admin area tenant list where the table would break the page layout on smaller screens. When the table ran out of space to compact further, it overflowed its container and caused a broken horizontal scrollbar across the whole page. The table now scrolls horizontally within its own container, keeping the rest of the layout intact.
Audience: User
A third-party dependency contained a bug that caused git access checks to fail with "Connection reset" errors on certain container environments. This could prevent users from creating or testing building block definitions that use SSH-based git repositories. We have updated the dependency to a version that fixes this issue.
Audience: User
When configuring a building block in the marketplace, the inputs screen now shows a loading indicator while fetching the configuration data. Previously, the screen would appear blank with no feedback during loading, which could be confusing.
Audience: User
When configuring dependencies for a building block definition, you can no longer select the definition itself as a dependency option. The building block definition is now excluded from the dependency selection list, making it clearer upfront that self-referencing is not allowed. The backend has always prevented this configuration - this is purely a UI improvement.
Audience: User
Building block runners can now send outputs incrementally across multiple updates and then send a final status change without re-sending all outputs. This resolves issues where runs were incorrectly marked as failed when the runner sent outputs in separate API calls during execution.
Audience: User
We fixed an issue where the allowHierarchicalOrganizationalUnitAssignment flag on AWS platform configurations was
not correctly returned when reading platforms via the meshObject API. This caused API clients like the Terraform
provider to report inconsistencies after applying a configuration.
Audience: User
We removed the allowHierarchicalManagementGroupAssignment field from the AzureRG platform configuration in the
meshObject API. This field was never operational for AzureRG platforms and was always returned as false. If you
are setting this field in your API requests for AzureRG platforms, you can safely remove it.
Audience: User
We now hide all access request-related tabs and actions when the Four-Eye Principle (4EP) is not enabled in your meshStack deployment. This keeps the UI clean and avoids confusion by only showing features that are actually available.
The following items are now hidden when 4EP is not enabled:
Audience: User
We added a STACKIT Storage Bucket building block definition to the platform builder getting started page. You can now quickly deploy a STACKIT storage bucket directly from the welcome experience, just like you could already do with AWS, Azure, and GCP storage buckets.
Audience: User
We've added STACKIT to the list of available platform types in meshStack. This means you can now integrate STACKIT as a platform in meshStack and manage your STACKIT resources.
When creating a new platform, simply select STACKIT from the list of platform types to get started with your integration.
Audience: User
We have updated the meshStack panel favicon to reflect our current product logo.
]]>This release includes the following issues:
Audience: User
The "Open Platform Builder" banner that used to sit above the services in the marketplace has been removed. Instead, a card now appears at the end of the service list, so you can browse services without a banner pushing everything down.
Audience: User
We've refreshed the look of featured service cards in the marketplace. They now display with a clean white background and a blue border, matching the style of regular service cards while still standing out clearly. We've also removed the service count from the "All Services" heading to keep the interface cleaner and less cluttered.
Audience: User
When you view the details of a building block, we now show you only the relevant inputs first, while static inputs (managed automatically by the platform) are hidden by default. Should you need to see the static inputs, you can always reveal them by clicking the corresponding button. This makes it easier to focus on the fields that actually matter to you.
Audience: User
We fixed a bug where updating an existing building block definition with a GitLab implementation would always fail with a "Could not read request body" error. You can now update GitLab building block definitions without errors.
Audience: User
We fixed a bug where assigning a global group to a project via the meshObject API always failed with a "group does not exist" error, even though the group existed. You can now successfully assign global groups to projects using the meshObject API.
Audience: User
We fixed a visual glitch in the sidebar navigation where collapsing or expanding a section caused a small jump at the end of the animation. The sidebar now collapses and expands smoothly.
Audience: User
You can now specify an optional Git reference (e.g. a branch or tag like refs/heads/my-branch)
when configuring an Azure DevOps pipeline building block definition. This allows you to pin a building
block to a specific branch or tag of your pipeline's repository.
When no Git reference is provided, Azure DevOps uses its default branch as before.
Audience: User
We fixed a small visual bug where the page content would shift a bit when opening a modal dialog.
Audience: User
We fixed a bug where the "Deploy building block" button never became active when deploying a draft building block for testing that has no user-configurable inputs (all inputs are set statically by the definition).
Audience: User
We fixed a bug where the "General Information" form in the building block definition creation wizard was pre-filled with data from a previously created building block definition.
Audience: User
When you import a building block definition from the meshStack Hub and you only have access to a single workspace, we now skip the workspace selection step and navigate you directly to the new definition form. This saves you an unnecessary click and makes the import flow faster.
Audience: User
We redesigned the welcome section of the platform builder dashboard to guide you through the initial setup of your platform with a clear, step-by-step onboarding flow. The new experience walks you through creating your first Building Block Definition and integrating your first platform, with quick-start examples for AWS, Azure, and GCP.
When you open the platform builder dashboard as a new user, you will see the updated welcome section with guided steps. Each step includes cards that link directly to relevant resources like the meshStack Hub for Building Block examples, or pre-filled platform integration wizards for supported cloud providers.
Audience: User
You can now abort building block runs that are pending (queued but not yet started), waiting for input, or waiting for a dependent building block to complete. This gives you full control to abort stuck or unwanted runs, regardless of their current state.
Audience: User
When a building block fails because it did not emit all outputs defined in the building block definition, you now see a clear failure reason and which specific outputs are missing. Previously, the building block was just marked as failed without any details, making it hard to understand what went wrong.
Audience: User
When creating or updating a building block definition version via the API, we now validate that inputs of type CODE have their argument provided as a JSON-escaped string. If you pass a raw JSON object instead of an escaped string, the API returns a clear error message explaining what went wrong. Please refer to our API documentation for details on the correct format.
]]>This release includes the following issues:
Audience: User
We moved the building block definition journey wizard to a more prominent position at the top of the control plane page header. This makes it easier for you to follow the three-step process of creating, testing, and publishing your building block definition. The wizard now also features an updated visual style that is consistent with the platform builder dashboard.
Audience: User
The featured star icon was not appearing next to featured services in the workspace services admin view, even when a service had been marked as featured. We fixed this by correctly including the featured status in the API response, so the star now shows up as expected.
Audience: User
We improved the way identifiers are displayed throughout the meshStack user interface. Identifiers such as project, workspace, tenant, platform, and building block UUIDs are now shown using a new, consistent identifier widget. This makes it easier to recognize, copy, and use these identifiers across the platform.
You can now click on any displayed identifier to copy it to your clipboard. The new identifier widget is available in all major areas of the UI where identifiers are shown, providing a more consistent and user-friendly experience.
Audience: User
You can now filter the marketplace catalog by tags. When browsing the catalog, you can select tags to narrow down the list of building blocks to only those that match specific tag values.
Audience: User
We fixed a bug in the platform builder where the breadcrumb on the "create new platform" screen incorrectly displayed the raw route parameter "New/:platformTypeHref" instead of "New Platform". The breadcrumb now correctly shows "New Platform" when you navigate to create a new platform.
Audience: User
We fixed a bug where clicking external links (like GitLab CI/CD pipeline links) in building block run steps would not navigate to the URL. The links would only open when using the right-click context menu.
Audience: User
When creating or updating a building block definition via the meshBuildingBlockDefinition API, the icon symbol field now validates that base64-encoded image data does not exceed 100 KiB after decoding. This prevents large icon payloads from consuming excessive server resources. The validation also ensures that base64 data is properly formatted and rejects malformed base64 strings with a clear error message.
When providing an icon symbol for your building block definition using a data URI (e.g.,
data:image/png;base64,...), ensure that the original image file does not exceed 100 KiB in size. If you
encounter a validation error indicating that your icon exceeds the size limit, compress or resize your image and
re-encode it to base64. HTTPS and HTTP URLs remain unaffected by this validation and can reference icons of any
size.
This release includes the following issues:
Audience: User
Platform admins can now add a custom free-text note to any platform under Settings > Configuration > Replication Config. This note is displayed to users on the platform access screen, providing a convenient way to share additional guidance, links, or instructions for accessing the platform.
Navigate to your platform's control plane, go to Settings > Configuration > Replication Config, and enter your custom message in the "Access Information Note" field. Save your changes - the note will immediately appear for all users when they access a tenant on that platform.
Audience: User
When importing a building block definition from the meshStack Hub, meshStack now pre-fills
significantly more fields in the wizard when the module contains a meshstack_integration.tf file.
This file provides a full description of the building block definition, including its variables,
and meshStack uses it to populate the wizard automatically.
If a module does not contain a meshstack_integration.tf file, meshStack falls back to the
previous behaviour.
Audience: User
We introduced a new feature preview called "Simplified Workspace Control Plane". When enabled, the workspace control plane hides the separate Projects and Building Blocks tabs, giving you a cleaner and more focused layout for managing your cloud resources.
Navigate to your Feature Previews in the user menu to opt in to the "Simplified Workspace Control Plane" feature preview. Once enabled, the Projects and Building Blocks tabs are removed from the workspace control plane, streamlining your navigation.
Audience: User
We added the ability to feature services in the marketplace. As a meshStack admin, you can now mark platforms and building block definitions as "featured" from the workspace services overview. Featured services appear in a dedicated highlighted section at the top of the marketplace catalog, making it easy for your users to discover recommended services at a glance.
Audience: User
When you invite a new user to a workspace via invitation token, they now only receive the invitation email. Previously, an additional "Access to Workspace Granted" email was sent alongside the invitation, which was redundant and confusing. We fixed this so that invited users receive a single, clear invitation email until they accept the invite.
Audience: User
We refined the visual design of tags throughout meshPanel. Tags now feature a cleaner, more compact look with improved spacing, consistent use of theme colors, and comma-separated values for better readability. The "show more" controls are now styled more subtly to keep the focus on your tag content.
Audience: User
When you create or update a building block definition via the meshObject API with a description that exceeds 255 characters, you now receive a clear and actionable error message that tells you exactly what the issue is. Previously, the API would return a cryptic internal error.
Audience: User
We improved how building block runs are prioritized in the execution queue. Previously, a building block run that had repeatedly timed out could block fresh building block runs from other workspaces from being picked up by the runner.
Now, new building block runs (that have never timed out) are always prioritized over runs that have previously timed out. This means a struggling building block no longer prevents other building blocks from being executed. Timed-out runs continue to retry, but with lower priority than fresh runs.
Audience: User
When creating a new platform, we now correctly detect if the chosen identifier is already used by a platform in another workspace. Previously, the validation silently ignored this case, allowing you to submit the form with an identifier that was already taken (which then failed).
Audience: User
You can now register a workspace even if another workspace already uses the same display name. Previously, workspace registration incorrectly rejected display names that were already in use, even though workspace display names in meshStack do not have to be unique (while identifiers have to be unique).
Audience: User
We fixed a bug where building block outputs defined with type CODE were incorrectly stored as STRING after a run. This caused the panel to not render the output value with code formatting, even when the building block definition explicitly configured the output as CODE.
Audience: User
We streamlined the workspace navigation for users who opted into the new workspace overview experience. The Projects and Building Blocks tabs are now hidden from the main workspace navigation when you use the new overview, reducing clutter and avoiding redundant navigation options. Instead, you can manage expired project access and project access requests directly under the Access Control section.
Audience: User
When integrating a new platform in the Platform Builder, meshStack now guides you through choosing an integration method. If a Terraform module is available for the selected platform type, we show you a dialog with two options: open the meshStack Hub to integrate using the Terraform module, or configure the platform manually via the UI.
For platform types without a Terraform module, we skip the dialog and take you directly to the manual setup.
]]>This release includes the following issues:
Audience: User
We improved the stability and reliability of the nightly tenant replication process by preventing excessive database load caused by unnecessary updates of the event system.
Audience: User
When you reach the project quota limit for your workspace, the "Create Project" button on the workspace overview now shows a popover explaining why project creation is blocked. Previously, the button was silently disabled with no hint about the reason.
Audience: User
Previously, you could not delete any tenant at the global location from a project. We fixed this so that only the global marketplace tenant is protected from deletion. You can now remove other tenants at the global location, such as AWS or custom platform tenants, just like tenants at any other location.
Audience: User
We removed the console redirect link for AKS tenants. Previously, AKS tenants displayed a sign-in URL that pointed to a non-usable URL. The console redirect is no longer set for AKS tenants.
Audience: User
The Tofu building block runner prepends the directory where the tofu (or legacy terraform) binary is located to the PATH environment variable when the (optional) pre-run script is executed during a building block run. That means you can now simply call tofu or terraform command in your pre-run scripts without resorting to a workaround discovering the binary location first.
Audience: User
We fixed an issue where the Financials dashboard (Admin Area > Organization > Dashboard) continued to show payment method warnings even when payment methods had been disabled in your meshStack configuration. Now, when payment methods are disabled, we no longer display payment method-related alerts or highlight the Financials section as having issues.
Audience: User
Fixed an issue where sign-in information was not properly generated for AWS Accounts when the platform was configured to use the new AWS Identity Store IAM integration method.
Audience: User
We fixed an issue where configuring a building block input with the "Building Block Output" assignment type could result in cryptic errors. meshStack now validates the argument format and provides clear error messages when the configuration is incorrect - for example, when the argument is missing, has an invalid format, or references an output key that does not exist on the parent building block definition.
Audience: User
We added some more calls-to-action (CTAs) for the Platform Builder throughout the Panel if the Platform Builder feature is enabled for a workspace. These CTAs make it easier for users to discover and access the Platform Builder when it is enabled for their workspace.
Audience: User
We redesigned the invitation acceptance page with a clearer visual flow when the "User Invitation Tokens" setting is enabled. You now see distinct loading, success, and error states when accepting an invitation, making it easier to understand what is happening. After successfully accepting an invitation, a "Continue" button lets you proceed to meshStack at your own pace.
Audience: User
When four-eye principle (multi-approval) is enabled in your meshStack instance, the "Add Myself" button in the workspace role mappings interface now proactively prompts you to provide a reason for your access request. Previously, this would fail with a "missing reason" error.
Audience: User
We added two quick-action cards to the platform builder dashboard. You can now navigate directly to building block definitions and platforms from the dashboard, making it faster to get started with creating infrastructure modules or connecting cloud providers.
Audience: User
When creating an API key, the workspace dropdown now includes workspaces you have recently created. You no longer need to refresh the page or re-login to see your new workspace in the list.
Audience: User
We fixed some issues with SSH key and known hosts management when editing a building block implementation. The SSH private key was incorrectly shown as invalid after reloading the implementation tab - it now correctly reflects the saved state. Known hosts are now properly cleared when you switch from a custom SSH repository to a public one. Additionally, empty values for repository path and branch/ref are now correctly treated as absent, preventing building block execution failures caused by blank field submissions.
Audience: User
When editing an existing landing zone, the platform field is now displayed as a read-only text field instead of a disabled dropdown. This makes it clear that the platform cannot be changed after creation and removes any confusion about why the dropdown could not be selected.
]]>This release includes the following issues:
Audience: User
We added a new IAM integration option for AWS platforms: the AWS Identity Store API. meshStack integrates with this API using IAM roles, making it compatible with Workload Identity Federation (WIF), whereas the previous SCIM based API required configuration of a long-lived SCIM bearer token.
In the AWS platform configuration, you can now select "AWS Identity Store API" as the IAM integration type. Configure your Identity Store ID, SSO Instance ARN, group name pattern, sign-in URL, and role mappings. You will need to update your IAM Policies to whitelist additional API calls for the Identity Store. For setup details, refer to the meshStack documentation at https://docs.meshcloud.io/integrations/aws/sso-setup/
Audience: User
When payment methods are disabled in your meshStack setup, moving a tenant to another project that has no payment method set is now correctly allowed. Previously, the migration was incorrectly blocked even though payment methods were not required.
Audience: User
You can now configure an optional pre-run script on your OpenTofu building block definition
versions. This shell script executes after tofu init in the working directory where source files
and tfvars are already in place.
Pre-run scripts can set up secrets, generate provider configurations, or run pre-flight validation checks without modifying your OpenTofu module. The script can be set via meshPanel or the meshObject API, and is limited to 16 KiB.
The run log captures your script's stdout and stderr as a system message.
You can write user messages for this step to a special file via the MESHSTACK_USER_MESSAGE environment variable.
The run mode (APPLY, or DESTROY) is passed as the first argument.
The full meshBuildingBlockRun object JSON is available on stdin, so you can use jq to read any field.
Audience: User
When sorting payment methods by the "Amount Status" column, we now also consider the total consumption when two payment methods have the same usage percentage. This gives you a more consistent and meaningful ordering when reviewing payment method usage.
Audience: User
We've updated the welcome experience in the Platform Builder. The new dashboard greets you with a "Welcome to meshStack" card that gives you a clear starting point: define reusable building blocks, connect cloud platforms, and let your teams self-service the infrastructure they need.
Audience: User
We fixed a race condition that could prevent new users from successfully logging in. Previously, users saw an access denied error on their first login and had to click "Login" again to get in. This is now resolved, so you can log in smoothly on the first attempt.
Audience: User
The "Actions Needed" card on the workspace overview page is now hidden when your workspace has no projects. This keeps the overview clean and avoids showing actions that are not relevant until you have created at least one project.
Audience: User
When you create a new GitHub Actions building block, we now enable the "Pass only API URL" option by default. This
means your workflow receives a buildingBlockRunUrl to fetch building block data from the meshStack API, rather than
the full run object as a workflow input.
This is the recommended approach and protects your workflows from failures caused by large payloads exceeding GitHub's 65KB input limit.
Audience: User
Previously, exporting payment methods to CSV would always download all payment methods, ignoring any search, filters, or sorting you had applied. We fixed this so the CSV export now reflects exactly what you see in the table, including the active filter and the current sort order, making it much easier to export only the payment methods you care about in the order you expect.
Audience: User
The meshLocation API now returns both active and deleted locations. When a location is deleted, it is now
soft-deleted instead of permanently removed, so it remains visible via the API.
Each location response now includes a status.lifecycle field with a state value of either ACTIVE or
DELETED.
This release includes the following issues:
Audience: User
We fixed a bug where removing a user from a workspace could result in an internal error in certain edge cases.
Audience: User
We reverted the recently introduced improvement for tracking GitHub Actions building block runs. The new GitHub API for returning the run ID directly on dispatch is not yet available on private GitHub installations, which caused issues for affected customers. meshStack now uses the previous polling-based approach again to ensure compatibility with all GitHub installations. We will reintroduce the improvement once the new API is available and applied for private GitHub installations as well.
Audience: User
You can now configure an annual price for building blocks in addition to the existing daily and monthly options. An annual fee is charged once per year on the anniversary of the building block's creation date. All other monthly billing periods receive no charge, making it ideal for resources with yearly license costs or annual commitments (e.g. AI platform subscriptions or cloud-provider annual agreements).
To configure an annual price, go to the building block definition in the platform builder, open the General tab, and select Annually from the recurring fee dropdown. Please note that pricing is only supported on tenant-level building blocks, as all usage-reporting is based on projects and chargeback uses the project's associated payment method.
Audience: User
We fixed a bug where building block notifications for failed or succeeded runs were not sent when a runner reported the final run status via the meshObject API. This affected platform operators and building block definition owners who rely on notifications to be alerted when a building block run fails or succeeds.
Audience: User
We fixed two issues with the Azure Subscription Owner Object ID configuration. First, the meshObject API now correctly
accepts null for the subscriptionOwnerObjectIds field. Previously, sending null resulted in a 400 error even
though the API documentation marked the field as optional. Both null and an empty list are now treated as "no
subscription owner configured". Second, the panel now correctly persists the "Do not require a Subscription Owner"
override setting. Previously, this setting could be lost after saving and reloading the platform configuration because
it was derived from the subscription owner list being empty, which was ambiguous.
Audience: User
We improved how the Terraform building block runner handles the meshStack-provided variables
(e.g. meshstack_building_block_run_b64, meshstack_building_block_id). If you have already
defined variable blocks for these in your Terraform configuration, we no longer overwrite them.
In addition, the .auto.tfvars file written by meshStack is now assigned the lowest alphabetical
precedence. Any .auto.tfvars files in your repository load after it and can override the
meshStack-provided values, following standard Terraform variable precedence rules.
Audience: User
We have removed the Cloud Universe feature from meshStack. The Cloud Universe was a read-only graph visualization of meshStack entities (users, groups, workspaces, projects, and tenants) accessible via the admin "Cloud Foundation" tab. It has been removed as part of our ongoing effort to streamline the product and focus on features that provide the most value to our users.
Audience: User
We fixed a bug where aborting a building block run could cause runners to receive an unexpected HTTP 500 error
instead of the correct response indicating the run was aborted.
If you are using custom runners or have built automated pipelines that integrate via the building block run API,
this fix ensures your runners now reliably receive the correct runAborted: true response and can handle
the abort gracefully.
Audience: User
The spec.symbol field on building block definitions now validates that the value is a safe image URI.
Valid values are inline image data URIs using PNG, JPEG, GIF, or WebP formats (e.g.,
data:image/png;base64,...) or an http(s):// URL pointing to an image. SVG data URIs and other
non-image data URIs are no longer accepted, as they could pose a cross-site scripting (XSS) risk.
If you use Terraform or another API client to manage building block definitions with a custom symbol,
please ensure your symbol value uses one of the supported formats above.
Audience: User
When a tenant was moved to a different workspace, the old platform groups (tied to the previous workspace) could get stuck and never be cleaned up on GCP, OpenStack, AWS and Azure. This happened when the platform was temporarily slow to respond during replication and required manual cleanup. We fixed this so that meshStack now always preserves the old group metadata across failed replication attempts, ensuring the cleanup of stale groups is retried successfully on the next replication cycle.
Audience: User
We fixed a bug where building block runs could get stuck or fail unexpectedly when jobs failed to execute (e.g. due to node pressure or resource constraints). In those cases, the retried job would report an incorrect status back to meshStack. The run would then appear failed or stuck without a clear reason.
Audience: User
We improved the internal architecture of marketplace service instances to better support multiple marketplaces per location. As part of this change, we removed the deprecated tenant-aware service support from the user interface. This change resolves issues that previously occurred when configuring multiple Open Service Broker (OSB) marketplaces within the same location.
Audience: User
We optimized how building blocks are triggered for execution. Building blocks are now grouped by workspace before triggering, which reduces unnecessary processing and improves overall performance when updating multiple building blocks. Additionally, we improved the event attribution in the building block audit trail.
]]>This release includes the following issues:
Audience: User
We improved the back navigation in the building block control plane. The "Go back" button now consistently navigates you to the corresponding building block definition, instead of attempting to navigate to the previously visited overview page. This makes the navigation more predictable and reliable, regardless of how you reached the control plane (e.g. via deep link, page refresh, or navigating between tabs).
Audience: User
GitHub recently added API support for returning the run ID directly when dispatching a workflow. We updated our GitHub Actions building block runner to take advantage of this. Previously, meshStack had to poll and guess which run was triggered based on timestamps, which could lead to incorrect run tracking in rare cases. meshStack now receives the run ID directly from GitHub, ensuring the correct run is always tracked and monitored.
Audience: User
We fixed a bug where releasing a new version of a building block definition was incorrectly flagging the selectable values input field as changed when moving from a null to an empty list, or vice versa. To prevent that it is no longer allow to define an empty list of selectable values. The field must now be set to null if there are no selectable values.
Audience: User
We fixed an issue where the cancel button in the communication creation dialog did not work correctly. Previously, clicking "Cancel" could fail to close the dialog. You can now reliably dismiss the dialog using the cancel button at any point during communication creation.
Audience: User
We fixed a bug where workspace and project deletion could get stuck when removing role bindings from a workspace or project failed with an internal error. If you experienced stuck workspace or project deletions, they will now proceed successfully.
Audience: User
We improved the group search in the access control screens so that exact name matches are now prioritised correctly. This makes it easier to find and add groups, especially when multiple groups share similar names.
Audience: User
We introduced Access Control V2 as a feature preview. You can now try the new access control experience on workspace, project, and admin access pages by opting in via the "Try New Experience" toggle on those pages. Access Control V2 brings a redesigned interface for managing role mappings and permissions. The feature will gradually roll out and eventually replace the current access control experience.
If your meshStack previously had Access Control V2 enforced, it will remain enforced with no option to toggle back. For all other instances, users can try the new experience via the toggle and opt out if needed. The feature will gradually roll out and become mandatory for all instances.
Audience: User
We fixed an issue where building block runners would incorrectly show an error in their activity status, even though the runners were working correctly. The runner activity tracking now properly updates the last seen timestamp.
Audience: User
We improved the error handling when a OpenTofu runner fails to parse a incorrect backend.tf file during Terraform based building block execution.
Audience: User
We fixed an issue where run tokens, which are provided to building block runners, lacked sufficient permissions to fetch their own building block runs. This previously prevented runners from checking the current state of their runs via the meshObject API. Run tokens now include the necessary permissions to retrieve building block run information.
Audience: User
We fixed an issue where fetching terminated building block runs (e.g., runs with status SUCCEEDED, FAILED, or ABORTED) via the meshObject API resulted in an HTTP 500 error. The API now gracefully handles these cases by returning a placeholder value for the run token field, allowing you to successfully retrieve information about terminated building block runs without errors.
Audience: User
You can now update the "Only Apply Once per Tenant" setting for building block definitions that are still in their initial draft state. Previously, this setting could only be configured during initial creation and could not be changed afterward, even for drafts.
Audience: User
When releasing a building block definition draft version without requiring admin approval, the publication state is now correctly updated to "Published". Previously, the publication state remained unchanged even though the version was successfully released, which could caused an inconsistent view in the panel.
Audience: User
We improved the handling of building block executions by optimizing database queries. This increases stability for building block executions from workspaces and projects with a lot of building blocks attached.
]]>This release includes the following issues:
Audience: User
The meshLocation API now requires specifying which workspace owns a location. This change makes location ownership explicit and enables workspace-scoped users to manage locations within their own workspace. Previously, only administrators could create and manage locations.
Audience: User
The meshObject APIs for meshPlatform (v2), meshLandingZone (v1), meshLocation (v1), meshPlatformType (v1), and meshIntegration (v1) have been promoted from preview to General Availability (GA). These APIs are now considered stable and ready for production use. Breaking changes will follow the standard versioning process for GA APIs.
Clients can temporarily continue using the preview media types like
application/vnd.meshcloud.api.meshplatform.v2-preview.hal+json for backward compatibility. But this preview version
will be removed according to the deprecation policy, so clients are encouraged to switch to the GA media types.
If you keep using a preview Content-Type header, you must also keep sending the matching preview value in the apiVersion
field of request bodies (for example, v2-preview). Requests that mix a preview Content-Type header with a GA apiVersion
(for example, v2) will fail validation.
To adopt the GA versions, update your API client's Accept and Content-Type headers to use the GA media types without
the -preview suffix (for example, application/vnd.meshcloud.api.meshplatform.v2.hal+json), and update the apiVersion
field in request bodies to the matching GA version (for example, v2).
Audience: User
We polished the building block definition editor to make it more reliable and less error-prone. The improved implementation better handles edge cases when updating configuration sections like general information, implementation details, dependencies, inputs, outputs, and tags.
Audience: User
The meshServiceInstance API now documents the optional parameters on the spec of a service instances. These parameters are forwarded to the Service Broker during provisioning or update operations and the last known values are returned when fetching the service instance. The field was already supported before, but documentation was missing.
Audience: User
We fixed an issue where clicking the "Create New Communication" button from the Platform Builder area (e.g. from workspaces, building block definitions, or platform instances) caused an error and prevented the communication creation dialog from opening. The button now works correctly across all areas of meshPanel.
Audience: User
Platform Builder permissions are now excluded from the available permissions when creating or editing building block definitions. These permissions allow platform teams to manage resources in other workspaces and are not suitable for building blocks running in workspace context.
Building block definitions can now only use workspace-level permissions, ensuring they operate within the appropriate authorization boundaries.
If your existing building block definitions already have Platform Builder permissions assigned, they will remain. However, you cannot add new Platform Builder permissions to building block definitions going forward.
Audience: User
Fixed an issue where platform tags displayed in the tenant details page did not refresh automatically when triggering a manual tenant replication. Previously, you had to reload the entire page to see updated tag values after replication completed. Now, the platform tags update automatically when the replication finishes, providing immediate feedback on tag changes.
Audience: User
We fixed an issue that could cause a 500 error when creating or updating landing zones through the meshPanel.
Audience: User
We fixed an issue where building block dependencies were not displayed correctly when working with draft versions of building block definitions. Previously, the system always queried the latest published version when determining dependencies, which caused confusion and incorrect dependency information during building block configuration. Now, when you configure a building block based on a draft version, you will see the accurate dependencies specific to that draft version. Additionally, we improved the building block configuration dialog to provide a more reliable and maintainable user experience.
Audience: User
You can now select and remove multiple users or groups from workspace and project access lists in a single action in the new access control interface (access control v2).
Note: This change only affects customers who have access to the new access control v2 feature. If you are using the standard access control interface, you already have this capability.
]]>This release includes the following issues:
Audience: User
We fixed an issue where @buildingblock, @project, and @tenant mentions in building block summary markdown were displayed as escaped HTML text instead of rendered elements. Mentions now correctly display as interactive badges that load and show the referenced resource information.
Audience: User
Building block definitions using Azure DevOps Pipelines now support ephemeral API keys when you configure permissions on the building block definition. This enables building blocks to interact with meshStack programmatically without requiring manually managed credentials.
When you create or edit a building block definition using Azure DevOps Pipeline implementation and select one or more permissions, meshStack automatically generates a workspace-scoped API key and provides it as the MESHSTACK_API_TOKEN pipeline variable. Your Azure DevOps Pipeline can use this token to authenticate API requests to meshStack.
Additionally, if you enable asynchronous execution mode for your building block definition, meshStack also provides MESHSTACK_RUN_URL and MESHSTACK_RUN_TOKEN as pipeline variables. These allow your Azure DevOps Pipeline to report status updates and results back to meshStack for the specific building block run.
The ephemeral API keys are automatically managed by meshStack - they are created when the building block run starts and have limited scope to ensure security. You don't need to manually create or manage any API keys.
Audience: User
We now validate currency codes when importing resource usage reports via the meshResourceUsageReport API. Only valid ISO 4217 currency codes (such as USD, EUR, GBP) are accepted. If you submit a usage report with an invalid currency code, the API will return a clear error message indicating which currency code is invalid. This validation prevents data inconsistencies in your billing and chargeback data, ensuring that all financial information uses standardized currency codes.
When importing resource usage reports, make sure all line items use valid ISO 4217 currency codes. If you receive an error about an invalid currency code, check the currency field in your usage report and correct it to use a standard three-letter currency code like USD, EUR, or GBP.
Audience: User
We strengthened security by preventing changes to the sensitivity setting of existing building block definition inputs. Once an input is marked as sensitive (encrypted), it cannot be downgraded to non-sensitive for security reasons. The sensitivity toggle in the building block definition editor is now automatically disabled for existing inputs to clearly indicate that this setting cannot be changed.
Audience: User
Building block definitions using GitHub Actions now support ephemeral API keys when you configure permissions on the building block definition. When using the "Pass only API URL" mode, the API token is automatically provided as a workflow input variable (MESHSTACK_API_TOKEN), allowing your GitHub Action workflows to authenticate with the meshStack API securely. This enables building blocks to interact with meshStack programmatically without requiring manually managed credentials.
When you create or edit a building block definition using GitHub Actions implementation and select one or more permissions, meshStack automatically generates a workspace-scoped API key and provides it as the MESHSTACK_API_TOKEN workflow input. Your GitHub Action workflow can use this token to authenticate API requests to meshStack.
Additionally, if you enable asynchronous execution mode for your building block definition, meshStack also provides MESHSTACK_RUN_URL and MESHSTACK_RUN_TOKEN as workflow inputs. These allow your GitHub Action workflow to report status updates and results back to meshStack for the specific building block run.
The ephemeral API keys are automatically managed by meshStack - they are created when the building block run starts and have limited scope to ensure security. You don't need to manually create or manage any API keys.
Audience: User
Asynchronous building block definitions now automatically receive two new system-generated inputs: MESHSTACK_RUN_URL and MESHSTACK_RUN_TOKEN. These inputs enable building block implementations to report status updates and results back to meshStack using the meshObject API without the need of finding the right URL manually and creating an admin scoped API key. This makes updating the run status and results more secure and easier, especially for building block implementations running outside of meshStack (e.g., GitHub Actions, Azure DevOps, or OpenTofu with async enabled).
Use the MESHSTACK_RUN_URL and MESHSTACK_RUN_TOKEN environment variables in your async building block implementations to report status and results. For example, in a GitHub workflow or Azure DevOps pipeline, POST to the run URL with the token to update the run status. These variables are automatically available when async mode is enabled. Existing asynchronous building block definitions will receive these inputs upon the next update to their implementation settings.
Audience: User
The meshObject API now consistently provides lifecycle information (such as creation and deletion
timestamps) in the status.lifecycle section instead of the metadata section. This change affects
meshPlatform, meshPlatformType, and meshIntegration objects. The API now follows a clearer separation
of concerns: metadata contains identifiers and ownership information, while status contains runtime
state and lifecycle information.
Audience: User
We fixed an issue where existing Azure groups could not be correctly imported into an administrative unit (AU). The fix also adds better error handling and reporting for edge cases like missing or duplicate groups.
Audience: User
We improved the API for Building Block Definition Versions so you can manage permissions for ephemeral API keys that are used when running Building Blocks based on a specific Building Block Definition Version. Furthermore, we added lifecycle information to the status subsection of Building Block Definition Versions.
Audience: User
If your organization has enabled 4EyePrinciple, you will now be prompted to provide a reason when adding or editing user access to workspaces and projects. This approval workflow (also known as the 4-eye principle) ensures that access changes are reviewed and authorized by multiple people for better security and governance. When 4EyePrinciple is enabled, a "Reason" field automatically appears in the add and edit user forms, requiring you to explain why the access change is needed. Your request will then need to be approved by a workspace or project owner before the access change takes effect. This works for both adding individual users and adding multiple users at once, where a single reason applies to all users being added. If approval requirements are not enabled for your organization, users are added or edited immediately without requiring a reason.
Note: This change only affects customers who have access to the new access control v2 feature. If you are using the standard access control interface, this change does not apply to you.
Audience: User
Fixed a bug where building block run updates could be lost when a late update from the coordinator arrived shortly after a runner had already registered its execution status. This could lead into seemingly stuck building blocks.
Audience: User
Building block definition permissions (ephemeral API keys) are now correctly preserved when creating draft versions from published versions. Previously, these permissions were silently lost during the draft creation process, requiring manual reconfiguration.
Audience: User
Building block definition inputs now require unique input keys. When creating or editing building block definitions, the system validates that no two inputs share the same key, both in the panel and via the API. This prevents configuration errors and ensures clear, unambiguous input references.
Audience: User
We improved the way you manage secrets (like SSH private keys) when configuring building block definitions. The new implementation now properly handles secret data using a secure embedded format, ensuring that existing secrets are preserved when you update other properties without re-uploading them.
When editing a building block definition with Terraform implementation, you can now see a clear indication when an existing SSH private key is configured (displayed as "*****"). You only need to upload a new key if you want to change it - otherwise, the existing key will be preserved automatically. This makes it easier and safer to update other implementation settings without accidentally removing or exposing sensitive credentials.
Audience: User
The meshIntegration API now uses an improved secret handling approach for integration secrets like GitHub App private keys and Azure DevOps personal access tokens. Previously, GET responses returned a placeholder value for secrets, which made it impossible to detect configuration drift. Now, secrets are returned with a hash value that enables drift detection while maintaining security by never exposing actual secret values. This uses the same concept as meshPlatform configurations and building block definitions. This is a breaking change, so existing API clients need to adapt to the new secret representation structure.
Audience: User
We have redesigned the API Key permission selection experience to make it much easier for you to browse and pick the right permissions for your Workspace or Admin API keys. The new interface groups permissions more clearly and provides helpful descriptions, so you can confidently select the access you need. This update also applies to the recently introduced ephemeral API keys for Building Block Definitions, making it simple to grant just the right permissions for automation and integration scenarios.
When creating or editing an API key, you will now see a new permission selection dialog. Permissions are grouped by category, and you can expand each group to learn more about what each permission allows. For ephemeral API keys used in Building Block Definitions, you can quickly select only the permissions required for your automation. This helps you follow the principle of least privilege and improves security for your integrations.
]]>This release includes the following issues:
Audience: User
We fixed an issue in the Terraform building block runner where SINGLE_SELECT and MULTI_SELECT input values were not correctly processed when passed as Terraform variables. This caused Terraform execution errors when using these input types in building block definitions.
]]>