v2.1.2

[2.1.2] - 2026-10-14

Tokens limited to selected projects, backups and database copies for classic projects, and engine fetches that cannot reach internal addresses.

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.1 changed how redeploys, the firewall and project isolation work, 2.1.2 is about access, data and safety. An API or MCP token can be limited to selected projects, a project can be protected from token calls, and an allowed project can call the Engine API itself. Classic projects get backups, backup schedules and database copies in staging, clone and push. Every URL the engine fetches is checked against internal addresses. A project's deploy history, environment, files and PHP errors can be read over the API and MCP, and a long list of fixes covers the firewall migration, cancelled deploys, backups and site databases.

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.2

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

Added

Secrets and access

• Project-scoped tokens. POST /mcp-tokens takes projects, and the token then reaches only those projects. PUT /mcp-tokens/{id}/projects changes the list at once. Project and task lists are filtered, other global routes answer 403, and MCP does not list tools the token cannot call. A scoped token cannot change the project's resource limits, PHP and Redis sizing, or its suspension; those stay with the operator. The MCP activity log records the project a call named and filters by ?project=. Tokens without a project list behave as before.
• Protected projects. pae project:settings:set protected on --project=<name> makes every API or MCP token call that would delete, stop or redeploy the project answer 409 project_protected. Nothing runs and nothing is queued. Your own pae commands are not affected, and a token cannot turn the setting off.
• Engine API access for projects. pae system:api-access:allow <project> lets a container project call the Engine API, with a scope of self, all or a list of projects, and --mcp for MCP. On every deploy the app receives PANELALPHA_ENGINE_URL, PANELALPHA_ENGINE_TOKEN, and PANELALPHA_ENGINE_CA when the certificate is not trusted for that name. The firewall opens port 2011 for that project only. deny, list and rotate manage the entries, and a rotated token reaches the running app without a rebuild.
• End SFTP sessions. End the open sessions of one SFTP account or of all accounts in a project, over the API or with sftp_session_kill and sftp_session_kill_all. Deleting an SFTP account ends its sessions first.

Security

• Egress guard. Every URL the engine fetches for you, including git clone and ls-remote, files/fetch, MCP file_url and vault paste checks, is refused with 422 host_refused when it resolves to loopback, link-local, private ranges, or the engine's own and Docker networks. Each redirect is checked again, and a download connects to the address that was checked, so a DNS change in between cannot redirect it. A git token is sent only to the repository's own host. To fetch from a private git or file server, set EGRESS_ALLOW_HOSTS or EGRESS_ALLOW_PRIVATE.

Deploy

• Deploy history. deploy_list, GET /projects/{username}/deploys and pae project:deploy:list list the deploys the engine keeps for a project, newest first: status, install or redeploy, source, branch, commit, times, and the task or webhook that ran it. deploy_log_read reads the log of any of them. The engine keeps 10 deploy logs per project by default (DEPLOY_LOG_KEEP).
• Attach a git source. A container project created without a repository can take one later with project_source_attach or POST /projects/{username}/source. The repository and its token are checked the same way as on create, and the first deploy is queued as a task. A project that already has a source or already runs an app is refused.
• Branches and tags. source_refs lists a repository's default branch, branches and tags without cloning it, before any project exists. Private repositories take a token or a vault: reference.
• Environment variables. env_var_list shows a container project's stored variables, with values masked. env_var_set adds, changes or removes them and recreates only the services that changed, without a rebuild. Variables read at build time still need a rebuild.
• Archive deploy from the CLI. pae project:deploy-archive deploys a local .zip or .tar.gz into a container project created without a git repository, and prints the log as it runs. The archive is removed afterwards, whether the deploy worked or not.
• Default tunnel. pae settings:set default_tunnel none, or the engine-address section of pae configure, gives new projects created without tunnel a name under the engine's own domain instead of a PanelAlpha Online tunnel. panelalpha or an unset value keeps the previous behaviour. /system/info shows the setting.
• Preview tunnels. A tunnel takes purpose (default or preview) and ttl_minutes (5 to 43200). A PanelAlpha Online tunnel created without a hostname gets a free preview-<id>.panelalpha.online name. A preview tunnel lives 24 hours unless you give it ttl_minutes, and expired tunnels are removed every five minutes. A WordPress site may still redirect a preview name to its own domain.

Backups

• Classic-project backups. Classic projects now also back up and restore: the home directory and one dump per project database. A backup can take only files or only databases, with a note. A restore swaps the home in with rollback, or extracts over it, and never extracts as root into a directory the account can change. A classic backup does not include the project's PHP configuration.
• Backup schedules. GET, PUT and DELETE /projects/{username}/backup-schedule, or pae project:backup:schedule, keep one UTC cron schedule per project, at most hourly, with keep_last from 1 to 365. A busy project is retried for an hour. Only scheduled backups are pruned.
• Backup download. backup_item_download and pae project:backup:download download one item of a backup from local, S3, FTP or SFTP storage.

Databases

• Database copies. A classic staging copy or clone now also copies every database the source owns, with new users and passwords and the same grants (copy_databases, on by default). Copied routines, triggers, views and events run as a project user, not as root. The copy serves the copied site instead of the engine placeholder. A push takes files and databases, both on by default, takes a rollback dump of each target database first, and keeps the target's users and passwords. Cancelling a queued push leaves the target free for other work.
• Push selected tables. On a classic project, a push can replace only the tables you name, each after a rollback dump. project_push_diff lists the tables whose structure or data differ between the source and the target.
• Database rename. mysql_database_rename renames a project database and moves its grants. The old database is dropped only after the new one is complete. If the rename fails, the old database and its grants stay as they were.

Files and diagnostics

• Directory listing. file_list lists a directory as the project's account: type, size, modification time, mode, owner and link target, up to 20000 entries. A path through a link out of the home is refused.
• Image thumbnails. GET /projects/{username}/files/thumbnail returns a WebP thumbnail of a PNG, JPEG, GIF or WebP file, 16 to 1024 px, with caching headers. The format is read from the file's content, so an SVG named .png is refused. Files over 50 MB or 50 megapixels are refused.
• PHP error log. Classic PHP hosting writes PHP errors to a log per project, rotated at 10 MB. php_error_log_get reads the last lines, up to 5000. On a container project it reads the app container's output. The update adds the setting to existing projects, and it takes effect when the project's PHP handler next restarts.
• Task list. task_list lists tasks newest first, filtered by project, status, action or time, so a client can tell whether anything is running on a project. By default a token sees its own tasks and the tasks the engine started itself. A push now runs as a task and answers with its task_id.
• Disk usage. metrics:projects:disk measures every project every 15 minutes, in the background, and keeps 30 days. Each project in the API carries a disk block with files, Docker data, total and limit. Project usage now includes the project's Docker data (images, build cache, containers and volumes), which is usually most of its disk.

Changed

Deploy

• Git submodules. Submodules are fetched on every git deploy, including a pull, a branch change or a webhook redeploy, not only on the first clone. A submodule that cannot be fetched now fails the deploy with git's own reason; it used to only warn. git: {submodules: [...]} in the app config names the only submodules to fetch.
• Cancelled deploys. A cancel ends the deploy and its task as cancelled, also while cloning and during the final health check, and never takes do...

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 `...

v2.1.0

[2.1.0] - 2026-09-30

One-line app installation command: go from a fresh VPS to a hosted application with a single command. More applications and less work for your assistant come with it.

One-command installation of "any repository" is our answer to the growing number of open source projects. In many cases, developers still expect users to know how to prepare a server, configure Docker, run a few commands and then simply hope that everything works.

With PanelAlpha Engine, we want to make this process as simple as possible. And with an AI agent connected, not only the installation but also the ongoing maintenance can become something you no longer need to worry about.

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.0.1 brought more control over assistants and day-to-day hosting, 2.1.0 makes it easier to get an application online and keep it there. The engine now ships more than 800 application recipes, can install itself and deploy your first repository with the one-line app deployment command, and gives your assistant the tools it needs without loading the whole catalogue into every conversation. A lighter idle engine, more reliable rebuilds, and clearer answers when a deploy fails round out this release.

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

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

Added

Deploy

• One-line app installation command. Add --repo to the installer to go from a fresh VPS to a hosted application. The engine picks a project name, deploys the repository, and prints the HTTPS address and the password that opens the site. --branch selects a branch, --git-token supplies a token for a private repository, --password sets your own password, and --no-password leaves the site open. If the deploy fails, the engine stays installed and ready to use.
• More than 800 application recipes. This release adds 673 recipes and removes one, up from 188 in 2.0.1. Examples: Actual Budget, BookStack, Immich, Open WebUI. A project created from one of these repositories picks up its recipe on its own and sets up the services, storage, and settings the application needs. Some applications still need their own first-run setup or credentials.
• Admin login. For many recipes the engine generates the administrator username and a strong password, sets the application up with them, and keeps them across deploys and rebuilds. Your assistant returns the sign-in address, username, and password on request. The password is not written to the deploy log. A password changed later inside the application is not reflected.
• More repositories without a recipe. The engine now recognises plain PHP projects without a Composer file, Next.js applications inside a workspace, and usable Compose files in a subdirectory.

MCP

• Tools on demand. The assistant starts with the tools for deploying, checking, and running projects. It finds the rest with search_tools and calls them with execute_tools, so the full catalogue is no longer loaded into every conversation. Permissions still decide what it can find and run. A setting keeps the previous full list for clients that need it.
• Paged logs and files. A deployment log or text file is read or downloaded in pieces, and the next request continues where the last ended. Paging no longer skips lines between requests. Large files and logs do not arrive in one oversized tool response.

Diagnostics

• Known fixes on failed deploys. With telemetry enabled, when PanelAlpha monitoring recognises a failure, the deploy result includes its explanation, the suggested fix, and the engine version that fixes it. For an unknown failure, or when monitoring is unavailable, the engine's local diagnosis is returned.
• Unfinished application setup. Health checks detect an application that serves its installer instead of a finished site. The deploy still succeeds, and the finding asks you to finish setup before someone else claims the administrator account.

Resources

• Memory limits. Every project has a memory limit. Without one, a project may use the server's RAM minus the engine's reserve (512 MB by default), and both the default and the reserve are configurable. A project's limit is checked against that maximum. The combined limits of several projects can still exceed the server's RAM.
• Disk quotas. The installer enables project disk quotas automatically on ext4. On XFS it says what to change and whether a restart is needed. Where quotas cannot be enabled, it says so instead of implying that a recorded limit is enforced.
• More settings in pae configure. pae configure sites-db sets the memory kept for the database of hosted PHP sites. Applying it restarts that database briefly. pae configure csf-ui turns the CSF firewall web interface on or off; it is off by default.

Changed

Install and update

• One command to install or update. The same curl command updates an existing engine. --repo on an existing VPS deploys another project. --update-engine updates the engine first, and --deploy-only deploys without updating. Hosted websites keep running during the update, and your assistant reconnects after the engine restarts.
• Lower idle memory. The engine keeps fewer idle PHP workers, recycles queue workers, and uses smaller default caches for the database of hosted PHP sites. The database caches can be raised when sites need them.

Secrets and access

• Vault secrets are per project. A vault secret belongs to one project by default. Several global Git or Cloudflare tokens can be kept, and a project selects one by its vault:<id> reference. A global token is no longer applied when a request omits a token. Deleting a vault entry does not revoke a credential already stored on a project.
• Read-only MCP access. Read-only access no longer includes the calls that return firewall credentials, outgoing-mail credentials, an application login session, or an application's generated admin login.

Builds

• Runtime detection. A Node project that names no version gets Node 22. Version requirements and package-manager files are handled more reliably for Node, Python, Ruby, Java, Go, and Rust. Vite sites serve the output directory named in their build configuration.
• Build memory. Host builds run one at a time by default. The build memory allowance scales with the project limit, within the server's budget, and the deploy log states how much memory the build received and why. A fixed build allowance can be set. It is separate from the application's runtime limit.
• Build network. By default, host build containers can reach the internet for dependencies, but not the engine, the host's private network, or the cloud metadata endpoint. Servers that use private package registries can change this.
• Low disk check. A deploy checks free space first and refuses to start when less than 3 GB remains on the storage it needs. The message says what to free and points to pae system:image:prune. The threshold is configurable.
• Image cache and cleanup. Projects pull missing image layers through the host's cache, and the engine refreshes its prepared base images weekly. A daily cleanup removes unused host images and build caches, and waits while a deploy is running. Account disk cleanup no longer needs to stop its Docker daemon.

Runtime

• Rebuilds keep secrets and storage. Corrected recipes retain generated encryption keys, database passwords, and stored uploads across redeploys. This fixes regeneration or loss on each redeploy for WordPress, Paperless-ngx, Plausible, Umami, Wiki.js, and others. A custom deployment must declare its own persistent storage.
• Public URL and database credentials. Compose applications and recipe-based deployments receive the site's public URL where their settings expect it. Generated database credentials reach the services that need them, and startup waits for service readiness. This fixes containers that could not reach their database or redirected to the wrong address.
• Visitor IP on PHP sites. Apache-backed PHP applications receive the visitor's address through the engine's proxy, so application logs and address-based rules no longer see the proxy's address.

Deploy errors

• Clearer failure messages. A build failure names the failing step and its cause instead of reporting image-pull progress as the error. Health checks explain why a running application is not answering, which makes missing settings, unavailable dependencies, and memory problems easier to tell apart.

v2.0.1

[2.0.1] - 2026-09-23

Follow-up to the 2.0.0 launch. The Engine now uses less memory and a smaller queue, adds recipes for 188 applications and support for deploying from their own repositories, and gives you more control over assistants before they touch the server. Passwords, push webhooks, statistics, files, and PHP settings are now easier to work with directly too.

This one is more of a technical update. There are no major changes in direction here, just a few things we wanted to get into 2.0 but didn’t quite make it in time, plus a few smaller things we cleaned up at the same time. Rather than wait for another major release, we wanted to roll them out as soon as they were ready, so everyone can start using them right away.

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!

Install on a fresh Debian or Ubuntu VPS:

curl -fsSL https://get.panelalpha.com/engine | sh

Read the announcement: PanelAlpha Engine 2.0.1

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

Added

Security

• Password protection. Pass a password when you create the project, or set it later with pae, the API, or MCP. It covers every domain of that project. The gate is nginx-proxy; other web servers cannot set one.
• Assistant access. pae configure sets a ceiling: full, modify, or readonly. A token is for the API or for MCP, and it can be limited to named operations. The assistant's tool list shows only what that token may call. A revoked token is refused on both.
• WordPress logins. The WordPress hardening ruleset refuses an author query and an anonymous listing of users. It is off until you enable it, the same way the other rulesets are. A signed-in editor can still list users.

Applications

• Application recipes. The engine ships recipes for 188 applications. A project created from one of those repositories picks the recipe up on its own: how to build it, and how to close an open installer or a published password before the site is reachable. A repository without a recipe deploys as before.

Git

• Git webhook. You create the hook. A push to the tracked branch updates the checkout and rebuilds the project. GitHub, GitLab, and Bitbucket are accepted, and the delivery is checked before anything runs. Other branches are ignored. A WordPress checkout only fast-forwards, so files already on the server stay.

Statistics

• Bandwidth usage. A project already had a transfer limit. 2.0.1 reports how much was actually used: current transfer next to the limit, and a daily or monthly series. Every response is counted, crawlers included, so the number is higher than a visitor chart. Only traffic after this update is counted.
• Visitor statistics. Per domain: how many came, how often, which pages, which site sent them, and which system and browser they used. Country, continent, and region appear once you install the city database with pae geolocation:database update. It is not installed for you, and the lookup stays on this server.

Hosting operations

• File operations. Move a folder's contents in one step, fetch a file from a web address into the project, and set a path's permissions. The same calls are MCP tools. They join the file operations that were already there.
• Per-domain PHP. A domain can have its own directives (memory_limit, upload_max_filesize, max_execution_time, and the rest). Account settings stay the default; the domain overrides them for that site only. The same get and set operations are MCP tools.
• Ports on inspect. Inspect reports the port the engine routes, the ports that need a proxy rule, and the ports that stay unpublished, such as a database, with the reason. The same inspect reads the recipe and the submodules the deploy reads, so a repository it calls undeployable is one that will not deploy.

Settings

• Settings wizard. pae configure walks the engine's settings: which MCP tools are exposed, the address and certificate, telemetry, the queue, API and MCP tokens, and connecting an assistant. Nothing is written until the result is confirmed. The same values can still be edited by hand.

Changed

The install

• Less memory. Redis is gone, and a new install no longer runs MariaDB for the engine itself. The engine uses less memory. Databases that belong to your projects are unchanged. An install that already keeps the engine's own data in MariaDB keeps that database.
• A smaller queue. The default is two workers instead of eight. pae configure queue changes the count without recreating the container. A host that never set the count runs two.

Docker Hub

• Docker Hub on the host. Give the engine a Docker Hub login once. Pulls from this VPS then count against that account, not against the free limit on the address. The login stays on the host. A project never sees it.

Tokens

• Check the repository first. The repository and its token are checked before the engine creates the project. A URL that cannot be cloned, or a token that cannot read the repository, is refused then, with what was wrong and what to send instead. A Git or Cloudflare token pasted on the vault page is checked before it is saved.
• One Git token, one Cloudflare token. Paste each once for the engine. Every project that has none of its own uses it. A token set on the project still wins. Keeping tokens per project is a setting, and it is off by default. Creating a secret that already exists is refused, so a paste cannot overwrite it in silence.
• PanelAlpha Connect. The engine calls https://connect.panelalpha.com. A host that set PANELALPHA_HUB must rename it to PANELALPHA_CONNECT. The old name is not read.

PHP

• One PHP version at a time. An account write applies to the version you name. It used to copy the same map onto every installed version.

Deploys

• A failed deploy says where. A failed rebuild names the stage that failed. A pull that dies on a damaged layer says so, instead of blaming a missing base image. A repository URL that includes a GitLab subgroup is addressed correctly.
• What gets built. An open Node range, such as >=18, resolves to Node 20, not the oldest major that still matches. The engine builds the Dockerfile the project meant to ship, and it finds a Dockerfile that is on disk. A PHP site does not print errors into the page. A checkout with no front controller is not published whole. A one-shot task that exits in error fails the deploy, and the engine does not treat the Erlang port mapper as the site.
• Firewall, archives, and SFTP. On a host where CSF is already installed, the engine's firewall rules are applied, so an app on a port other than 80 or 8000 answers. An archive uploaded onto a project that deploys from git is refused before any file is replaced. SFTP logins work, and removing a project removes the login.
• Review fixes. A Compose file cannot keep options that amount to a privileged container, or bind the host's root and daemon state into the app. An uploaded archive is refused when unpacking it would pass the size limit. An application's sign-in redirect stays on this engine. A project's disk usage counts its files, not the engine's images under that account.

v2.0.0

[2.0.0] - 2026-09-16

First public, open source release. Apache 2.0.

Releasing PanelAlpha Engine as Open Source was the biggest (and the most exciting!) milestone for us this year. With this move, we not only want to show the new direction of our product and respond to the new trends on the market, but also invite you to build it together with us. I believe that building a community around PanelAlpha Engine is the only way to turn it into a new standard for hosting and make servers ready for the AI era.

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!

Engine 2.0 is a new product, not a polish of 1.x. Git, backups and staging now live in the engine instead of the panel. Everything else below is new: Docker-in-Docker hosting, MCP, app recipes, the secret vault, and telemetry.

Install on a fresh Debian or Ubuntu VPS:

curl -fsSL https://get.panelalpha.com/engine | sh

Read the announcement: PanelAlpha Engine 2.0

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

Added

Deploy any stack

• Deploy from git. Point the engine at a public or private repository. It clones the code, detects the stack, builds it, starts it, and gives it HTTPS. Private repos use a git token pasted on a vault page, never in the chat.
• Deploy from files. Upload an archive when the code is not in git. Later updates rebuild from the files already on the VPS, or from a new archive.
• Any application. PHP, WordPress, Laravel, Node, Next.js, Django, Python, Go, Rust, Java, a Dockerfile, a Compose file, a folder of HTML. The engine looks at the repository and works out how to run it.
• App recipes (panelalpha.yaml). Put a .panelalpha/ directory in the repository to say how that app should be bootstrapped. The engine also ships recipes for known apps.

Isolation and Docker

• Docker-in-Docker, isolated with Sysbox. Each project runs in its own container, with its own disk, memory and CPU limits. One broken app cannot take the others down.
• Cached images on the host. Base images stay on the VPS, so the next deploy of a similar stack does not wait on Docker Hub.

Domains, TLS, Cloudflare

• A free panelalpha.online hostname on every project, with HTTPS, the moment it exists. Attach your own domain when you are ready; Let's Encrypt issues and renews the certificate.
• Cloudflare tunnels. Serve a site through Cloudflare instead of opening the VPS to the internet. Built for servers behind NAT, homelabs without a public IP, and anyone who does not want to point an A record at the machine.

Hosting operations (moved from the panel)

These used to live in the PanelAlpha panel. In 2.0 they run on the engine itself.

• Git on the project. Pull, switch branch, or go back to the last deployed commit, then rebuild.
• Backups and backup stores. Snapshot a project's files, volumes and databases to a local folder, S3, FTP or SFTP, and restore it.
• Staging and push. A linked copy with its own hostname. Push staging live when you are happy, or the other way to refresh the test copy with real data.

Control: MCP, API, CLI

• MCP, 182 tools. Connect the assistant you already use (Claude Code, Cursor, Codex, Gemini CLI, and others). It deploys, debugs and looks after the server through the engine, never as root.
• REST API. Full server management over HTTP. The same operations as MCP.
• pae CLI. The same work from SSH when no assistant is connected.

Health, telemetry, secrets

• App health checks. Ask whether a project is still serving itself, over MCP, the API or pae. The engine also probes every deployed app on a schedule.
• Telemetry. Anonymous reports about deploys and later health, so a failure that shows up on many installs can be fixed in the product. Optional email alerts if you give an address. Off with pae telemetry:disable. Nothing about your source, tokens, or visitors is sent.
• Secret vault. When a private git repo or a Cloudflare tunnel needs a token, the assistant creates a one-hour URL. You paste the token there. The assistant never sees it.

Changed

• Rebuilt core. The engine is no longer a remote worker for the panel. Hosting operations run here. The codebase is structured around Docker-in-Docker accounts; classic PHP hosting accounts remain supported.