Version 2.1.0
Read more on PanelAlpha Blog: PanelAlpha Engine 2.1
Konrad KeckA word from the founder
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.
New Features
- One-line app installation command. Add
--repoto 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.--branchselects a branch,--git-tokensupplies a token for a private repository,--passwordsets your own password, and--no-passwordleaves 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.
- Tools on demand. The assistant starts with the tools for deploying, checking, and running projects. It finds the rest with
search_toolsand calls them withexecute_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.
- 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.
- 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-dbsets the memory kept for the database of hosted PHP sites. Applying it restarts that database briefly.pae configure csf-uiturns the CSF firewall web interface on or off; it is off by default.
Improvements
- One command to install or update. The same
curlcommand updates an existing engine.--repoon an existing VPS deploys another project.--update-engineupdates the engine first, and--deploy-onlydeploys 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.
- 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.
- 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.
- 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.
- 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.