Skip to main content

Release 2026.41.0

· 15 min read
meshcloud

Release period: 2026-09-30 to 2026-10-07

This release includes the following issues:

  • Building Block Runs Show Which Inputs Were Environment Variables
  • Hub Import Fills in the Pre-Run Script
  • Deleting a Building Block Definition With Deleted Parent Blocks No Longer Fails
  • Locking for the Terraform State of Building Blocks Stored in meshStack
  • Aborted Building Block Runs End Once the Runner Has Stopped
  • Clearer Workspace Role Expiry Email
  • meshPanel Suggests the meshStack CLI, and API Docs Show the Real Authentication
  • Purge a Building Block Whose Dependency Is Gone
  • Building Block Run Artifact Endpoints Renamed
  • Fix meshStack CLI Browser Login Failing With Offline Tokens Not Allowed
  • Legacy Addresses of the Declarative meshObject Import Removed
  • Building Blocks Now Run When a Workspace Role Expires
  • Closed a Permission Gap for Workspace-Level Building Blocks
  • API Keys Can Read Their Own Details
  • See All Landing Zone Tags When Picking a Landing Zone
  • Accepting an Invitation Now Updates Building Blocks and Tenants
  • Marketplace Shows Only Services That Match All Selected Tags
  • New Look for the Tag Filter in the Marketplace Catalog
  • Bulk Upgrade Explains Why a Building Block Input Value Is Rejected
  • Tenant Deleted Events Now Show How a Tenant Was Deleted
  • Reference a Payment Method From a Building Block
  • Read the Inputs and Outputs of Building Block Definitions You Consume
  • Create Tenants via API When Mandatory Building Blocks Have Optional Inputs
  • Clearer Errors and Docs for Building Block Targets in the API
  • Tenants Now Show the "Managed by" Link
  • Pending Output Badges on the Building Block Control Plane Line Up
  • Improved Breadcrumb Labels

Ticket Details​

Building Block Runs Show Which Inputs Were Environment Variables​

Audience: User

Description​

When you list the runs of a building block through the API, each run input now tells you whether the run passed it as an environment variable, even after the building block definition changed. So far an older run showed an input as no environment variable once you upgraded the building block to a version without that input, or removed the input from a draft version.

Hub Import Fills in the Pre-Run Script​

Audience: User

Description​

When you import a building block definition from the meshStack Hub, we now fill in its pre-run script. Hub modules keep this script, and sometimes an input's JSON schema, in a separate file. The noop building block uses such a script. We now read that file during the import. Before, the Pre-Run Script field stayed empty and you had to copy the script by hand.

Deleting a Building Block Definition With Deleted Parent Blocks No Longer Fails​

Audience: User

Description​

When you deleted a building block definition, for example in a Terraform destroy, meshStack could answer with an internal error. This happened when a deleted building block of that definition had been set as the parent of another deleted building block, but the other building block's definition did not declare this dependency in its latest version. Such a definition can now be deleted before the definition of the child building block.

If an active building block depends on a deleted building block of the definition, meshStack now refuses the delete with a message that names the building blocks you need to delete first.

Locking for the Terraform State of Building Blocks Stored in meshStack​

Audience: User

Description​

meshStack's Terraform state backend now supports state locking. Two writers can no longer change the state of the same Building Block at the same time: a Building Block run waits for the lock held by another run or by a person, and a write without the lock is refused while someone holds it. When a run ends, meshStack releases any lock the run still holds.

Workspace Owners and Workspace Managers of the workspace that owns a Building Block Definition can now read, lock and write the Terraform state of its Building Blocks with their normal login. Before, this needed an API Key.

Aborted Building Block Runs End Once the Runner Has Stopped​

Audience: User

Description​

When you abort a synchronous Building Block run that is already executing, meshStack now waits until the runner has stopped the execution. meshStack tells the runner to stop and keeps the run in progress until the runner reports a final status, normally aborted. So a new run of the Building Block no longer starts while the aborted one still changes resources. If a runner never reports back, meshStack aborts the run after the usual timeout for stuck runs. Asynchronous runs are still aborted right away.

Clearer Workspace Role Expiry Email​

Audience: User

Description​

The email that warns you about an expiring workspace role now says clearly that the listed role is your own. Each entry shows the workspace, your role and the date it expires. Before, the workspace owners were listed in the same entry, and some readers took the role for the owner's role. The owners now have their own section, so you know whom to contact if you need support or have questions.

meshPanel Suggests the meshStack CLI, and API Docs Show the Real Authentication​

Audience: User

Description​

When you create an API key or rotate its secret, meshPanel now shows the meshstack login command that stores the key in a profile of the meshStack CLI, and a Terraform provider block that uses this profile. This way the key secret no longer ends up in your Terraform files. The API key pages also make clear that API keys are for automation, and that you log in with the meshStack CLI when you work with meshStack yourself.

The meshStack API docs now show which authentication each endpoint takes, and you can try an endpoint in the docs with a bearer token. API users are deprecated: only the declarative import, the meshObjectCollection endpoints and the metering API still need them.

Purge a Building Block Whose Dependency Is Gone​

Audience: User

Description​

In rare cases, purging building blocks that depend on each other could leave one of them behind without the building block it depends on. Platform teams can now purge such a building block too. Until now, its purge never started, and the building block stayed in the workspace with no way to remove it. A purge only removes the building block from meshStack without running anything on your platform, so it does not need its dependencies.

Building Block Run Artifact Endpoints Renamed​

Audience: User

Description​

We renamed the meshObject API endpoints that building block runners use to upload and download a run's artifact, for example the plan of a dry run. They no longer say "plan", because building block runs are not tied to Terraform or OpenTofu. The meshBuildingBlockRun now links to the download with the new "artifact" link.

How to use​

Existing runners continue to run unchanged: the former "plan-artifact" endpoints and the "planArtifact" link keep working. They are deprecated and will be removed after 2027-01-01.

If you run building block runners on your own infrastructure, update them to the latest runner release before then. Older runners find the predecessor's plan only through the "planArtifact" link, so after its removal they would compute the changes again instead of applying the approved plan. If you wrote your own runner, move it to the new endpoints and the "artifact" link.

Fix meshStack CLI Browser Login Failing With Offline Tokens Not Allowed​

Audience: User

Description​

On some meshStack instances, logging in with the meshStack CLI through the browser failed with the error "Offline tokens not allowed for the user or client". We fixed the Keycloak setup of these instances, so the browser login works on every meshStack. Logins with an API key were not affected.

Legacy Addresses of the Declarative meshObject Import Removed​

Audience: User

Description​

We removed /external/meshobjects/v1 and /external/meshobjectcollections, the old addresses of the declarative meshObject import and of meshObjectCollections. They did the same as PUT /api/meshobjects and POST or DELETE /api/meshobjectcollections and were no longer in use. The declarative import and meshObjectCollections themselves are unchanged and stay available under /api.

Building Blocks Now Run When a Workspace Role Expires​

Audience: User

Description​

A Building Block that reads the "User Permissions" input kept handing out access to a user whose workspace role had already run out, until some unrelated change happened to trigger the next run. We now re-run a workspace's building blocks in the night after the last day of one of its roles, as we already did for project roles. Access on the cloud platforms themselves was withdrawn with that night's update before this change too, and still is. Every withdrawal is now recorded in the activity log of the workspace or project it applies to.

How to use​

There is nothing to set up. On the first night after this release every workspace role that has already expired is caught up in one pass, so each workspace that owns building blocks gets a run for them. Runs started this way are labelled "Workspace role expired" in the run list, and you can filter for them there.

Closed a Permission Gap for Workspace-Level Building Blocks​

Audience: User

Description​

We hardened the permission check so that workspace members can no longer create workspace-level building blocks.

API Keys Can Read Their Own Details​

Audience: User

Description​

An API key can now read its own details, including its permissions, without the permission to list other API keys. This helps the meshStack CLI show what the API key it authenticates with may do.

See All Landing Zone Tags When Picking a Landing Zone​

Audience: User

Description​

When you pick a landing zone while creating a project, or as an operator change the landing zone of a tenant, the dropdown now lists every tag key and value of each landing zone. You can compare the landing zones by their tags before you choose one. The payment method dropdown and the selected payment method list every tag in the same way.

Before, the dropdown showed only the first three tag keys and two values per key. Clicking "Show more" in the project creation dropdown selected the landing zone and closed the dropdown instead of showing the tags.

Accepting an Invitation Now Updates Building Blocks and Tenants​

Audience: User

Description​

When you invite a new user by email and add them to a workspace or project, accepting the invitation now starts everything that gives them access. We replicate their tenants and run every building block that uses the user permissions input again. The user has access once these runs finish. Before, you had to start the building block run yourself after the user accepted.

Marketplace Shows Only Services That Match All Selected Tags​

Audience: User

Description​

Filtering the marketplace catalog by several tags now narrows the result the way you expect. Selecting values of different tags (for example an environment and a team) shows only building blocks that match all of the selected tags. Selecting several values of the same tag still shows building blocks that match any of those values. Previously, a building block appeared as soon as it matched any selected value.

New Look for the Tag Filter in the Marketplace Catalog​

Audience: User

Description​

The tag filter in the marketplace catalog got a new look. It now matches the other catalog controls and shows how many tags you selected.

Bulk Upgrade Explains Why a Building Block Input Value Is Rejected​

Audience: User

Description​

When you bulk upgrade building blocks and the new definition version no longer accepts a kept value of a JSON input, because the value is not valid JSON or does not match the input's JSON schema, the upgrade summary now lists the building block under "cannot be upgraded automatically" and names the input and what is wrong with its value. Until now the summary only said "An unknown error occurred". Upgrade such a building block on its own to enter a valid value.

Tenant Deleted Events Now Show How a Tenant Was Deleted​

Audience: User

Description​

We now provide more accurate information in the "howDeleted" field of the "Tenant Deleted" event. Until now it always said "automatically".

How to use​

The "howDeleted" field now says:

  • "automatically": meshStack deleted the tenant in the platform.
  • "manually": an operator deleted the tenant and confirmed the deletion.
  • "via building block": the building block of a custom platform tenant deleted it.
  • "purged": the tenant was purged, so nothing was deleted in the platform.

Reference a Payment Method From a Building Block​

Audience: User

Description​

Your Building Blocks can now ask for one of a workspace's Payment Methods. Pick the new "Payment Method" input source when you define an input, and whoever orders the Building Block chooses from the active Payment Methods of their own workspace.

This is useful when the automation behind a Building Block has to allocate cost, for example to register a cloud account with your FinOps process. Until now only project Building Blocks could reach a Payment Method, and only indirectly through its tags, so teams kept empty projects alive just to carry that association. Workspace Building Blocks can now carry it themselves.

How to use​

Add an input to your Building Block Definition and set its source to "Payment Method". Your implementation receives the Payment Method as a meshObject reference.

If the Payment Method expires later, the Building Block keeps running against it. It just cannot be picked again. The Inputs of the Building Block show the Payment Method by name and flag it as expired right away, so you do not have to open the editor to find out.

See https://docs.meshcloud.io/concepts/building-block#payment-method-input for the payload, the editing permission and who may choose a Payment Method.

Read the Inputs and Outputs of Building Block Definitions You Consume​

Audience: User

Description​

You can now read the versions of a Building Block Definition that another workspace published to the marketplace through the meshObject API, using a workspace API key with the permission to list building block definitions. The response shows the released versions with their complete input and output schema, so you can see which inputs a building block needs before you order it. The value of a static input is included unless the input is sensitive, so you see the same values a building block of that version carries in its inputs. You also see the dependencies of a version and which of their outputs an input takes its value from. Implementation details, the runner and permissions stay visible to the owning workspace and to admins only.

When you read a Building Block Definition of another workspace, the response no longer contains its usage count. It lists only the released versions, and status.latestVersion and status.latestVersionUuid name the latest released version. status.redactedForNonOwnerAccess is true in such a response, so a client can tell it from the complete response the owning workspace receives.

If you use the meshStack Terraform provider, upgrade it to version 0.26.4 or later before this meshStack release reaches your environment. Older provider versions expect the previous answer for definitions your workspace does not own and crash when they list the building block definitions of another workspace. Version 0.26.4 works with both the previous and the new answer, so you can upgrade the provider ahead of time.

Create Tenants via API When Mandatory Building Blocks Have Optional Inputs​

Audience: User

Description​

You can now create a tenant through the meshTenant API on a landing zone whose mandatory building blocks have optional user or platform operator inputs without a default value. Previously, the API rejected such a tenant with an error about missing inputs, even though these inputs can stay empty. We now create the mandatory building blocks with these inputs left empty, and an empty optional operator input does not make the building block wait for the platform operator. Inputs that are required and have no default value still make the API reject the tenant, because you cannot provide them through the API.

Clearer Errors and Docs for Building Block Targets in the API​

Audience: User

Description​

When you create a building block through the meshObject API and reference its target with the wrong identifier, the error now names the right one: a workspace is referenced by its identifier in name, a tenant by uuid. The API documentation for spec.targetRef now says the same.

How to use​

Use "targetRef": { "kind": "meshWorkspace", "name": "<workspace identifier>" } to create a building block on a workspace and "targetRef": { "kind": "meshTenant", "uuid": "<tenant uuid>" } to create one on a tenant.

Audience: User

Description​

Building Blocks that create other meshObjects are a common pattern, for example a starter kit that creates a project together with its tenants. Building Blocks, Building Block Definitions, Platforms and Landing Zones already show a "managed by" link naming the Building Block that created them. Tenants now show it too, together with the "Managed" badge.

Pending Output Badges on the Building Block Control Plane Line Up​

Audience: User

Description​

While a building block runs, the Outputs card on its control plane marks every output that has not been reported yet with a "Pending" badge. The spinner in that badge is now vertically centered on the text, so a list of pending outputs no longer looks uneven.

Improved Breadcrumb Labels​

Audience: User

Description​

We improved the breadcrumbs on several pages. Where you saw a raw placeholder such as ":link" before, you now see a readable label such as "Details" or "Tenant". This covers Workspace group details, Tenant pages in the Platform Builder, Platform and building block report details, Tenant environmental reports, and the service broker publish, usage, logs and plan pages. On building block and run pages, the breadcrumb now reads "Building Block" instead of the building block's name.