Making the new generation of PanelAlpha Engine more reliable and secure for production use is one of our highest priorities right now. At the same time, we are working toward full compatibility between Engine and our Control Panel. These two efforts are closely connected: Engine has to be dependable enough to run real projects day after day, and the Control Panel has to be ready to build on that foundation.
After 2.1.0 release made it possible to go from a fresh VPS to a hosted application in one command, PanelAlpha Engine 2.1.1 focuses much more on what happens after the first deploy: how safely you can redeploy, how strongly projects are isolated, and how reliably the server handles everyday operation.
Already using PanelAlpha together with Engine? Please stay on your current Engine version for now. Full Control Panel compatibility with the 2.0 generation is still in progress, and getting it ready is the next major milestone on our list.
What 2.1.1 changes in practice
This release touches several different parts of Engine, but they all move in the same direction. The goal is to make production use safer, give projects clearer boundaries and reduce how much manual work is still needed once the app is running.
Move traffic only when the new version is ready
For eligible projects, Engine now starts the new version beside the one that is already running and checks it before moving the site over. If the new version never becomes healthy, the previous version keeps serving. Rebuilds can also run as background tasks, conflicting deploys are refused, and important operations such as project deletion are blocked while a deploy, backup or restore is still running. The result is a much safer path from one version of an application to the next.
Projects stay in their own lane
Projects can still reach the internet and the shared services they need, but direct access to other projects, the Engine API and private addresses is blocked. Project proxy rules are limited to the project’s own application and domains, while repository Compose files and access to the shared image cache are checked more strictly. A project gets what it needs to run without getting an easy path into parts of the server it should not reach.
Better protection around the server itself
ufw now replaces CSF, while fail2ban watches SSH, SFTP, FTP and the Engine API for repeated failed logins. Existing CSF allow and deny rules are carried over during the update, so moving to the new setup does not mean rebuilding them from scratch. Custom ModSecurity rules also go through checks before they replace the live set, helping prevent a bad rule from weakening protection or blocking normal traffic.
Catch problems before they become bigger ones
A new disk guard checks the host regularly, keeps build cache under control and starts cleaning when free space gets too low. During a deploy, Engine watches storage more closely and stops before the project passes its disk limit or the server runs out of the space it needs. Engine also warns when stored secrets can no longer be decrypted, while update checks now confirm that Engine services actually started and have a working network before reporting success.
More real-world applications fit the normal flow
Procfile workers can now run beside the main application, release commands can run before a new version starts, and persistent paths can keep uploads or SQLite data across rebuilds and redeploys. Engine can also create read-only SSH deploy keys for private repositories, while private registry credentials are available only for the time a deploy needs them.
Automatic stack detection has also grown to cover more Go, Java, Rails, Rust, Angular, Yarn PnP, SvelteKit, .NET and Quarkus setups, with new recipes for Overleaf, DOMjudge, Anubis, Pomerium and Memos. This allows more projects to follow the standard Engine flow without extra manual setup.
More of the everyday details covered
The update also brings a longer list of smaller improvements that make Engine easier to inspect and more dependable in everyday use. Container logs can now return more history, be filtered by time and followed live through the API. Engine can check the SPF, DKIM, DMARC and MX records needed for server mail, while visitor statistics can break traffic down by HTTP status code.
The runtime gets broader support too. PHP services are supervised and can restart when they exit, gzip and Brotli are enabled for sites, and Engine handles more gRPC, TCP/UDP, large-header and streamed-response cases correctly.
Want to support what we’re building?
GitHub is where the work behind each release happens in the open, and leaving a ★ goes a long way in helping more people to discover the project too. You can also open an issue, share a use case or jump into the code. We’d love to have you there!
Follow Engine on GitHubStill heading the same way
We want each release to remove more of the server work you still have to handle yourself. Sometimes that means a new feature, sometimes stronger safeguards, and sometimes simply making everyday tasks easier to trust.
We are going to keep releasing improvements this way: regularly, as soon as useful changes are ready, and with the same goal in front of us. We want PanelAlpha Engine to become the easiest way to host projects on your own server. The next step is already in motion. Let’s keep building!
Comments