Known Issues

Affected release: meshStack 2026.18.0 Symptom: The version number shown in the meshStack UI does not correctly reflect the deployed release version (e.g. as visible at <your-meshstack-url>/mesh/info ). This can cause confusion when verifying which release is running. Root cause: The release tag for 2026.18.0 was not properly published during the release process. Manual intervention was required to correct it, which means some environments may display an incorrect version string. How to verify your version: Check the metadata.all commit hash at https://<your-backend-url>/mesh/info and compare against: 2026.18.0 → metadata.all = e71ec7d8c6ae6864650ece3900a621bf65fbc8d2 2026.17.0 → metadata.all = e3ae221c695d9214c0d9a3595f03737eee731bee If the hash matches 2026.18.0, your environment is running the correct release despite the version label. Resolution: This issue is resolved in the next release. The release tagging process has been corrected and no further manual intervention will be required.

Who is affected Only customers using Terraform <= 1.5.5 (not OpenTofu) are affected. This is caused by an expired PGP signing key used to verify Terraform binary checksums during installation. Root cause This is a known upstream bug in HashiCorp's hc-install tool, which meshStack uses internally to download and verify Terraform binaries. The issue is present since 18.04.2026. The issue has been reported to HashiCorp: https://github.com/hashicorp/hc-install/issues/370 Workaround / Fix We are currently investigating a workaround on our end. Using OpenTofu instead of Terraform would solve the issue, but we are currently checking the consequences of this migration for existing Building Blocks. Status: Under investigation — no fix available from HashiCorp yet.

We are currently observing elevated error rates affecting managed meshStack instances in our SaaS service. meshStack SaaS is hosted on Google Cloud Platform (GCP) on GKE. This behavior is primarily linked to a surge in infrastructure maintenance events in GKE. Technical Details Our engineering team has identified two primary external factors contributing to this instability: CVE-2026-23268 (CrackArmor) Patching : Google is currently rolling out kernel-level mitigations for "CrackArmor" vulnerabilities. This has resulted in an increased frequency of node reboots and live migrations. On our current N2 nodes we see long provisioning times for new nodes to replace failed hosts. While our service is designed to withstand these maintenance events, customers may observe intermittent errors. Since this is the second time node migrations have impacted our service, we are looking at long term solutions Affected Components All meshStack SaaS services (meshPanel, meshStack API) Customers hosted on our GCP-based SaaS infrastructure Status and Next Steps To stabilize the environment and reduce the impact of these maintenance events, we are taking the following actions: Node Type Migration: We are accelerating a migration of affected workloads from N2 instances to more modern instance types. This move is designed to provide better stability during maintenance and decouple our infrastructure from any hardware-specific issues seen on the N2 family. Review of node pool sizing: we are allocating more headroom for maintenance events

Issue Description We are currently experiencing degraded service on meshStack SaaS. Due to an issue with our infrastructure provider (GCP), Kubernetes nodes hosting meshStack services have become unhealthy and require replacement. Customers may observe: Intermittent HTTP 503 (Service Unavailable) responses from meshStack services while they are migrating to healthy nodes Elevated error rates when accessing meshStack Intermittent failures when performing operations in the meshPanel or via the API Affected Components All meshStack SaaS services (meshPanel, meshStack API) Customers hosted on our GCP-based SaaS infrastructure Status and Next Steps We have identified the root cause as unhealthy Kubernetes nodes in our GCP infrastructure. We are actively replacing affected nodes and taking measures to stabilize the service. Current status: Mitigation in progress. We will post a status update by 17:00 today (March 20, 2026) . Contact Check in with our customer success team or support@meshcloud.io if you need any help.

Issue Description We have identified an issue in meshStack v2026.5.0 affecting Building Blocks that use the Terraform or OpenTofu runner. The issue prevents inputs from being correctly passed to the runner, causing building block runs to fail. Specific behaviors observed: Single-select inputs: Values are incorrectly double-quoted. Multi-select inputs: Values are failing to pass, resulting in an "Error: No value for required input". The issue was introduced by another bugfix for correctly encoding code inputs. Affected Components meshStack software release v2026.5.0 Building Blocks using the Terraform or OpenTofu runner Building Blocks with inputs of type single-select or multi-select Workaround The rollout of meshStack v2026.5.0 has been halted. Customers with self-service deployment options: Do not upgrade to meshStack v2026.5.0. Please wait for the patch release. Existing deployments: If you have already upgraded and are experiencing this issue, please contact support. Status and Next Steps We are actively investigating the root cause and a fix is in progress. We expect to publish a patch release resolving this issue later today, outside of scheduled maintenance windows. We will also be revising our internal end-to-end test scenarios to correctly detect and prevent this type of encoding issue from happening again in the future. Contact Check in with our customer success team or support@meshcloud.io if you need any help.

Currently, log entries generated by technical users—such as API keys or API users—do not provide enough information to accurately identify the specific key or user responsible for the action. Additionally, we want to enhance log clarity by displaying the first and last name of a user alongside their username.

We would like to inform you about a known issue currently affecting policy-based role restrictions in meshStack. Issue Summary: Policies configured to restrict user roles based on tags (e.g., limiting certain roles to specific user groups) are not being enforced during the initial project creation process. This means that users may inadvertently be assigned restricted roles when a project is first created, even if they do not meet the tag-based criteria defined in your policy. Important Note: These policies are correctly enforced when: Adding users to a project after creation Changing user roles within an existing project Resolution Plan: We are actively working on a fix, which will be included in our upcoming release next week. This update will ensure that tag-based role restrictions are fully respected during project creation, bringing consistency to policy enforcement across all workflows. Recommended Action: Until the fix is released, we recommend reviewing the policy violations shown in the admin and workspace area and adjusting roles manually if needed. We appreciate your understanding and continued support. If you have any questions or need assistance, please feel free to reach out to our support team.

We have a set of mandatory tags in our environment. A user cannot create a project without filling those tag values in the Cloud Portal UI. When creating a project via API, using the POST meshProject endpoint ( https://docs.meshcloud.io/api/#_post_meshproject ), it is still possible to create the project without providing those tags, even if they are mandatory. The creation only fails if a tag is associated to a policy which restricts project creation (e.g. value of tag X in Project has to match tag X in Workspace in order to create).

At the moment it is not possible to access Tenant Usage Reports in the Service Management Area. We are working on a solution.

When editing the building block inputs sometimes you wanna just click and drag to select a specific part of a string. Instead of it working as I would expect, the entire input form get's dragged and the text is not selected. Seems like the "drag to rearrange" feature of inputs in this form should only work when the input element is collapsed or at least only when a user clicks and drags on the "header" of each individual input instance. Example of how it looks when one accidentally drags the entire form is attached