The deploy dialog has a new Commit field that lists the latest commits on your branch. Pick one and that deployment builds it instead of the branch head. To keep an application on one commit, enter it under Pinned commit on the Settings tab. Every deployment then builds that commit, including the ones a push triggers, until you remove the pin.
Before: Every deployment built the latest commit on the branch, and you could only roll back to versions you had deployed before. After: Build any commit on the branch, including one you never deployed, and keep the application on it while the branch moves on.
You can now connect a Gitea instance under Settings > Connections and deploy applications from its repositories. Enter the address of your instance and a personal access token. A label is optional and helps when you connect more than one instance.
Before: Ploi Cloud deployed from GitHub, GitLab and Bitbucket. After: Gitea repositories work the same way, including a deployment on every push.
PHP applications have a new Custom PHP ini settings field in the PHP runtime settings on the Settings tab, under Show all settings. Enter php.ini directives, one per line, and your next deployment writes them into the image. PHP loads them last, so they override the image defaults and the runtime settings above the field.
Before: You could only change the PHP settings the dashboard offered. After: Set any php.ini directive, such as apc.enable_cli=1.
On October 21 PHP released fixes for CVE-2026-109618 and CVE-2026-109619. Both let an attacker run code on a server with one web request, without logging in. We rebuilt every PHP application on Ploi Cloud with the fixed versions, so you didn't have to redeploy.
PHP 7.4, 8.0 and 8.1 are end of life and got no new release. For those versions we applied the PHP security team's patch ourselves and built our own images, for PHP applications and for WordPress.
Because of PHP security advisory CVE-2026-115560, every PHP application now builds with session.upload_progress.enabled=0. The line is in the new Custom PHP ini settings field and takes effect on your next deployment. If your application tracks upload progress through the session, remove the line or set it to 1.
Applications with the imagick PHP extension, and all WordPress sites, now build with a stricter ImageMagick policy that blocks the formats behind most ImageMagick exploits. Imagick can no longer fetch URLs, run MSL scripts, read files through @ paths or open PDF, PostScript and EPS files. The policy applies from your next deployment.
Builds now send your Git access token in a request header instead of putting it in the repository address, so it can't show up when Git prints that address in its output.
Backslashes and quotes in the names and values of your security headers are now escaped correctly.
The Sync status button on object storage works in every state except while it's being deleted. We also check the status of every object storage each night, not only running ones. When a custom domain failed to register, the next status check tries again.
Saving the Settings tab, for example after adding a domain, turned off your security headers and cleared your custom headers and SSL settings. Saving settings now leaves them as they are.
Applications attached to a network couldn't connect to your managed databases. They can now.
When you changed an application's networks, some of the old access rules stayed in place. A change now replaces the previous rules completely.
The autoscaler couldn't read the load of applications running Nightwatch or Inertia SSR, so it didn't scale them. It now reads the load from your application itself.
The autoscaling metrics of applications in other regions didn't load, because we looked them up in Amsterdam. Each application now gets the metrics from its own region.
Some workers failed to deploy because of how their number of instances was saved. They deploy normally again.