v2.1.1

[2.1.1] - 2026-10-07

Zero-downtime redeploys, ufw and fail2ban in place of CSF, and project network isolation.

Less exciting update, but still an important step toward making Engine more reliable and secure for production use, especially during redeploys and day-to-day operation. It is also another step closer to getting it live with our control panel (coming soon).

Konrad Keck - CEO & Founder

An important note for current users: if you’re using PanelAlpha together with the Engine, please stay on your current version for now. Making the Control Panel ready for 2.0 is the next milestone on our list, and work on that is already in progress. Thanks for sticking with us for this next step!

After 2.1.0 took a fresh VPS to a hosted application in one command, 2.1.1 changes how redeploys, the firewall and project isolation work. Eligible redeploys start the new version beside the running one, ufw and fail2ban replace CSF, and isolated projects cannot connect directly to the engine API or each other. Rebuilds run as background tasks, the host disk is checked every five minutes, and a project can declare worker processes, persistent paths, registry logins and a deploy key.

Install on a fresh Debian or Ubuntu VPS and deploy your first application:

curl -fsSL https://get.panelalpha.com/engine | sh -s -- --repo https://github.com/n8n-io/n8n

Replace the repository URL with your own, or leave out -s -- --repo … to install just the engine.

Read the announcement: PanelAlpha Engine 2.1.1

Documentation: panelalpha.com/documentation/panelalpha-engine · Discord

Added

Deploy

• Zero-downtime redeploys. For eligible projects, a rebuild starts the new version beside the running one and moves the site only when the new version answers with a page. A server error or an empty page does not count. If it never answers, the deploy fails and the previous version keeps serving. Proxy rules you added for the app's port move with it. A project behind a Cloudflare tunnel, a repository Compose file with more than one service, or a service that publishes a port range or a UDP port is replaced in place with an interruption, and the deploy log says why.
• Procfile workers and release commands. When the engine generates the Compose file, workers listed in Procfile run beside the application from the same image, with no public port. They restart if they stop. A worker is skipped if a service already uses its name. release: runs once on every deploy, before the application starts. If it fails, the deploy fails and the running version stays up. Repository Compose projects and static sites served by the engine's nginx image do not use these.
• Persistent paths. The persist-paths project setting keeps what the application writes under the listed container paths, such as uploads or a directory containing a SQLite database, on volumes of the project's own across redeploys and rebuilds. Paths already mounted are left unchanged. A project with its own docker-compose.yml declares its volumes there instead.
• Private registry logins. The registry-auth project setting holds one host username token line per registry, for images on ghcr.io or a private Docker Hub account. The Docker login file is present in the project only while a deploy runs, and an image it covers never passes through the server's shared image cache.
• Git deploy keys. The engine creates an SSH deploy key for a project and shows its public half, which you add to the repository as a read-only key instead of a personal token. The private half stays encrypted on the engine. Host keys for github.com, gitlab.com and bitbucket.org are pinned; another git server is pinned when you name it with --host or through the assistant. Ask your assistant, or run pae git:deploy-key on the server.
• Generated admin logins. For applications whose recipe declares a login, the engine creates a username or email and a strong password on first deploy, stores them encrypted on the project, keeps them across redeploys, and returns them through the API and MCP together with the login URL when the recipe names one. Ask your assistant for the admin login of a project.

Security

• ufw and fail2ban. ufw replaces CSF as the server firewall. Host ports and the ports Docker publishes for containers have separate rules, and a deny covers both. fail2ban watches SSH, SFTP, FTP and the engine API on port 2011, and bans an address for an hour after 5 failed logins in 10 minutes (10 for the API), longer each time it returns. Trusted addresses are never banned. The engine's own port rules cannot be changed or removed through the assistant. A server that ran CSF is moved on update: its allow and deny lists become ufw rules and its configuration is saved under /var/backups. The CSF web interface on port 2012 and pae configure csf-ui are removed.
• Project network isolation. Projects can reach the internet, the server's MySQL and image caches, and the server's mail and web ports. Direct connections to other projects, the engine API, FTP, SFTP, phpMyAdmin and private addresses are blocked. The update attempts to move existing running projects. Applications using the server's MySQL may restart during the move, and their sites are unavailable until they answer again. Start a project that was stopped during the update, then move it with pae project:network:move --project={project}. Retry a failed move with the same command.
• Custom ModSecurity rules. Your own WAF rules go into a custom ruleset, written through MCP or the API. Rules are parsed and run once before they replace the live set. A rule that does not parse, switches ModSecurity off or to detection-only, or denies an ordinary request is refused, and the rules in place keep working. Rule ids are 1100000 to 1199999.
• Project proxy rules. A proxy rule that belongs to a project may only point at that project's own app and use the project's own domains. Another project, the database server, the engine API, the image registries and the host's addresses are refused. These project restrictions do not apply to system rules.
• Read-only image cache and Compose checks. Projects can pull from the shared base-image cache but not push to it or delete from it. A repository's Compose files are checked after include, extends, variables in bind paths and committed symlinks are resolved, so a service cannot gain privileges, host networking or the project's Docker socket through them.

Operations

• Disk guard. system:disk:guard runs every five minutes. It keeps host build cache under 10G, and when free space on the Docker root or /home falls below 15% it prunes build cache, then asks the image cleanup to remove base images unused for 6 hours. Image cleanup waits while a deploy is running. During a deploy, disk is measured every 15 seconds, and the deploy is stopped when the project passes its disk limit or the host storage it needs falls below 3G by default.
• Unreadable secrets warning. When stored secrets no longer decode with the engine's encryption key, the project names them (env values, Git and Cloudflare tokens, registry logins, the site password) and warns that the next save, a redeploy included, stores them empty. System info lists every project affected. The app database password is kept, and deploys are refused until it decodes.
• Container logs. container_service_logs reads up to 5000 lines and filters them by since and until, a time or a span such as 2h. The API also follows a service's log live for up to 10 minutes. Project usage includes the disk its container logs take.
• Mail DNS check. domain_mail_dns_get lists the SPF, DKIM, DMARC and MX records a domain needs for mail sent through the server, and reports each as ok, missing, wrong or unknown. DKIM is checked when you give the relay's selector. The engine does not sign mail itself.
• HTTP status codes in visitor statistics. The visitor breakdown takes status_codes: requests and bytes per HTTP status for exactly the dates you name. 200 and 304 share one row.
• gzip and Brotli. The engine's webserver enables gzip and Brotli for every site. Text responses of at least 1024 bytes are eligible; the client must request a supported encoding.

Changed

Deploy

• Queued rebuilds. project_rebuild, project_deploy_archive, and a git pull, branch change or revert on a project managed by deploy answer at once with a task to follow with task_get. A second request while a deploy is queued or running is refused with its task id, or a null id when the deploy was started outside the task queue. Over the API, POST /projects/{username}/rebuild and /deploy-archive answer 202 with a task instead of 200 with the project by default. Clients that request the deploy log as a stream still wait for completion. pae project:rebuild still waits for the rebuild to finish.
• Project delete. A delete is refused while a deploy, rebuild, staging copy, push, backup or restore is running on the project, and changes nothing. Work still queued for it is cancelled first.
• Image prewarm. A fresh install keeps no base images ready. pae configure prewarm selects the images to keep, and sets the disk budget (6G) and reserve (10G). The first deploy that needs an image builds or pulls it.
• Health checks. The deploy probe sends the forwarded headers a visitor's request carries, so an app that refuses plain HTTP is no longer reported broken. An empty 2xx front page counts as not serving in every runtime, and so does a restart loop in a stack with no published port.
• Stack detection. Builds without a recipe handle Go programs that embed a frontend or keep main under cmd/, a newer JDK when javac asks for one, Rails jsbundling and cssbundling assets, Rust build scripts that need protoc, cmake or libclang, Angular workspaces with several projects, Yarn PnP, SvelteKit adapters, .NET publish directories and Quarkus jars.
• Recipes. New recipes for Overleaf, DOMjudge, Anubis, Pomerium and Memos. DOMjudge needs a separate judgehost to process submissions; Anubis and Pomerium initially serve a placeholder until you set their upstream application. Galette and PieFed setup is corrected, and JARR uses its current repository.

Runtime

• Supervised PHP hosting services. On PHP hosting, PHP handlers, Apache, Redis and cron run under s6 and restart when they exit. On container projects, application services with a restart policy come back automatically after the project's own Docker restarts.
• gRPC, TCP/UDP rules and large headers. gRPC over HTTPS reaches the application over HTTP/2 with its trailers. Response headers up to 64 KB pass the engine's webserver instead of returning a 502. TCP and UDP proxy rules load, get an open port and listen on IPv6. X-Accel-Buffering: no from an application reaches the client, so streamed responses are not held back.

Install and update

• Update checks. An update removes containers and files the new release no longer has, and fails, naming the service, when an engine service did not start or has no network. This fixes an update that reported success while a service was down.