{"id":3267,"date":"2026-09-23T15:47:21","date_gmt":"2026-09-23T13:47:21","guid":{"rendered":"https:\/\/www.panelalpha.com\/blog\/?p=3267"},"modified":"2026-09-23T19:30:03","modified_gmt":"2026-09-23T17:30:03","slug":"panelalpha-engine-2-0-1","status":"publish","type":"post","link":"https:\/\/www.panelalpha.com\/blog\/panelalpha-engine-2-0-1\/","title":{"rendered":"PanelAlpha Engine 2.0.1: Getting more of the details right"},"content":{"rendered":"

One week ago, PanelAlpha Engine<\/strong><\/a> entered its 2.0 generation with one very clear goal: make hosting projects on your own VPS as easy as possible<\/strong>. The server is yours, every infrastructure decision stays yours to make, and the AI assistant you already use can take over much of the work that would otherwise pull you into server administration.<\/p>\n\n

Engine 2.0 gave us the foundation for that. It is open source, it is no longer tied to WordPress, and it gives AI assistants a safe way to deploy and manage different kinds of applications on a VPS. But 2.0 was never meant to sit still.<\/p>\n\n

We are actively collecting feedback, paying attention to the problems people want Engine to solve and looking for anything that can be made simpler, lighter or easier to control. The plan is to turn what we learn into regular updates instead of holding improvements back for another large release months from now. So, exactly one week after 2.0, PanelAlpha Engine 2.0.1 is here.<\/strong><\/p>\n\n\n\n

Less to set up, more to control<\/h2>\n\n\n

Making self-hosting easier is not just about getting an application online. Too much unnecessary work still happens around the deployment itself: securing a project before anyone should see it, entering the same credentials again, checking whether an integration actually connected or manually working out what an AI agent should and should not be allowed to do. 2.0.1 cuts more of that work out.<\/p>\n\n\n\n

\n\n
\n

01<\/p>\n

Projects can start private<\/a><\/h3>\n

Password protection is now built directly into Engine, including MCP and the API. You can set it while creating the project, so a staging site, internal app or unfinished project is protected from the start. When working through an AI assistant, protection can simply be part of the original request.<\/p>\n<\/div>\n\n

\n

02<\/p>\n

Connect Git and Cloudflare once<\/a><\/h3>\n

Git and Cloudflare tokens can now be stored once for the entire Engine installation and reused across projects. You can still assign a separate token when a particular project needs different credentials, but repeating the same setup is no longer required.<\/p>\n<\/div>\n\n<\/div>\n\n\n\n

\n\n
\n

03<\/p>\n

Know immediately if the connection works<\/a><\/h3>\n

Engine can now test Git and Cloudflare tokens directly in the form. You immediately know whether the credentials work and can fix them on the spot instead of discovering the problem later when the AI agent tries to use them.<\/p>\n<\/div>\n\n

\n

04<\/p>\n

Decide how much access the AI gets<\/a><\/h3>\n

Engine now gives you three AI access modes, switchable from the CLI: full access, confirmation for higher-risk actions, or a restricted mode that blocks them completely. This lets you set different boundaries for environments such as development and production.<\/p>\n<\/div>\n\n<\/div>\n\n\n\n

Less Engine, more room for the project<\/h2>\n\n\n

Engine exists to take server work off your plate. It should not become a heavy piece of infrastructure itself. Several changes in 2.0.1 are about making the layer underneath everyday work smaller, cleaner and less wasteful.<\/p>\n\n\n\n

\n\n
\n

05<\/p>\n

More of your VPS stays available for your projects<\/a><\/h3>\n

We are continuing to reduce the resources Engine itself consumes. The lighter Engine becomes, the more CPU and memory stay available for the applications it is there to manage.<\/p>\n<\/div>\n\n

\n

06<\/p>\n

MCP takes less context<\/a><\/h3>\n

The Engine MCP specification now takes up less of the agent’s context, leaving more room for the codebase, task and conversation. Splitting it further could save even more tokens, but not every agent supports that equally well, so we are testing the options without sacrificing compatibility.<\/p>\n<\/div>\n\n<\/div>\n\n\n\n

\n\n
\n

07<\/p>\n

Deploys clean up after themselves<\/a><\/h3>\n

Deployments, including failed ones, leave temporary files and cache behind. Engine now removes what is no longer needed while keeping useful build cache that can make the next deployment faster.<\/p>\n<\/div>\n\n

\n

08<\/p>\n

Push the code. Let Engine deploy it.<\/a><\/h3>\n

Engine can now generate webhook URLs for GitHub, GitLab and Bitbucket. Once connected, a push to the repository can automatically trigger a fresh deployment. You push the change and Engine takes it from there.<\/p>\n<\/div>\n\n<\/div>\n\n\n

More of the project inside Engine<\/h2>\n\n\n

Running an application gets much easier when the information about that application is close to the tools used to operate it. Engine already knows how to deploy projects and manage the infrastructure around them. With 2.0.1, it gains more useful information about what is actually happening inside those projects and more control at the individual domain level.<\/p>\n\n\n\n

\n\n
\n

09<\/p>\n

See how much transfer a project is actually using<\/a><\/h3>\n

Engine can now show a project’s real transfer usage next to its limit, with daily and monthly numbers calculated from access logs. You can see how much bandwidth the project is actually using, not just how much it was given.<\/p>\n<\/div>\n\n

\n

10<\/p>\n

See who is actually visiting<\/a><\/h3>\n

The API can now return traffic reports for each domain, including pages, locations, referral sources, operating systems and browsers. Engine processes the data locally with AWStats, while raw logs remain available for diagnostics. AI assistants can also access this data directly through Engine.<\/p>\n<\/div>\n\n<\/div>\n\n\n\n

\n\n
\n

11<\/p>\n

Files become part of the same API<\/h3>\n

Project file operations are now part of the Engine API. Agents and integrations can work with files via the same structured interface they already use for other project operations, keeping file access inside the same controlled layer.<\/p>\n<\/div>\n\n

\n

12<\/p>\n

PHP settings go down to the domain level<\/a><\/h3>\n

Each domain can now override account-level PHP INI settings such as memory_limit<\/code>, upload_max_filesize<\/code> and max_execution_time<\/code> without affecting other projects. The same controls are available through MCP, so an AI agent can manage them through Engine as well.<\/p>\n<\/div>\n\n<\/div>\n\n\n\n

This is how we want Engine to grow<\/h2>\n\n\n

PanelAlpha Engine 2.0 was a major release because it changed what the product is supposed to become. But a new direction only means something if the product keeps moving towards it after launch day, and that is exactly what 2.0.1 is about.<\/p>\n\n

We will keep pushing Engine in that direction, listening closely to what happens when people run real projects on it and removing the parts of self-hosting that still require more work than they should.<\/p>\n\n

View full changelog<\/span><\/a><\/p>","protected":false},"excerpt":{"rendered":"

One week ago, PanelAlpha Engine entered its 2.0 generation with one very clear goal: make hosting projects on your own VPS as easy as possible. The server is yours, every infrastructure decision stays yours to make, and the AI assistant you already use can take over much of the work that would otherwise pull you […]<\/p>\n","protected":false},"author":3,"featured_media":3287,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3267","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-release-notes"],"_links":{"self":[{"href":"https:\/\/www.panelalpha.com\/blog\/wp-json\/wp\/v2\/posts\/3267","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.panelalpha.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.panelalpha.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.panelalpha.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.panelalpha.com\/blog\/wp-json\/wp\/v2\/comments?post=3267"}],"version-history":[{"count":31,"href":"https:\/\/www.panelalpha.com\/blog\/wp-json\/wp\/v2\/posts\/3267\/revisions"}],"predecessor-version":[{"id":3300,"href":"https:\/\/www.panelalpha.com\/blog\/wp-json\/wp\/v2\/posts\/3267\/revisions\/3300"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.panelalpha.com\/blog\/wp-json\/wp\/v2\/media\/3287"}],"wp:attachment":[{"href":"https:\/\/www.panelalpha.com\/blog\/wp-json\/wp\/v2\/media?parent=3267"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.panelalpha.com\/blog\/wp-json\/wp\/v2\/categories?post=3267"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.panelalpha.com\/blog\/wp-json\/wp\/v2\/tags?post=3267"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}