Managed clusters can be deleted with everything on them

You can now paste a screenshot, or drop files, straight into a ticket reply instead of saving and attaching them. Each file is listed with a preview before you send, and you can remove any you did not mean to add.

Every deployment that has not finished now has a Cancel button at the end of its row in the deployments list, on an environment's Deployments tab and on the Deployments page. A deployment that is queued or waiting to be run can now be cancelled, as well as one that is running.

If Google Cloud runs out of the usual Arm machines (C4A) in a region while your new managed cluster is being set up, its nodes are now created on the next Arm machine type (N4A) instead of the setup failing. The cluster page shows the machine type your nodes run on.

If Google Cloud runs out of the usual Arm machines (C4A) while a package change creates your cluster's new node pool, the new pool is now created on the next Arm machine type (N4A) instead of the change failing. Your sites move only once the new nodes are ready, as before.

When a deployment failed part way through, the site's scheduled tasks (crons) could stay switched off until someone retried or stopped it. The Control Panel now switches them back on as soon as a deployment fails.

Staging-only site pages now use the visible environment for page-scoped URLs, authentication, settings, and activity while retaining the hidden root as the group reference.

When a Magento 2 site deploys from git, its code is now compiled with the site's own PHP version before it goes live, using your Magento Marketplace keys from Company settings when the project needs them. Before this, these deployments stopped at the build step.

When a cluster cannot take a new site or environment yet, the request is refused at once with a clear message and nothing is created, instead of failing part-way with a platform error. Our team is notified automatically.