What's New at Corefinity

A ticket that an engineer is actively working on now shows the status In progress. It counts as open: it appears with your open tickets, and replying to it keeps it In progress.

You can now copy one of your CoreStack Enterprise environments, its files and its database, into one of your own password-protected CoreCluster sites, and copy it again whenever you want fresher data. Preview the copy first, then start, follow and finish it through the public API or the MCP tools. Your environment is never changed, and copied WordPress and Magento sites keep outgoing email and payments switched off.

Share Report on a performance audit now opens a designed report for your client, with Simple and Technical tabs, comparisons, definitions and a Save as PDF button, at one link you can protect with a username and password, revoke or regenerate. Choose its sections and their order on the audit, and do all of this through the API and AI agents too.

Turn on automatic upgrades and set a monthly limit of up to £100,000: when a new site or environment would not fit a CoreCluster, the Control Panel adds the cores, RAM or disk it needs, or moves it to the next package, and goes ahead. An environment too small for a copy gets a larger size. Each upgrade stays on your bill until changed back; the limit caps what new upgrades add each calendar month. Billing contacts get an email for each, and a deleted site stops counting against your disk.

While some of your environments have not switched over yet, My SSH keys and your company’s SSH keys in the Control Panel now say where each key already works and how many environments are still waiting, for example “On 16 of 26 environments · 10 at the switch-over”. A key you remove shows the environments it has already gone from, and the API and the assistant’s SSH tools give the same counts.

Planned maintenance emails now give the date and time in their subject line. Times are shown in UK time, marked GMT or BST, and the notice keeps its paragraphs.

On the Region step of the online order, a region that cannot take your order is no longer shown greyed out. If no region can take it, the step says so in one line.

When Continue cannot go on yet on a step of the order page, a short sentence beside it now says what is still missing, such as your site's domain, the human check or the six-digit code, and selecting Continue takes you to that field.

When a scheduled snapshot cannot be taken, it is tried again a few minutes later, up to three times in all. Until the last try it shows as Retrying, and it only shows as failed if every try fails.

When a change to a site's nginx rules makes the health check and every one of its check paths fail three times in a row, the Control Panel now puts the previous rules back after about 15 seconds instead of waiting the full 90 seconds. The same applies to the check that runs once an environment that was stopped when the rules were saved is running. A path that is still starting up keeps the full 90 seconds.

Before you start a deployment or a rehearsal, the Control Panel checks that the settings file your platform needs is in the environment's shared folder, and tells you how to create it if it is not. The same check is on the API and for AI assistants.

Copying a saved snapshot to an environment on different servers is refused before you start, with the same plain reason in the Control Panel, the API and MCP, and what to do instead: copy the live environment, or restore the snapshot to an environment on the same servers.

The Shopware storefront and Shopware administration build presets can now be chosen in a pipeline's Build stage, in deployment templates and through the API and MCP. They build the storefront and administration code of every plugin, including plugins in custom/plugins that are not installed through Composer, without using the shop's database. They need an environment with the runtime update and Node.js 20 or newer.

In the Control Panel, a performance audit now shows Not run, with the reason, for any test the runner could not complete. Shared reports, the API and the MCP tools give no time for such a test, so every time you see is a real measurement.

Company settings in the Control Panel now open straight onto your company's firewall and default maintenance window cards, even when they are the only settings your company has.

The Feedback button now says that our product team reads every message but doesn't reply, and links to a support ticket for when you need an answer. The API documentation and the AI assistant's feedback tool say the same.

When you add a staging environment, the Control Panel now shows what it starts with: the firewall addresses it inherits and whether SSH is closed to everyone else, the SSH keys it gets and its password protection. The same answer is available from the API and to AI assistants over MCP.

We have brought the Control Panel's nginx rule checks up to date with the platform's. They now accept a CORS map that passes your app's own Access-Control-Allow-Origin header through, as in the Laravel API CORS snippet, and the Control Panel, the API and the MCP tools all give the same answer.

New sites and environments on MariaDB 11.4 now start on 11.4.13, the latest 11.4 release. Sites already on MariaDB 11.4 keep the release they run.

Environments created from now on are set up for SSH key management in the Control Panel shortly after they are ready, so you can add and remove their SSH keys there straight away. Existing environments move over in planned stages.

Agencies and customers can now create up to 100 sites an hour in the Control Panel, the API and MCP, up from 5 or 10. Your cluster's capacity and your package's limits still apply.

A path app on a WordPress site can now link to the site's uploads folder, or any folder inside it, so the media you upload in WordPress is served under the path app too.

The demo invitation email now says who set the demo up, lists the two steps to get started and shows the date the link expires. The demo sign-up page is cleaner, and a CoreCluster demo now shows as many sites as fit the cluster's capacity.

When a new site or environment is held up by something temporary on the platform, the Control Panel now tries it again for you, up to three times, and keeps going for longer before it gives up. Its progress, the API and the MCP tools say each automatic attempt in the same words.

When an environment's nginx rules have been changed outside the Control Panel, the public API and AI assistants connected with MCP can now answer it just as the Nginx tab does: use the committed version, or keep the Control Panel's rules. Each answer is checked the same way, in the same plain words, wherever you give it.

A deployment that is running when we update the Control Panel finishes on the version it started on, and new deployments start straight away.

A new site or environment is no longer turned away when the region has no room for it yet. It is accepted straight away, shows "Taking a little longer" while it waits briefly for room, and then continues by itself. This works the same in the Control Panel, the API and the MCP tools, and the capacity check now says the site will wait rather than reporting a block.

When you create a site, a CoreCluster or an environment while another one is being set up in the same region, the Control Panel now accepts it straight away and shows "Waiting for another change to finish" until it starts, then carries on by itself. The same applies through the API and to AI agents. You no longer need to come back and try again.

When you raise a support ticket you can now choose more than one website and more than one environment, so one problem affecting several sites needs only one ticket. Environments are listed under their website. The support API and MCP tools take lists of websites and environments too.

Creating a CoreCluster now rides out a slow platform: when a step meets a temporary problem it waits and tries again on its own, and your cluster's progress says so. If a new cluster cannot be created after all, its name is free again straight away, so you can create it again under the same name.

Copying an environment into another, or to live, now gets time limits that grow with the size of the data being copied, for the copy itself and for the steps around it, so large copies have the time they need. A new environment created from a copy always reaches a clear status, with a plain message when its copy could not finish.

When a site in a migration cannot be created straight away, for example because the cluster has no room for it yet or is busy with another change, the migration now waits and tries again on its own, showing why it is waiting and when it will try next. A site stops only when it still cannot be created after several hours, or when it needs something from you, and then it says why.

When the version a new site would install by default has not finished our testing yet, or its default PHP version is not yet available for new sites, the site is now created on the newest version that is ready. When no version is ready yet, the site waits and is set up as soon as one is, instead of the request being turned down, and it can be deleted while it waits. The site's page, the API and the MCP tools say which version was installed, or which one the site is waiting for.

Copying onto an environment or pushing to live no longer stops at "wait for it to finish". If another copy is running on the site, a change is still in progress on either environment, or the environment is still being set up, your copy now joins a queue and starts on its own as soon as it is free, first come first served. The copy dialog, the API and the MCP tools show what it is waiting for, and you can cancel it any time before it starts.

When the environment you copy into has too little space for the data, the copy preview now names the size to resize it to before anything starts, in the Control Panel, the API and through MCP alike. Companies that turn on automatic upgrades can have the target grow to that size first, priced as a resize and kept within the monthly limit they set. A new environment made as a copy says up front which size holds the data.

A create the Control Panel turns down, such as a mistyped domain or a change that is still running, no longer counts towards your limits, in the Control Panel, the API and AI assistants alike. Retrying a site that did not finish setting up has an allowance of its own, you can add many environments at once, restoring a deleted site is never held back by the deletes it undoes, and new CoreClusters share one hourly allowance across your company.

When a new site or CoreCluster takes a little longer to set up, its billing and any free trial now start when it is ready, not when you ordered it, so you never pay for a day you could not use it. The Billing page in the Control Panel shows when each contract starts billing, and so do the API and AI assistants connected with MCP.

A new site, environment or CoreCluster that needs a fresh server while cluster changes are paused for planned maintenance, or while a CoreCluster is moving onto its new servers, is now accepted and set up automatically the moment it can be. There is nothing to try again: follow its progress in the Control Panel, the API or your AI assistant.

Staging and development environments on Managed Clusters can now be renamed from their site page in the Control Panel. Their hostname, and everything else about them, stays the same.

When the certificate for a new site or environment takes longer to issue, the create now waits for it instead of stopping, and carries on by itself as soon as it can. While it waits, the Control Panel, the API and the MCP tools show "Certificate on its way", so there is nothing to retry.

A Direct Debit you have just set up now counts as a payment method straight away, so you no longer wait for your bank to confirm it before creating a site or changing a package. And if your company has no payment method yet, you can still create one CoreStack site: it is set up as usual, and we email you the date to add a card or a Direct Debit mandate by. The Control Panel, the API and the MCP tools all say the same.

When a new CoreStack site's usual platform address is already taken, the site and its environments are created on the next free address, and its progress in the Control Panel, the API and the MCP tools shows which one it uses. A site created again straight after an earlier attempt waits for that attempt to be tidied away instead of asking you to try later.

When the platform needs more capacity for a new site or environment, a larger server included when one is needed, it now waits while that capacity is prepared and carries on by itself once it is ready. The progress page, the API and the MCP tools say "This can take a little longer" while it waits.

Deployment, repository and company SSH key actions that your role does not include now stay in view in the Control Panel, unavailable, with a note naming the permission they need and who in your company can grant it. The API and MCP list them too, with the same note.

When a new site waits for a version that is still finishing its security testing, the Control Panel now asks for that testing straight away and shows where it stands: about to start, under way, or with our team. The same progress appears in the API and the MCP tools.

When you check or save custom nginx rules, the Control Panel now tells you straight away that an HTTP-hook upstream name starting with cf_ is reserved for the platform, so you can choose another name.

The clean-up at the end of a deployment now removes only releases that a deployment created, and always keeps the release the deployment replaced. A site's first Git deployment keeps the files the site served before it on the server, so the site can still go back to them.

When the Control Panel writes its settings into a Bedrock project's .env (a Git deployment, a URL change, going live, a copy or a restore), DATABASE_URL now names the site's own database by reference, so a standard Bedrock project keeps reaching its database.

A converted or moved site's first Git deployment keeps the files it already serves, and its older release stays until a later deployment succeeds with nothing unshared left in it; a Bedrock release must reach its database first. Pipelines refuse a variable named like a tool's credential, flag a line that is only cd or export, warn about a Node.js version mismatch, and Retry says when the pipeline changed after the build.

When a change to HTTP authentication is saved while your site is in maintenance mode, the card now says it was saved but not yet checked. The API and AI assistants report the same state.

A Laravel site or environment created empty now gets its .env file, with its own application key and the site's database settings, and Laravel's storage folders, as a fresh install does, so its first Git deployment has everything it needs.

When Corefinity support retries a new site's create, its progress page still says when you asked for the site and by whom, and shows the retry on its own line. The public API and MCP site progress answer both.

Turning on admin two-factor on a live Magento site now waits for the site to be quiet before Magento recompiles, so the recompile runs clear of visitors' requests. If another change is already holding the site, nothing is changed.

With the pre-switch check on, a deployment now asks the new release for its home page, and any paths you list, before it goes live. If the new release answers with an error, the deployment stops before the switch, your live site keeps serving the release it had, and the deployment says which page failed.

Explaining a path such as a hidden file, a PHP backup copy or a .phtml file now shows that the platform answers it with a 404 before your own rules run, and names the guard. The API and the MCP explain tool answer the same.

If you close or reload a support ticket while your reply is still sending, your browser now asks you to confirm first, so your reply can finish sending.

Two environments of one CoreCluster saving their nginx rules within a second of each other now both go through. A save is still refused when its own environment's files changed in the meantime.

When the tunnel a build uses to reach your live database or cache stops part-way through, the build now stops straight away and says so.

A message naming your site's domain, such as the one for a key that is already added, is now shown as written in the Control Panel, the API and MCP, whatever letters the domain contains.

After a search index build fails, the Shopware health check reports the index as missing, while your shop searches its database, until a build succeeds. The Control Panel, the API and MCP all show the same.

When a pipeline carried over from CoreStack Enterprise has no line left to review, the card now offers Accept as translated, which lets the pipeline deploy, and Dismiss waits until it is accepted.

On the Legacy SSH keys review the select column is now narrow, so key names and their labels have room, and on narrower screens the less important columns fold away. In every SSH key list a long status, such as Waiting for the switch-over, stays inside its own column, and on the Legacy keys review and an environment's SSH access list its detail sits on the line below.

The All sites card shows a site as Deploying only while a deployment is running, and the Deployments and Recent deployments cards count a deployment as waiting only when it will start by itself. A deployment waiting for someone to press Deploy is still listed on the site's Deployments page.

A redirect from a path your nginx rules already handle exactly (location = /path) is now refused when you save it, naming the line of your rules.

When a known AI app such as Claude Code or Codex connects to the Control Panel for the first time, the sign-in page now names it instead of saying that an app wants to connect. The descriptions on the permission cards you tick are also easier to read.

While site commands are switched off, the Functions tab, the API and the assistant show each function that runs a command as not available, with the reason, and a Node.js or PHP change waiting to be checked says "Waiting: commands are switched off" instead of "Applying change". A WordPress update asked for meanwhile is refused at once.

When a map in your nginx rules has a key nginx cannot fit, usually a long domain in the Magento multi-store snippet, the rules test now says so and shows how to write that key as a regular expression.

When a pipeline rehearsal fails, the Control Panel now shows the step that failed and the steps that did not run as soon as the rehearsal ends. The temporary copy of your site's code that a rehearsal uses is removed once it has finished.

When a new environment cannot take the memory limit, upload size or max execution time of the environment it is made from, its progress, its PHP settings, the API and the assistant now say which settings were changed and the value each now has.

A build whose tunnel to a live service could not be opened now names that service, a database sign-in error in deployment output shows whether a password was sent, a deployment step that runs out of time says so in plain words, and the Job Log toolbar follows the dark theme.

On a site with more than one pipeline, the deployments list now hides Duration and then Triggered by as the screen narrows, as it does on every other site, and keeps the Pipeline and Started columns.

Corefinity sends Strict-Transport-Security (HSTS) on every HTTPS response, so a header of that name in your nginx rules would never reach the browser and saving it is refused. The Add header dialog no longer offers the HSTS preset, and an HSTS header added from the card before shows why it is refused, with Remove to take it out.

When an AI assistant connected to the Control Panel checks on a change while it is being made, such as turning on the Shopware Security Plugin, the change carries on as normal: the Control Panel carries out each step in the background, and the assistant sees the progress as it happens.

When a Magento site moves to a new cluster, the folders and files it keeps in var/ now stay available to the site after its next deployment, not only Magento's own shared folders. The Control Panel lists the ones it carried in the environment's Deployment options card.

When you turn on install scripts for a global Node.js package that has them, and the environment's command line has less than 512 MiB of memory, the Control Panel now says the install needs more memory and saves nothing. Turn install scripts off for that package, or choose a larger size. The API and AI assistants get the same answer.

A line carried over from CoreStack Enterprise that is waiting for review and still calls n98-magerun now says that CoreStack runs Magento's commands as php bin/magento. The Control Panel, the API and MCP ask you to edit or remove that line before it is accepted, so every carried-over pipeline deploys cleanly.

Testing custom nginx rules now lists only the messages about your own rules, so a check that passes reads clean. An error that stops the rules from loading is still shown.

When someone raises a ticket for your company, the company's owner now gets the same email as everyone else, not a differently worded one. The owner's copy leaves out the line about notification preferences, because the owner is always told about new tickets.

When a deployment switches a Laravel site to a new release, the Control Panel now waits until the site is answering requests again before it carries on and reports the deployment finished. The same applies to the other changes that rebuild a Laravel site's configuration, such as changing its URL.

Selecting text with the mouse now highlights every line it covers in the web server rules, PHP, error page, Varnish and deployment pipeline editors, so copying a block is quicker.

In the Control Panel's nginx rules and Varnish VCL history, each revision now lists the parts it changed against the last revision before it that stood, skipping any revision that was rolled back, refused or never applied. The API and the MCP history tools show the same.

Deployments from an uploaded .zip, .tar, .tar.xz or .tar.zst archive now run your pipeline's build commands, as a .tar.gz upload does, and a .zip made on Windows with backslashes in its folder names deploys with every folder in place. The built release is kept as a .tar.gz archive, so retrying the deployment deploys the same build.

If a new site or environment cannot be created, its progress page tells you that our team has been alerted, and our team hears about it straight away so they can look into it.

When you run a command on an environment through the Control Panel, the API or an AI assistant, it now shows as finished as soon as the Control Panel sees that it has ended. Before, a command that finished very quickly could still show as running until the next check.

When a change, a copy, a command or a cluster task cannot finish, its message now tells you to contact support. A message says our team has been alerted only when it has been, for example when a new site cannot be created or scheduled maintenance cannot be completed.

A repository with the same webhook added more than once now deploys each push once. Pushing the same commit again within ten minutes does not start a second deployment; use Deploy in the Control Panel to deploy it again.

Repositories owned by a GitHub organisation now come up when you search, and the warning about missing admin access only shows when the account really lacks it. A Grant organisation access link now shows whenever GitHub is connected, including next to each GitHub account under Deployment Connections.

A CoreStack site now shows how much of its snapshot space is used and warns when it is nearly full; changing its package moves the next scheduled snapshot to the new package's frequency.

Server type changes and moves are now checked when you request them, before anything is scheduled.

Roll back can now take a converted site back to the files it served before its first Git deployment, on the Deployments tab in the Control Panel, through the REST API and through MCP. It runs as a new deployment, like any other rollback, and is offered while no earlier deployment can be rolled back to.

Deleted snapshots show a specific reason for automatic clean-ups, such as "Removed after its copy" or "Deleted with its site". The Control Panel, the API and the MCP tools give the same reason.

When a new release's container keeps exiting, its deployment now stops as soon as that is clear and shows the container's exit code and last message in the Control Panel, the REST API and MCP, rather than waiting for the full timeout.

When you restore a snapshot, you can now choose another environment of your website as the destination, for example to restore a production snapshot into a staging environment. You confirm the destination by typing its name before anything in it is replaced.

Magento 2 sites on CoreStack and CoreCluster can now serve pages from Varnish. Switch it on or off, choose its version, purge it by URL, tag or pattern, add your own VCL with validation, history and revert, and follow its hit ratio in the Corefinity Control Panel, the API and the MCP tools; deployments purge it for you.

A redirect rule can now apply to chosen domains of a site instead of all of them, so two shops on one site can each keep their own redirects. On its domains a limited rule runs before the rules for every domain.

On every CoreStack environment you can now run a separate PHP application in a folder of your site (such as a WordPress admin), serve a folder of files, block a path, or limit a path or host name to a list of addresses, from the Nginx tab. Only the PHP files you list ever run, and every change is checked before it goes live.

Each CoreStack environment has a Database tab with its connection details and database users: add read-only or read-write logins for tools inside the site, or turn on external access to give an outside system its own login from addresses you choose, on a static address for £15.00 / month.

Our error pages now show for 500, 502, 503 and 504 responses, with your app's API and JSON responses left untouched. In Error pages you can turn ours off per code, use your own HTML with live preview, and test it against your site.

The Control Panel API can now read, check, preview, save, revert, reset, copy and retry an environment's error and maintenance pages, follow each change, and switch maintenance mode on or off, with the same permissions, checks and limits as the Control Panel and the AI assistant tools.

The API now reads, checks, saves, restores and copies an environment's custom nginx rules, explains which rule answers an address and converts .htaccess files, with the same checks and answers as the Nginx tab.

The API can now list and read your sites, websites and CoreClusters, follow a new site or CoreCluster, see what needs attention, check capacity, create or delete a CoreCluster and delete or restore a site. It can manage environments, show the preview login, reset an administrator, change a package, add-ons or server type, and follow, retry or reveal operations and apply or cancel pending changes, with the same checks as the Control Panel and the MCP tools.

The API now reads and changes an environment's PHP and Node.js: versions, extensions, settings, PHP-FPM, Xdebug, php.ini checks and tests, history and restore, copies to other environments, and Node.js packages, with the same checks and answers as the PHP and Node.js tabs.

The API now reads and saves an environment's redirects, HTTP authentication (revealing a login's password to the token's own user) and domains, checks and points DNS, changes the main domain, attaches a domain to go live and manages the Cloudflare connection, zone, SSL mode and cache purge, with the same checks and answers as the Control Panel.

Home is now a dashboard you arrange yourself. Add widgets for your sites, CoreClusters, deployments, support tickets, billing and more, drag and resize them, and set one time range for every chart. Start from a ready-made template (agencies also get one for their clients), chart your log lines and errors or follow them live, and show a dashboard on a wall screen through a read-only display link you can revoke at any time.

SSH and SFTP users and their keys on a site's Access tab can now be read, added, changed and removed with the API, with the same rules as the Control Panel.

Your team, roles and company notification settings can now be managed through the public API and by AI agents connected to the Control Panel, with the same rules as the Team, Roles and My Company pages. User and role ids from outside your company answer Not found.

The API now takes, reads and deletes snapshots and sets snapshot frequencies and CoreCluster snapshot settings, with the same checks and answers as the Snapshots tab. Listing an environment's snapshots and changing a snapshot's note or keeping it now work through the API too.

Open, read, reply to, close and reopen your support tickets, attach files to a reply, change a ticket's priority and choose who follows it, through the API and an AI assistant connected with MCP, with the same rules as the ticket page.

A CoreStack or CoreCluster site's deployments, deployment pipeline, variables and registry secrets, and your company's deployment templates, variables and registry secrets, can now be read and changed from the API as in the Control Panel: deploy, stop, retry and roll back, edit, copy, restore, rehearse and reset pipelines, save templates and reveal a value, with the same checks, messages and limits as the Control Panel and the MCP tools.

The API now reads your billing account, balance, usage, ledger, invoices and their PDFs, credit notes, credits, payment methods, contracts, the price catalogue, quotes and your orders, with the same rights and answers as the Billing pages and Company › Orders. AI assistants can list your orders too, and filter your invoices as the Invoices page does.

The API can now check and start a copy of an environment onto another environment of the same website, or onto production (push to live), with the same checks, refusals and token scopes as the Control Panel and AI agents. The new Copies page of the API documentation shows how to follow a copy as it runs.

CoreStack Enterprise deployments can now be listed, deployed, cancelled, retried and rolled back from the API and from MCP tools, with the same checks and messages as the Control Panel. In the API, ids outside what you can see in the Control Panel answer Not found, exactly as ids that do not exist.

Your sites' scheduled tasks, a Shopware shop's store token, storefront domains, health, Security Plugin and search, PageSpeed Insights tests, the browser terminal's history and recordings, and a site's own database login can now be used through the API with a personal access token, and feedback can be sent through it too, with the same rules and answers as the Control Panel and AI assistants.

The API now searches a website's logs and reads their fields, facets, histogram, context, saved queries and usage, and exports log lines to a file, with the same checks and answers as the Logs tab.

You can now read and change a CoreStack Enterprise environment's deployment settings (pipeline on or off, deployment source, manual or automatic git deploys) and its git repositories through the API and the MCP server, with the same rules as the environment page.

A path app can now limit how many requests a second each visitor may make, and a new kind of path app shows another website, such as a blog hosted elsewhere, under a path of your own address over https. Both are on the environment's Nginx tab, in the REST API and in the MCP tools.

A Magento site can send each store's mail through its own verified sending domain, chosen by the From address.

The Control Panel detects a Bedrock WordPress project and deploys, copies, clones and changes its address the Bedrock way. A WordPress site's managing agency can turn Corefinity's platform plugins off; the tools that need them then say why, in the Control Panel, the API and MCP.

You can now list, read, create and run your company's performance audits through the Control Panel API and MCP, with the run followed until it finishes; audited sites' HTTP passwords are never shown. Agencies can also read their partner referrals and refer new leads, and read their agency page and ask for changes to it, the same way.

The change log entries and announcements on the What's new? page can now be listed, read and marked as read through the API and by AI assistants connected to the Control Panel, with the same rules as the page.

New Magento 2 sites on CoreStack and CoreCluster now start with Varnish full-page cache switched on, and new environments follow their site's Varnish setting. You can switch it off or choose its version when you create the site, or at any time afterwards, in the Corefinity Control Panel, the API or the MCP tools.

The progress steps shown while a change is applied to a site, such as a PHP, domain or email change, now say plainly what is happening, for example "Applying the change" and "Change applied". The badge beside a change says when it takes effect.

A new Shopware 5 site created at 16 GB or more now includes Elasticsearch 7.17 search, which runs inside the site; smaller sites search through the database. Until its first search index is built, the storefront searches through the database, so search keeps working throughout.

New sites and environments are now created only on PHP versions with the latest security patches. PHP 7.4, 8.0 and 8.1 are available for new CoreStack and CoreCluster sites on patched images; existing sites are unaffected.

A new website now shows as Active on Managed Websites from the moment it is added, rather than Pending setup or Onboarding. A site that is still being created shows Creating… until it is ready.

When you create a site, a cluster or an environment, the platform, version, PHP, database, package and size choices now show only the options you can select, instead of greyed-out ones you could not click. The recommended choice is still picked for you.

A website whose production environment is on CoreStack Enterprise now shows as CoreStack Enterprise, and is listed under that tab, even when its staging environment runs on CoreStack. Each environment still shows where it runs.

A Magento 2 site that runs more than one store can now have each store answer on its own address, a platform address or a domain of its own, with the right store shown on each. Ask support to set it up for your site.

A website with more than three environments now shows three of them and an All button. It opens a list of every environment, grouped into Production, Staging, UAT and Development, that you can search as you type; pin the ones you use most to keep them on the row.

The Cluster / Region column is gone from Managed Websites, leaving more room for each website and its environments. Where a website runs still shows on its own page.

Your deployments now continue as normal while we update the Control Panel, and queued deployments start as usual. Anything you start at the moment of an update is queued for a moment and starts by itself within about a minute, so there are no more pauses to wait for.

You can now take up to 20 one-off snapshots of a site each hour (sites on Google disks stay limited to 6 an hour by Google). The Snapshots tab no longer shows how many are left this hour.

Every deployment from an uploaded archive now checks the unpacked release against a list of files known to be malicious, and stops before anything is built or changed if it finds one, naming the files to remove. Magento 2 releases also get a warning when they hold PHP files under pub/ that are not Magento's own.

If your billing is arranged with Corefinity outside the Control Panel, you can now upgrade a site's package, add capacity, change its server type and resize its staging environments yourself. No price is quoted in the Control Panel for these changes; they are invoiced as part of your existing arrangement.

Retrying a deployment that is not the newest on its environment now tells you which commit it will put live and which deployment is the newest, and goes ahead only once you confirm. The API and the MCP tool ask for the same confirmation, sent as confirm_older.

The menu groups Organisation, Billing, Tools and agency pages, and Tickets is now Support. Site, cluster, billing, organisation, profile and role pages share one layout with a section menu, every list and table has search and filters that stay in the page address, agencies can search and star clients in the client switcher, and dialogs, buttons and links are tidier and more consistent.

Reading a deployment pipeline through the API or the MCP server now lists, for a classic pipeline, every command it runs in the order a deployment runs them, under the names the deployment page uses, including the commands it inherits from the platform's shared pipeline. Credentials stay hidden.

Every refusal from the public API now carries a code equal to its reason, and every endpoint answers a field that is missing or wrong with 422 invalid, naming the field. A typed confirmation that does not match, such as the environment's name when turning external database access off, is confirm_mismatch in the same words the AI assistant tools use.

The release archive of each deployment is now kept for 30 days, and always for an environment's 10 most recent deployments and its newest successful one. An older deployment whose archive has been removed can no longer be retried or rolled back: deploy again from its branch or commit instead.

Reading or changing PHP settings on a site whose settings the Control Panel does not manage now refuses with not_available, and a command the Control Panel will not run refuses with invalid_arguments. Both carry a code, in the same words and with the same code as the AI assistant tools.

When a CoreStack Enterprise environment moving to CoreStack needs a larger staging size than its disk suggests, you can now see the question and answer it through the API and the MCP server, as well as on the environment's page. Accepting a size that costs more asks you to confirm the extra cost.

The billing routes of the API now take account_id, the name the AI assistant tools use, as well as account to choose a billing account, with the same answers either way.

The usage charts that AI assistants show through the Control Panel's MCP server now name memory and disk in GB, MB and TB, like the rest of the Control Panel. The figures themselves are unchanged.

The usage history charts on a site's Overview and on a cluster's usage card now use the Control Panel's new chart style. They follow light and dark mode as you switch, can be shown as a table and keep the limit and guaranteed labels apart.

The site check that AI assistants run through the Control Panel's MCP server now names response sizes in KB and MB, as the rest of the Control Panel does. Cluster and site pages name memory and disk in GB for every user. The figures themselves are unchanged.

The dashboard's 30-day PageSpeed trend and a site's PageSpeed history now use the Control Panel's charts: hover or use the arrow keys to read each day's medians and each run's score, band and metrics, failed runs are marked on the axis, and both follow dark mode.

Each result now shows how long the server took to answer, apart from the time spent connecting, so a slow connection no longer makes a fast site look slow. It is in the Control Panel, the API and for AI assistants.

Performance audits can now be edited, deleted and shared, and their GTmetrix reports generated and read, through the public API and the MCP tools, the same way as in the Control Panel. A delete asks for the audit's name, and GTmetrix reports for the number of tests, to confirm.

Before a copy replaces an existing environment, the copy dialog now asks you to type that environment's name.

The CoreClusters widget shows each cluster as a tile with its CPU, memory and storage, Moving to CoreStack fits the sites it lists, links and buttons on dashboards show the pointer, the Clients card's attention count opens Client health with each reason, and the Add widget gallery is easier to browse. Cluster answers in the Control Panel, the API and MCP give capacity as CPU, memory and storage.

You can continue straight away; choose a different package if you need more.

On an environment's SSH access card, the options that open from Add my IP now show in full, and you can scroll down to Add.

Signing in, or entering your two-factor code, now completes even while another Control Panel tab in the same browser is loading, and your new sign-in stays in place. Signing in with Google or GitHub for an email without an account now links you to the order page.

A build now keeps what its commands printed, up to the last 512 KiB, so the deployment page shows a failing command's own messages even after the live output has gone. A successful build keeps its output the same way.

While a change is being made to a site, the sites table on a cluster page now names the change itself, such as SSH keys or PHP configuration, and shows the old and new versions only for a PHP or MariaDB version change.

On a site that deploys from Git, the Deploy button at the top of the page works from every tab: it opens the Deployments tab when needed and asks you to confirm deploying the branch, with the pipeline to use when there are several, and says why when a deployment cannot start.

A release archive uploaded through the deployment API now deploys to a CoreStack environment, including one moved from CoreStack Enterprise. Anyone who can deploy the site from the Control Panel can upload to it with their API token, and each upload is recorded in the site's activity.

The check that runs when you save custom nginx rules now uses every one of the site's own platform files, so valid rules save on every CoreStack site.

A pre-built release installed without Composer's platform check now deploys to CoreStack even when some of its packages declare a PHP range outside the site's PHP: each one is listed as a warning on the "Checking PHP requirements" step. Missing PHP extensions, your composer.json's own PHP range, and releases that ship the platform check are still refused.

A Shopware 5 repository without custom/plugins or custom/project (Git does not keep empty folders) now deploys: each deployment creates the folders Shopware 5 needs before the new release goes live.

New Shopware 5 shops are installed with laminas/laminas-code 4.11.0, the PHP 8.2 version Shopware allows, so the shop's own code deploys from Git and the standard build runs on a Shopware release tree. Where a site's platform offers no other PHP version, a refused deployment now says which package or requirement to update.

Steps from your own pipeline are named by where they sit in it, for example Build command 3, and show the command that ran, on the deployment page, in Slack alerts and in tickets raised from a failed deployment.

A site's and a cluster's usage graphs now add CPU and memory readings every 10 minutes, each within about 20 minutes of being measured, and disk readings every 20 minutes, within about 40.

While a site's staging environment has moved to the platform and its live site still runs on the old hosting, the platform checks only the environments it runs, so the live site raises no status alerts or Node.js, PHP or application version warnings until it moves too.

Once a planned maintenance pause ends on a busy cluster, the deploys that waited during the pause are started a few at a time, and once those are on their way, new deploys start straight away.

While planned maintenance pauses deploys, a queued deploy's page now says it is queued and will start by itself, with the expected time when there is one, and that there is no need to cancel it or deploy again. Once the pause ends it says the deploy is starting shortly.

On environments whose SSH access is managed by the Control Panel, deployments built from VSF images now prepare the web user's SSH folder themselves, so the Create Ssh Key step completes, and deployment output leaves out a stray "no mount point specified" line.

The Nginx tab is now available on Shopware 5 environments, and checks your rules the same way as on the other platforms.

When GitHub, GitLab or Bitbucket refuses the webhook that starts a deployment on each push, the repository now says so and why, with what to do about it. Reconnecting the account, or connecting the repository again, tries again.

Edit on the company and cluster maintenance window cards, Change and Choose another in the restore wizard, Restore to on the Snapshots page, Copy known_hosts and the host key rotation buttons, and Retry and Show older on several lists all show and work.

When several deployments are queued on one pipeline, they now always run in the order they were started, so the last one started is the one that stays live, and a waiting deployment's output names the deployment it is waiting for.

When you ask the API or the MCP tools for upcoming maintenance across all your sites, the answer now includes your CoreStack sites that are not in a CoreCluster, and a token limited to particular sites lists every one of them however many sites you have.

The cache flush at the end of attaching a domain now works without the PHP Redis extension, and a site with no Redis skips the flush and records that. A staging or development environment now keeps its outgoing mail held when a domain is attached.

While a CoreStack Enterprise environment's move to SSH keys managed in the Control Panel is on hold, its SSH page, the API and the AI tools show a switch-over date only once the switch-over is planned.

A whole copy (files and database) into an environment with a smaller disk is now sized by the data the site actually uses, as files-only and database-only copies already were. A files-only Shopware copy into an environment with no shop database yet completes and says the theme compiles once the database is copied, in the Control Panel, the API and the MCP server alike.

When two environments run on one server and the Control Panel manages SSH on one of them, the other one's SSH page now says where its SSH is managed and links there. Adding, changing or removing that environment's own keys is refused with the same words in the Control Panel, the API and the AI tools.

Applying a site's pending changes, now or in the maintenance window, places the site on any server of its cluster that has room.

A Magento 2 deployment on Kubernetes now purges the Varnish cache once the new pods are online and before maintenance mode comes off, so pages from the previous release are not served after the switch. Purging everything in Varnish on a CoreStack or CoreCluster site now also clears files Magento does not tag, such as robots.txt and sitemaps.

Deployments using the shared WordPress pipeline now leave out one of its build steps and run straight through; environments with their own build or post-deploy commands are unchanged.

On environments that use deployment pipeline version 2, each deployment keeps WordPress's wp-content/uploads, and Laravel's storage folder and .env file, on the site's shared storage rather than using the release's own copies. Files already there are carried over once from the live site and never overwritten.

A redirect limited to some of a site's domains now updates by itself when the site's domains or address change: it starts working on a domain the site gains and stops on one it loses, without saving the redirects again.

While deleting is switched off for a moment, deleting a site or an environment or restoring a deleted site through the API now answers 503 switched_off, in the same words and with the same code as the AI assistant tools, instead of 404 feature_off.

A restore that can only run as a fast swap, onto an environment whose platform version cannot prepare it, is now refused straight away with a plain reason. Copies onto such an environment take the usual copy path.

A connection that needs re-authorising now offers Reconnect (Replace access token for self-hosted GitLab). Remove connection keeps environments' repository settings: it names the environments that still deploy through the connection and waits for them. Connections can also be listed and removed through the API and MCP.

AI agents connected to the Control Panel's MCP server can read its guides and playbooks, use its ready-made prompts, and open the log viewer, usage charts, smoke test and site picker as apps inside the conversation, in AI apps that support them. Every logs query says the exact time window it read.

A deployment's page now says which revision of your company's deployment template, or of Corefinity's default, each stage was built from, and which stages that environment sets for itself.

Use the Feedback button at the bottom right of any page, or press Shift+F, to report a problem, suggest a feature or ask for a new platform. You can add a screenshot of the page and mark it up; passwords and other secrets on screen are hidden automatically.

Set your build, database and after-deploy commands once per platform; every environment follows them and can change any stage for itself.

Every CoreStack site now deploys in three stages, build, database and post-deploy, which you edit on the Deployments tab, each line with its own step and time limit. Existing pipelines are converted automatically, a group of sites at a time, and deploy exactly as before; credentials written into commands are moved into encrypted variables.

Pick the Node.js version and the global npm packages each environment runs, on its Runtime tab. Changes apply straight away, and deployments build with the same version and packages.

AI agents such as Claude Code, Codex and ChatGPT can now work on your CoreCluster and CoreStack sites through the Control Panel's MCP server. Create a token or connect an app under Company settings › MCP & API Access; every call is recorded there.

Each environment's PHP card now sets its PHP version, the extensions it loads and its own php.ini settings. Every change is checked before it is saved, and the card's history shows what changed and lets you put an earlier version back.

Changes to an environment's PHP settings, nginx rules or Node.js version are applied to the running environment and checked once they are live.

Standard date and time fields in the Control Panel now follow UK time, automatically switching between BST and GMT.

A new empty site or environment now shows a page confirming it is set up, with its services listed, until you deploy your code or upload files over SSH/SFTP.

The Create window describes CoreStack Enterprise as enterprise multi zone managed hosting for high traffic websites.

On Billing, Payment methods, Add card is now in the Cards box in the same style as Set up Direct Debit, and both buttons sit clear of the text above them.

The Billing overview and Usage pages no longer show the note that prices are per hour (the monthly price divided by the hours in the month).

The invoice PDF and the invoice email no longer carry the line about prices being per hour, matching the Billing pages.

When you order while signed in, the Verify step no longer shows a paragraph about your email and two-factor sign-in. The box with your name and the set-up below it say what to do.

On the Review step, an included staging environment is now listed by its name and size, with Included shown once beside it.

While we finish your order, the page checks every few seconds and shows a spinner only while it checks. It says when your site is being retried, or when the region has no room yet.

The email telling you your site takes a little longer to set up no longer says that nothing is charged until then.

The main button in every email from the Control Panel is now Corefinity blue.

Add a card now looks like the rest of the Control Panel. Default and Backup each say what they mean, and anything that goes wrong says what to do next.

With a default and a backup card already saved, Add card explains the limit up front. Menu actions that aren't available yet say why.

The order pages have more room between sections, fields and summary lines, and a long email address in Your order wraps cleanly. When something needs fixing, the page now takes you straight to the message or the field. The Billing step no longer repeats that UK VAT is added: the order summary shows it.

The deployment output is light in the light theme and keeps its dark terminal in the dark theme, on every deployment page. Masked values show as chips, and one line under the log explains how masking works.

Every sign-in screen now shares one cleaner design: the Control Panel login, signing in during an order, password reset, two-factor codes and invitation sign-up. The Google and GitHub buttons carry their official logos, and how you sign in is unchanged.

If you change a pipeline while a deployment is waiting to be run, the deployment now uses your change when you press Run Now.

On the Managed Websites list, each CoreStack Enterprise environment now shows its own name.

A payment method saved with Stripe Link now shows as Link with its masked email. The … menus open above the page without scrolling it, the sign-in page is blue to the bottom of the window, and a request that gets no answer shows a retry message.

On the order page the currency switch always changes the currency before Billing, and says why if it cannot. A buyer who was signed in before ordering gets their email code without pressing Resend, a verified mobile number can be used for sign-in codes in one step, and the authenticator set-up shows its code field in full.

When a buyer who was signed in before ordering confirms their email with the emailed code, the Verify step now says simply that the email is verified.

A CoreStack order is no longer taken when the region has no room for the site and its staging environment. You are asked to choose another region or contact us, and an order already waiting is set up as soon as there is room.

If your bank confirms the card but the save doesn't reach us, Try again now finishes saving it.

Problems on your standalone CoreStack sites now appear in Needs attention, as they do for the sites on your CoreClusters: on the Managed Clusters dashboard, even when you have no CoreCluster, and on each site's own page.

When your company already has an account with us, the Billing step of a new order now fills in your billing address and VAT number and offers the card or Direct Debit your company already pays with, so there is nothing new to enter. Companies that already keep two cards can order straight through too.

A newly created site's storage is now checked as soon as it is set up, so it can take a copy, a branch environment or a files-only or database-only restore straight away. Until that check is done, these requests say the storage is still being set up.

A regular check now keeps each cluster's inventory current, so a site or environment is created straight away, even on a cluster whose configuration has not changed for an hour or more.

A Laravel or Magento 2 site's database details now show application, the name of the database the site uses.

A site or environment whose creation did not complete can now be deleted. It is removed without a final snapshot, as it never held any data.

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) and the change carries on. Your sites move only once the new nodes are ready, as before.

When a deployment fails part way through, the Control Panel now switches the site's scheduled tasks (crons) back on straight away, without waiting for a retry or a stop.

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.

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. Our team is notified automatically.

Retrying a Magento 2 Git deployment whose build had already finished now deploys that same build. A step that ends without a message now says when the connection to the site dropped.

Restoring a snapshot of a large site now gives the copy time in proportion to the snapshot size, up to six hours, rather than 40 minutes.

When you copy a Magento 2 environment's files and database into another environment, the target's own database password is now set first, so its URLs and settings are updated and the copy completes.

When a site's containers are replaced during a deployment, the deployment now waits for the old container to finish shutting down before its next step, so that step always connects to a running container and completes its work.

The list of deployments on an environment, and the full deployments list, no longer need scrolling sideways to reach a deployment's status, dates and buttons, whichever way you opened the page. On smaller screens the Tasks and Duration columns step aside to make room, and both are still on the deployment's own page.

Pressing Retry once on a deployment stopped part way through now starts the replacement straight away, and where a deployment does have to wait, the page says what it is waiting for.

The clock icon on tables that refresh on their own, such as Actions, Tickets and an environment's Deployments tab, is now a labelled Auto-refresh on / off switch. Switching it off keeps every table still as you move between pages, reload or open a new tab, until you switch it back on or log out.

You now stay signed in for up to 12 hours of inactivity instead of 2. Two-factor authentication is still required every time you sign in.

Website names on the deployments screen are now links through to the website's own record, the same as website names elsewhere in the Control Panel.

Breadcrumbs now follow a record's real ownership chain — company, then website, then environment — with every step a link, instead of always pointing back at the listing page.

Passwords have to meet stricter rules when you create an account or change your password, rather than only being eight characters long.

The registration screens keep what you have entered when something needs correcting, and each error is shown against the field it belongs to, including the individual password requirements.

The View icon on a deployment's tasks table now sits at the left of each row instead of off to the right, so it can be reached without scrolling sideways.

An environment's Deployments tab now has a single Deploy button in place of Create Deployment and Deploy Commit. Its page deploys a commit from one of the environment's Git repositories, or an uploaded release archive, and opens on the commit where Git is set up. Once you press Deploy, you land on the new deployment's page to follow its progress.

The Slack channel dropdowns on an environment's Deployments tab show your workspace's channels, so you can choose where deployment alerts go.

Tables across the Control Panel now share one style, with a heading row, dividers and comfortable spacing, matching its other lists.

Deployment output now reads in a single colour, and red is kept for lines that report a genuine problem and for a step that actually failed.

Raise a Ticket on a failed deployment now opens the ticket form with the company, website, environment, department and subject filled in, and the description already written: which deployment failed, when, at which step and with which exit code. Add to it or write over it before you send.

Every link now underlines and deepens in colour when you point at it or reach it with the keyboard, and links on screens such as the ticket header and the dashboard's Websites and Jobs cards are clearly marked as links.

When a deployment fails at Checkout Repository, the task now says what went wrong - that the environment's repository has been changed or removed, or that the commit is not in the repository that was cloned - instead of only "Fetching repository failed!".

Images pasted into a ticket from Google Chat are saved with the ticket instead of linked back to where they came from, so they keep displaying later on.

PDFs and other files attached to a ticket open for anyone who can see the ticket.

Agency users can close tickets for the companies they work with.

Connecting a Bitbucket account goes smoothly all the way through authorisation.

The last step of company registration tells you when an email address is not a valid format, so you can correct it before you continue.

Tab bars across the Control Panel sit against the left edge at their natural width, so each tab is easy to tell apart. Long tab bars still scroll.

Retrying a previous deployment runs its tasks even when there is no crontab backup to restore.

Release archives uploaded for a manual deployment are accepted, including archives that link into their own shared tree. Staff can also download a deployment's release archive.

Bullet points and numbered lists show their markers in ticket replies, and the divider above the delete button sits clear of the end of the message.

Profile > API Tokens now shows each new token in a pop-up so you can copy it, and the confirmation pop-ups for resetting Google 2FA and for verifying your mobile number open in the same way.