Skip to content

v2.0.1

Choose a tag to compare

@wiluszdamian wiluszdamian released this 23 Sep 14:07

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