Release 2026.30.0
Release period: 2026-07-23 to 2026-07-29
This release includes the following issues:
- Fix meshObject API Consistency for Discovering Available Landing Zones
- Require Approval Before Applying Building Block Changes
- Automatically Detect or Fix Building Block Drift on a Schedule
- Copy Building Block Values and Workspace Identifiers With One Click
- No More Stray Whitespace When You Copy or Paste in the Panel
- Project Access Now Lasts Through the Whole Expiry Date
- No More Bogus Output Validation Errors on Building Block Deletion
- Fixed meshStack Copilot Returning an Error Instead of an Answer
- Status and Action Column and Live Updates in the Building Block List
- meshTenant Enforces Quota Limits
- Fix Batched Notification Emails Losing Entries
- Hide Projects with Expired Access from Workspace Overview
- Adapt Building Block Notification Links To Use Current Panel Filters
- Building Block Notification Emails Now Link to the Right Building Block Overview
- Building Block Runs Keep Their Creation Trigger Reason
- Fix Error When Changing Quota Key Casing on a Platform
- Audit Log Entry When Tenant Replication Fails
- New Tenants Tab in the Platform Control Plane
- Clear Error When an Input Key Clashes With a Reserved System Key
- Clearer Building Block Run Labels and Run Type Filtering
- Building Block Outputs Now Respect the Configured Display Order
- Deleted Tenants Are Now Part of the Tenants Screen
- Fixed Incorrect List Item Rendering in the meshObject API Documentation
- Building Block Runs: Clearer Trigger Button While a Run Is Waiting
- Workspace Bindings API Now Exposes and Accepts an Expiry Date
- Filter Platforms by Type in the API
- Discover Landing Zones of Platforms Published to You via the API
- Discover Platforms Published to Your Workspace via the API
Ticket Details
Fix meshObject API Consistency for Discovering Available Landing Zones
Audience: User
Description
We fixed two issues when querying the meshLandingZone endpoints as an application team workspace that doesn't own
that Landing Zone. You can now also read individual landing zones that were returned by the list endpoint and the
API now consistently removes the spec.platformProperties field from responses.
Require Approval Before Applying Building Block Changes
Audience: User
Description
You can now require a human review before specific Building Block changes are applied. On a Building Block Definition's Policies tab, choose which causes need approval - Building Block creation, a version upgrade, user input changes, manual triggers, or any input change. When an enabled cause applies to a run, meshStack plans the change first and holds it in Waiting for Approval status instead of applying it right away. An admin, or the platform team that owns the definition, reviews the plan and approves or rejects it before anything is applied. This feature currently supports the OpenTofu implementation type and is labeled Beta in the Panel.
How to use
Open the Building Block Definition's Policies tab and toggle on the causes that should hold a run for approval in the Run Approvals section. Once a run is held, approve or reject it from its details page in the Runs tab. The definition's notification subscribers get an email once a run needs approval - these are batched and sent out at most every 15 minutes, so multiple approvals don't flood your inbox with separate mails. You can also see everything waiting for you at a glance: pending approvals show up as "Building Blocks requiring approval" under Actions Needed in the Admin Area, and you can filter the Building Block overview by the "Review Approval" action to find every Building Block currently waiting for one.
Automatically Detect or Fix Building Block Drift on a Schedule
Audience: User
Description
meshStack can now periodically check whether a Building Block's real resource state still matches its configuration, without anyone triggering a run manually. On the Building Block Definition's Policies tab, choose "Detect drift only" to have meshStack run a scheduled dry run and record whether it found drift, or "Detect and fix drift" to also apply the fix - either held for approval or applied automatically. Both modes run on a daily or weekly frequency you choose. Detecting drift, or fixing it with approval, requires the OpenTofu implementation type; fixing drift fully automatically also works for GitHub Actions, GitLab CI/CD, and Azure DevOps Pipelines building blocks.
How to use
Open the Building Block Definition's Policies tab and pick a mode in the Drift Detection & Schedule section, then choose Daily or Weekly. Check the Runs tab, or filter the Building Block list by the "Review Drift" action, to see what a scheduled run found.
Copy Building Block Values and Workspace Identifiers With One Click
Audience: User
Description
Building Block inputs and outputs now have a copy button next to their value, and so does the identifier column in the Admin Area workspace list. One click puts the exact value on your clipboard, so you no longer have to select a resource id or a portal URL by hand.
Sensitive inputs show no copy button, because only their mask would end up on your clipboard. A sensitive input whose value happens to look like a URL is no longer rendered as a link either, which previously pointed at the mask instead of the value.
No More Stray Whitespace When You Copy or Paste in the Panel
Audience: User
Description
Copying a value out of the Panel no longer picks up a leading and trailing space. Selecting an identifier, a Building Block output or a table cell and copying it now gives you exactly the value, so it works straight away in a terminal, a cloud portal or a Terraform file, where a stray space breaks things.
Pasting into a Panel input field now strips surrounding whitespace too. A padded value pasted into a search field finds what you expect instead of coming up empty.
How to use
There is nothing to configure, just copy and paste as you always have. Copy buttons already copied the exact value and keep working unchanged. Values you copy out of the code editor or out of a preformatted block, such as a list or file Building Block value, are untouched, so indentation in policies and configuration files stays intact.
Project Access Now Lasts Through the Whole Expiry Date
Audience: User
Description
A project role binding now keeps granting access for the entire day it expires on, instead of ending at midnight going into that day. Previously the project disappeared from your project list, project switcher, workspace search and building block searches one day earlier than the expiry date shown to you, even though the binding was still listed as active. Opening the project directly still worked on that day, so the same role produced two different answers depending on where you looked.
No More Bogus Output Validation Errors on Building Block Deletion
Audience: User
Description
When you deleted a Terraform or OpenTofu Building Block, the run details showed a failed "meshStack Validation" step claiming the declared outputs were missing, even though the run itself succeeded. A destroy run tears the resources down, so its outputs no longer exist and are never reported back. We now skip output validation for destroy runs, so a successful deletion no longer shows a misleading validation failure.
Fixed meshStack Copilot Returning an Error Instead of an Answer
Audience: User
Description
meshStack Copilot answers your questions with the help of an external AI model. That model reached its end of life and the provider retired it, so Copilot could no longer reach a working model and returned an error for every question we sent it. We moved Copilot to the current model generation, and it answers your questions again.
How to use
No action is needed on your part. Once your meshStack is updated, just open Copilot and ask as usual. Questions that ran into the error were saved to your conversation but never answered - simply ask them again to get an answer.
Status and Action Column and Live Updates in the Building Block List
Audience: User
Description
The Building Block list now separates the status of a Building Block from the work it currently requires. A dedicated Status column shows at a glance whether the latest apply or destroy run of a Building Block succeeded, failed, or deleted its resources, along with how long ago that latest run started. The former status column is replaced by an action column that tells you what to do next (provide input, review errors, or upgrade to the latest Building Block Definition version) and links straight to where you can act on it. You can also filter the list by status and by required action.
The action column also reflects dry runs: a pending or running dry run shows up as "Dry run #N", and a failed dry run surfaces as "Review Errors" - without the dry run affecting the Building Block's status or health. A succeeded dry run that detected drift surfaces as "Review Drift", so you can spot Building Blocks whose real state has diverged from their definition. You can also filter the list by this action.
As long as a Building Block has a run that has not finished yet, its Status and Action values reload on their own, so you no longer have to hit refresh to find out whether the run finished. Your scroll position, selection, sorting and filters stay exactly as they are.
meshTenant Enforces Quota Limits
Audience: User
Description
When you create a Tenant through the meshObject API, for example with the Terraform provider, meshStack now enforces the same quota guardrails as the Panel. Requested quotas must stay within the minimum and maximum defined for each quota on the Platform, and quotas above a quota's auto-approval threshold are no longer applied silently. Admin API keys may still set values above the threshold, since they also define those limits, while other API keys should request such increases through the Panel so a Platform operator can approve them.
Note that a quota's auto-approval threshold defaults to 0. On a Platform where it has not been raised, the API therefore only accepts quota values at or below the Landing Zone's default for that quota. To let API clients request higher values directly, set an auto-approval threshold on the Platform's quota definition.
The v4 meshTenant also improves how quotas are represented. You can now request quotas as a map keyed by quota key, which is easier to work with than the previous list of entries, and you can read back the quotas meshStack actually applied. The previous list format still works but is now deprecated, so you have time to switch, for example to update your Terraform provider. If a request uses both formats, they must describe the same quotas, otherwise the request is rejected.
Fix Batched Notification Emails Losing Entries
Audience: User
Description
Batched notification emails now list every affected entity instead of only the most recent one. Previously, when several entities shared a notification scope, a newer notification replaced the older one before the email went out. If two of your building blocks needed attention within the same batching window, the email only mentioned one of them. This affected emails about building blocks that failed, that wait for your input, that wait for your approval, and that completed successfully, as well as emails about failed tenant replications.
Hide Projects with Expired Access from Workspace Overview
Audience: User
Description
The workspace overview no longer shows a project after a user's project role binding expired. Previously, the project was still visible, even though meshStack had already revoked the user's access and triggered replication of the revoked permissions to building blocks and cloud tenants. The project also drops out of the user's project list and project switcher and stops counting towards the number of projects reported for them on the workspace.
Adapt Building Block Notification Links To Use Current Panel Filters
Audience: User
Description
Email notifications about building blocks (failed runs, runs waiting for your input, and runs waiting for approval) now open the building block overview pre-filtered by the same action or health status filters shown in the panel today. Previously these links relied on a status filter the panel no longer exposes, so opening them no longer narrowed down the list for you.
Building Block Notification Emails Now Link to the Right Building Block Overview
Audience: User
Description
Email notifications about building blocks (failed runs, runs waiting for your input, and runs waiting for approval) now link to the building block overview of the area the building block definition is managed in: the owning workspace's service management area for workspace-owned definitions, and the administration console for definitions owned by a partner workspace. Previously, the link always pointed to the administration console, which platform builders without administration access could not open.
Building Block Runs Keep Their Creation Trigger Reason
Audience: User
Description
The first run of a Building Block could occasionally show a later trigger reason (e.g. a permission change) instead of "Building Block Creation" when result messages were processed out of order. We fixed this: the creation trigger is now preserved even when the creation result arrives late, so you can reliably see why a run originally came to exist.
Fix Error When Changing Quota Key Casing on a Platform
Audience: User
Description
Updating a Platform through the meshObject API now correctly applies a quota key change that only differs in casing (for example "cpu" to "CPU") or accents as an in-place update of the existing quota definition. Previously, such a request unexpectedly failed with an internal server error, because quota keys that differ only in casing or accents are treated as the same key. A request that lists two quota keys differing only in casing now returns a clear validation error instead of a server error.
Audit Log Entry When Tenant Replication Fails
Audience: User
Description
We now write an event log entry whenever a Tenant's replication starts to fail, so you can see failures in the Tenant's audit log instead of only through replication status and metrics. To keep the log readable, we record only the first failure in a chain: replication is retried continuously, so a Tenant that stays broken no longer floods the log with a duplicate entry on every attempt. A new entry is written again once the Tenant fails after a successful or first-ever replication.
New Tenants Tab in the Platform Control Plane
Audience: User
Description
The Platform Control Plane now has a Tenants tab that lists all Tenants running on the current Platform. You see the same rich Tenant list you already know from the Tenants overview - replication status, workspace and project hierarchy, Building Blocks and pending actions - but scoped to just this Platform. This makes it easy to review the Tenants of a single Platform without leaving its Control Plane.
Clear Error When an Input Key Clashes With a Reserved System Key
Audience: User
Description
When you create or edit a Building Block Definition, meshStack automatically adds reserved system inputs such as MESHSTACK_ENDPOINT and MESHSTACK_API_TOKEN. If one of your own input keys matched a reserved key, even when it only differed in capitalisation like meshstack_endpoint, the save failed with a confusing internal error.
You now get a clear message telling you the key is reserved, both directly in the Panel form as you type and when saving. We also detect duplicate input keys that differ only in case, matching how meshStack stores them.
Clearer Building Block Run Labels and Run Type Filtering
Audience: User
Description
We reworked how we label Building Block runs in the run control plane. The run number now comes first, followed by what the run actually does: Dry Run, Apply, Destroy, or Purge. This makes the runs list quicker to scan and tells apart a run that only plans changes from one that applies or removes resources at a glance. A Destroy run tears down the resources of a regular deletion, while a Purge run is the follow-up that removes the Building Block from meshStack. The run detail header uses the same order and keeps a trailing "Run" (for example "#123 Apply Run").
The runs list filter also matches this: you can filter for Apply, Destroy, and Purge runs separately, instead of only for a combined "Run".
Building Block Outputs Now Respect the Configured Display Order
Audience: User
Description
When you configure a display order for the outputs of a Building Block Definition, we now show those outputs in that exact order on the Building Block detail page and in the resource links on the Building Block card. Previously these two views ignored the configured order and listed outputs in the order they happened to be produced, so reordering them had no visible effect there. This gives you full, consistent control over how outputs appear to your users.
Deleted Tenants Are Now Part of the Tenants Screen
Audience: User
Description
Deleted tenants now show up directly in the Tenants screen of the admin area and the platform builder with their own "Deleted" status. You can filter for them via the status filter, and you can approve or decline pending tenant deletion requests right from the list. The separate "Deleted Tenants" view is retired; its sidebar entry now guides you to the new location.
Fixed Incorrect List Item Rendering in the meshObject API Documentation
Audience: User
Description
List endpoints in the meshObject API documentation (such as projects, tenants, workspaces, building blocks and communications) rendered the items of a paged response as a confusing mix of every possible type, and the generated examples were invalid. Each list item now documents its full set of fields, just like the corresponding single-object endpoint.
Building Block Runs: Clearer Trigger Button While a Run Is Waiting
Audience: User
Description
On the Runs tab of a Building Block, the Trigger Run button no longer shows a spinning loader while the latest run is parked in a waiting state, such as waiting for dependency. A spinner suggested work was happening when the run was actually paused. The button now shows the icon and a tooltip of that waiting status instead and stays disabled, so you can see at a glance why a new run cannot be started yet.
Workspace Bindings API Now Exposes and Accepts an Expiry Date
Audience: User
Description
The meshObject API for workspace user bindings and workspace group bindings now includes the expiry date of a binding. When you read a binding, you can see when its role assignment expires. When you create a binding, you can set an expiry date directly.
Filter Platforms by Type in the API
Audience: User
Description
The meshPlatform list API now supports a platformTypeIdentifier filter so you can list only platforms of a
given platform type through the API, making it easy to find compatible platforms of a specific type.
Discover Landing Zones of Platforms Published to You via the API
Audience: User
Description
The meshLandingZone API now also returns the Landing Zones of platforms another workspace has published to yours, so an API key with read access can resolve a compatible Landing Zone for a published Platform through the API, not just for platforms you own or contribute to.
Discover Platforms Published to Your Workspace via the API
Audience: User
Description
The meshPlatform API now also returns platforms another workspace has published to yours, not just those you own or contribute to, so an API key with read access can discover and reference them instead of hard-coding a UUID. When you only consume a published platform its technical connection configuration is omitted (the owning workspace and admins still receive it); secrets are always returned as hashes.