Skip to main content

Release 2026.35.0

· 10 min read
meshcloud

Release period: 2026-08-19 to 2026-08-26

This release includes the following issues:

  • New Actions Needed card for Payment Methods budget
  • Clearer Errors When a Building Block Run Cannot Be Executed
  • Fewer Sporadic Building Block Run Failures Under High Load
  • A Separate Name Template for Building Blocks
  • Parallel meshObject Writes No Longer Fail With an Internal Error
  • Fixed Intermittent 403 When a Composition Updates a Child Building Block
  • Policy Violation Errors Now Name the Policy That Failed
  • Organization Users Can Now View Global Groups in the Admin Area
  • Clearer Error When You Assign a Non-Workspace User or Group to a Project
  • Workspace Members Can Order Building Blocks That Read Workspace Data
  • Boolean Inputs Now Show as a Toggle in Building Block Upgrade and Run Forms
  • Preview What Workspace Users See When Ordering a Building Block
  • SBOM Now Published in CycloneDX Format
  • Only the Building Block Definition Owner or an Admin Can Approve a Run
  • Consistent Empty State in the Building Block List
  • API Key Expiration Is Now Preselected
  • GitHub Platforms Are Now Custom Platforms
  • Platform Builder Overview Only Shows Active Platforms
  • Recently Run Building Blocks on the Platform Builder Overview

Ticket Details​

New Actions Needed card for Payment Methods budget​

Audience: User

Description​

Your Workspace Overview now shows a Budget card in the Actions Needed section. It totals the consumed and remaining budget across all of your active payment methods and shows a colored badge for the remaining amount (green when you're within budget, yellow when you're close, red once you're over), so you can see at a glance how you're doing without opening each payment method individually.

Clearer Errors When a Building Block Run Cannot Be Executed​

Audience: User

Description​

When something goes wrong inside meshStack while a building block run is being executed, the error you get back now says what actually happened. Some of these failures previously came back without any message, which made a temporary internal problem look like the run had been aborted. A run could then keep showing as in progress long after its work had finished.

How to use​

You do not need to change anything to benefit from this. Every one of these errors now carries a message and an error id you can quote to us in a support request.

If you run your own building block runner, be aware that a few of these failures now report a different HTTP status code than before. A runner that treats any failed call as fatal is unaffected. If yours reacts to specific status codes, please review that logic.

Fewer Sporadic Building Block Run Failures Under High Load​

Audience: User

Description​

We significantly reduced sporadic failures of Building Block runs that could happen when many runs were executed at the same time. A run was reported as failed even though nothing was wrong with your Building Block or the platform it targets, and you had to trigger it again. This is now much less likely, and we are working on removing the remaining cases.

A Separate Name Template for Building Blocks​

Audience: User

Description​

A building block definition now has its own name template, separate from the definition name. Until now the only way to name a new building block after its inputs was to put placeholders such as {{ repoName }} into the definition name itself, and those raw placeholders then showed up everywhere we display a definition name: the marketplace catalogue, the definitions table, and the detail page of every building block. You can now give the definition a clean name and still have each new building block named after the values it was ordered with.

Parallel meshObject Writes No Longer Fail With an Internal Error​

Audience: User

Description​

We fixed a database deadlock that could make a meshObject write fail with an internal server error when several writes arrived at the same moment. Destroying a Building Block was the most likely way to run into it, because OpenTofu deletes independent resources in parallel. Those writes now all succeed.

Fixed Intermittent 403 When a Composition Updates a Child Building Block​

Audience: User

Description​

If you use a composition (a building block such as a starter kit that manages other building blocks), its run could occasionally be denied with a 403 when it changed the building block definition version of one of its children, even though nothing about your permissions had changed. Running the building block again cleared it. We fixed the race behind this, so a composition now keeps its elevated access for the whole run and these runs no longer fail for this reason.

Policy Violation Errors Now Name the Policy That Failed​

Audience: User

Description​

When a policy blocks what you are doing, the error now tells you which policy it was, which tag values were compared, and what the policy says about fixing it. Before, some of these errors said only how many policies had failed, which left you with a number and no way to act on it.

You get this wherever the policy check runs, including places that previously lost the detail: creating a tenant, where the landing zone's mandatory building blocks are validated, and any error surfaced through the meshObject API or the Terraform provider. The same detail now also reaches our logs, so we can help you faster when you ask.

Organization Users Can Now View Global Groups in the Admin Area​

Audience: User

Description​

As an Organization User, you can now open the read-only Global Groups view in the admin area, matching the documented scope of your role. We also fixed the details view of a global group, which previously showed an error for Compliance Managers even though they could see the list.

Clearer Error When You Assign a Non-Workspace User or Group to a Project​

Audience: User

Description​

When you assign a user or group to a project through the meshObject API, that user or group must already be assigned to the owning workspace. We used to report a missing workspace assignment as an internal error. You now get a clear message that names the user or group and tells you it is not assigned to the workspace, so you can correct the request instead of retrying it.

Workspace Members Can Order Building Blocks That Read Workspace Data​

Audience: User

Description​

Ordering a Building Block used to fail for workspace members whenever the Building Block Definition declared the permissions its run needs to read data about your workspace. Only Workspace Owners and Managers held those permissions, so the developers who actually order Building Blocks got a "missing permissions" error.

Workspace members can now read more of their own workspace: its user groups and its workspace role bindings, plus the role bindings of the projects they are assigned to. Their read access to Building Blocks and tenants stays limited to the projects they are assigned to, and it now satisfies a definition version that declares the workspace-level read permission. A definition version that declares only these read permissions is therefore orderable by every member of the workspace. Permissions that write data still require a Workspace Owner or Manager, so a definition that declares one keeps being orderable by them only.

A definition version can no longer declare a project-scoped permission such as PROJECT_BUILDINGBLOCK_LIST, PROJECT_TENANT_LIST or PROJECT_PROJECTPRINCIPALROLE_LIST, because a Building Block run's ephemeral API key cannot belong to a project. Declare the workspace-level permission instead. Versions that already declare one keep it and stay editable.

We also renamed the right to read the tenants of a project from TENANT_LIST_PROJECT to PROJECT_TENANT_LIST, so that every project-scoped right spells its scope the same way. The update renames the right in place, so every workspace role, every Building Block Definition version and every API key that holds it keeps it. If you assign API key permissions through the meshObject API or Terraform, replace the old name in your configuration: a request that still sends TENANT_LIST_PROJECT is rejected.

Boolean Inputs Now Show as a Toggle in Building Block Upgrade and Run Forms​

Audience: User

Description​

When upgrading a Building Block or configuring the inputs for a new run, a boolean input used to show as a dropdown with "true" and "false" as choices. We changed this to a simple toggle labeled "True" or "False", matching how boolean inputs already look everywhere else in meshStack.

Preview What Workspace Users See When Ordering a Building Block​

Audience: User

Description​

When you edit a Building Block Definition's inputs, you can now see a live Configuration Preview showing exactly what a workspace user sees when ordering the Building Block.

SBOM Now Published in CycloneDX Format​

Audience: User

Description​

The software bill of materials on the open source info page is now a CycloneDX 1.6 document, downloadable as sbom.cdx.json. It replaces the previous SPDX download.

How to use​

Open your user profile and go to "Open Source Info". You can download the SBOM as a plain text table or as a CycloneDX JSON document.

Only the Building Block Definition Owner or an Admin Can Approve a Run​

Audience: User

Description​

Approving a run that waits at an approval gate is now reserved for the workspace that owns the building block definition, or for an admin. This makes approval policies work as their authors expect: the definition owner stays in control of when a plan is applied, even when the building block is used in other workspaces.

Consistent Empty State in the Building Block List​

Audience: User

Description​

The Building Block list now looks the same no matter how you get to it. The "Building Blocks" tab carries the default filter, so it always opens the list without the deleted Building Blocks.

The getting-started empty state only appears when your scope holds no Building Blocks at all. A list that is empty because of your filter simply tells you that there is nothing to show. Lists also start with a loader now, instead of briefly flashing an empty table while the first page is loading.

API Key Expiration Is Now Preselected​

Audience: User

Description​

When you create an API key or rotate its secret, the expiration now starts with the shortest period your meshStack allows (usually 7 days) instead of an empty selection. You can still pick any other permitted period, but a never-expiring key is only ever an explicit choice.

GitHub Platforms Are Now Custom Platforms​

Audience: User

Description​

We retired the dedicated GitHub platform type. GitHub automation runs through the GitHub integration, so a separate platform type is no longer needed.

Your existing GitHub platforms keep their name, their tenants and their building blocks, and they now show the Custom category. GitHub Actions building blocks keep working, because they reference a GitHub integration and never depended on the platform. Usage reports and chargeback statements from earlier periods also switch to the Custom platform type, so a report that used to say GitHub now says Custom. The amounts themselves do not change.

You can no longer create a GitHub platform, and the meshPlatformType API no longer accepts the GITHUB category.

Platform Builder Overview Only Shows Active Platforms​

Audience: User

Description​

The platforms card on the Platform Builder overview now shows only your active platforms, sorted by their most recent change. Inactive platforms no longer take up space on the dashboard.

Recently Run Building Blocks on the Platform Builder Overview​

Audience: User

Description​

The Platform Builder overview page now shows the Building Blocks that ran most recently, above your Building Block Definitions and Platforms.