Skip to main content

Release 2026.43.0

· 12 min read
meshcloud

Release period: 2026-10-14 to 2026-10-21

This release includes the following issues:

  • Moved the "you are receiving this e-mail" notice into the email footer
  • Creating a Tenant Requires the Permission to Create Tenants
  • Deleting a User Removes the Access They Had Through User Groups
  • Clearer Error When You Assign Admin Permissions to an API Key
  • OpenShift Tenant Links Now Open the Project in the Web Console
  • Deactivated Users No Longer Receive Workspace Emails
  • Empty Required Lists No Longer Block Ordering a Building Block
  • See Orphaned Workspaces in the Admin Area
  • Links That Open Building Blocks, Tenants and More in the Right View
  • See Which Runner Executes a Building Block Definition After a Transfer
  • Fix Runner Access Control Issue
  • Marketplace Shows the Permissions of Building Block Definition Drafts
  • Fixed Project Selection When Assigning an Unmanaged Tenant
  • Stricter Checks for Building Block Upgrades and Inputs
  • Building Blocks Drop Outputs Removed in a Newer Definition Version
  • Clearer Error When a Landing Zone Needs Inputs You Did Not Provide
  • Deleting a Building Block That Never Ran No Longer Blocks the Workspace
  • Building Block Definitions Refuse an Invalid Input Regex
  • Fix Building Block Parent Access Control Issue
  • Missing Payment Method Mails Only Reach Current Workspace Managers and Owners
  • Building Blocks No Longer Fail After Another Building Block Finished Deleting
  • Approve and Abort Building Block Runs via the meshObject API
  • Links Always Open the Page They Point To

Ticket Details​

Audience: User

Description​

In the "Role Bindings Expiring Soon" e-mail notification, the disclaimer explaining why you received the e-mail now appears as part of the actual e-mail footer, below the panel link button and the sign-off text, instead of being shown above them.

Creating a Tenant Requires the Permission to Create Tenants​

Audience: User

Description​

A workspace member without the permission to create tenants could still add a tenant to a project of their own workspace that they had access to. This was only possible by calling the API behind meshPanel directly with their own login, because meshPanel never offers them this action. Users of other workspaces and API keys were not affected. meshStack now checks the permission on every tenant creation. Workspace Owners and Workspace Managers hold it by default.

Deleting a User Removes the Access They Had Through User Groups​

Audience: User

Description​

When you deleted a user who had access only through a user group, meshStack removed them from the group, but did not update the tenants and building blocks they could reach through that group. The user kept their permissions on the platforms, and building blocks that receive user permissions kept the user, until an unrelated change updated them. Now we remove this access right away, in the same way as for users with a direct role binding. This applies to users you delete in the admin area, through the meshObject API and through SCIM.

Clearer Error When You Assign Admin Permissions to an API Key​

Audience: User

Description​

When you create or update an API key with admin permissions from a workspace that is not the admin workspace, the meshObject API rejects the request. The error now tells you to use the admin workspace, so you know how to fix it. This helps when you log in with the meshStack CLI or configure the Terraform provider for the wrong workspace. The error also tells you when you request permissions that you do not hold yourself.

Audience: User

Description​

When you click the platform link of an OpenShift tenant, you now land directly on the tenant's project in the OpenShift web console. Before, the link opened the console start page and you had to search for the project yourself. This saves time on platforms with many projects.

The link is updated the next time the tenant is replicated. Platforms without a configured web console URL keep their current link.

Deactivated Users No Longer Receive Workspace Emails​

Audience: User

Description​

When a user is deactivated in meshStack, for example by your identity provider via SCIM, we no longer send that user the emails that go to all managers and owners of a workspace, even if they still have one of these roles. The same applies to users who have not accepted their invitation yet. Emails about expiring API keys still go to deactivated users.

Empty Required Lists No Longer Block Ordering a Building Block​

Audience: User

Description​

When you order a building block, a JSON input could block the "Add service to workspace" button although every field looked filled in. This happened when the input's schema marks a list as required but lets it stay empty, for example an optional list of nameservers. You can now order with such a list left empty, as the schema allows. A required list may stay empty, and only "minItems" in the schema asks for entries. This replaces the earlier behavior where removing the last entry of a required list showed "This field is required."

See Orphaned Workspaces in the Admin Area​

Audience: User

Description​

You can now spot workspaces that nobody looks after anymore, before their costs grow unnoticed. A workspace is orphaned when it is not deleted but has no active Workspace Owner or Workspace Manager left, for example after the last one was removed via SCIM, was disabled, or their role binding expired. Owners and managers who get their role through a group still count, as long as the group has at least one active member. An invited owner who has not logged in yet also counts, so a newly created workspace is not reported as orphaned.

How to use​

"Actions Needed" on the admin area dashboard now shows how many workspaces are orphaned. Click the entry to open the workspace list filtered to these workspaces. In the workspace list you can also pick "Orphaned" in the status filter, and every orphaned workspace carries an "Orphaned" status badge.

Audience: User

Description​

Copilot answers now link a building block definition or a platform to the best view the reader has access to: the admin area, the workspace that operates it, or the marketplace of their own workspace.

The meshObject API now returns a meshPanel link for building blocks, building block runs, building block definitions, tenants, projects, workspaces, platforms and integrations, which opens the object in the best view the user has access to, like the links in Copilot answers.

See Which Runner Executes a Building Block Definition After a Transfer​

Audience: User

Description​

When you transfer the ownership of a building block definition to another workspace, the Transfer Ownership dialog now tells you what happens to its runner. The versions keep their runners, so runs may still execute on a private runner of the previous owner until the new owner switches to their own runner or a shared one. If the runner uses workload identity federation and its subject template contains the workspace ID, the dialog also reminds you to update the trust relationships in your cloud provider.

Fix Runner Access Control Issue​

Audience: User

Description​

We improved security when you select a runner for a building block definition. Before, you could select a runner of another workspace if you knew its identifier. We found no sign that this was used. You can still select the runners of your own workspace and the shared runners, as before.

Marketplace Shows the Permissions of Building Block Definition Drafts​

Audience: User

Description​

When your Workspace owns a Building Block Definition with a draft version, the Marketplace now shows the permissions of that draft. Before, the catalog entry details and the configuration page always listed the permissions of the latest released version, even when you had changed them in the draft. The configuration page now also follows the version you select, so each version lists its own permissions. Other Workspaces still see only the permissions of the released version.

Fixed Project Selection When Assigning an Unmanaged Tenant​

Audience: User

Description​

When you assign an unmanaged tenant to a project, the project selection now lists the projects of the workspace you picked. This fixes a regression since v2026.40.0: the project selection stayed disabled, so you could not assign the tenant.

Stricter Checks for Building Block Upgrades and Inputs​

Audience: User

Description​

We tightened who may set which building block inputs when you order or upgrade a building block through meshPanel, so these actions now follow the same rules as the meshObject API.

Only platform administrators and the platform team that owns the building block definition may upgrade a building block. Application teams never saw the upgrade option in meshPanel, but the underlying request was not refused for them. It is now.

When you order a building block in meshPanel, meshStack now ignores values for inputs that it fills in itself, such as static inputs. Platform operator inputs are only accepted from platform administrators and the platform team that owns the definition.

Building Blocks Drop Outputs Removed in a Newer Definition Version​

Audience: User

Description​

Before, a building block kept showing an output after you removed it from its building block definition and upgraded the building block to the new version. The removed output and its old value stayed in the Panel and in the API, even after the building block ran again. We have fixed this: after a successful run, a building block only shows the outputs that its building block definition version declares. Building blocks that still show a removed output lose it with their next successful run. Dry runs do not remove outputs.

Clearer Error When a Landing Zone Needs Inputs You Did Not Provide​

Audience: User

Description​

When you create a tenant in a landing zone whose mandatory building blocks have inputs without a default value, the error message no longer says that you are importing a tenant. It now says that the tenant cannot be created or imported, and still lists the missing inputs.

Deleting a Building Block That Never Ran No Longer Blocks the Workspace​

Audience: User

Description​

We fixed a bug that occurred when you deleted a building block whose run had not started yet, for example because it was still waiting for an input or for a runner. The deletion was not processed, and as long as that building block stayed in deletion, we also ignored every other building block change in the same workspace: new building blocks, input changes and further deletions did not run, and the affected building blocks were set to failed after a few hours. Such a building block is now removed right away, and the other building blocks in the workspace are processed as usual.

Building Block Definitions Refuse an Invalid Input Regex​

Audience: User

Description​

A building block definition version is now refused if the validation regex of one of its inputs is not a valid regular expression. The error names the input. Until now such a version could be saved, and the regex then let every value through in the meshObject API.

How to use​

Only the version you save is checked; versions you saved before stay as they are. A Terraform apply that sends an existing version with such a regex again now fails, so fix the regex in your configuration before you apply it.

Fix Building Block Parent Access Control Issue​

Audience: User

Description​

We improved security when you choose the parent Building Blocks of a new Building Block. You can still choose parents on any tenant of your own workspace and on the workspace itself, as before.

Missing Payment Method Mails Only Reach Current Workspace Managers and Owners​

Audience: User

Description​

We now send the e-mail about projects without a payment method only to users who are Workspace Manager or Workspace Owner of the project's workspace when we check for projects without a payment method. This check can run some time before we send the e-mail. Before, a user whose role was changed from manager or owner to another role, for example Workspace Member, kept receiving these e-mails.

Building Blocks No Longer Fail After Another Building Block Finished Deleting​

Audience: User

Description​

When you created or changed a building block while another building block in the same workspace finished its deletion, we could lose your change. Your building block then stayed pending and failed hours later without a reason. We now apply your change in this situation, and the deleted building block stays deleted.

Approve and Abort Building Block Runs via the meshObject API​

Audience: User

Description​

You can now approve or reject a building block run that waits for approval, and abort a running one, with an API key or the meshStack CLI. An approval only applies the plan you reviewed. Approving and rejecting stay with the platform team that owns the building block definition.

Links Always Open the Page They Point To​

Audience: User

Description​

A link now always opens the page it points to. Before, on a slow connection, you could land on the first tab of the page you had just opened instead, for example on the admin dashboard right after you logged in.