Pterodactyl 2.0 Beta: What's New and How to Test the Upgrade

Pterodactyl 2.0 has been in open beta since 14 October 2026. If you run a 1.x panel, you want to know what changes, what breaks, and how to try 2.0 without touching the panel your users rely on. This guide covers all three from the release notes, docs and beta.2 source as of 1 November 2026, plus the 1.15.2 security release every 1.x panel needs.

Quick answer: Pterodactyl 2.0.0-beta.2 (14 October 2026) is the newest 2.0 release, and the release notes say to keep production panels on 1.x for now. 2.0 adds extensions that add features without editing core files, Pterodactyl themes with a dark and light switch and a safe mode, one app for admin and user pages, an egg catalog that imports Pterodactyl eggs in one click, and tags in place of nests. It needs PHP 8.3 or 8.4 with intl, MariaDB 10.11 or 11 or MySQL 8 or 9, Redis, and Ubuntu or Debian. Test the upgrade on a copy of your panel on a separate VPS that can't reach your live nodes, and update your billing module first. Still on 1.x? Install 1.15.2 and update PHP to 8.2.35 or 8.3.36 for the php2shell fixes.

What's New in Pterodactyl 2.0

Beta.1 brought the features below; beta.2, released the same day, fixes exporting eggs from the admin area.

Extensions

Extensions add features without editing core files, so they survive panel updates: pages, menu items, settings, table columns and form fields, plus hooks into core actions such as creating a server. A broken extension can't take the panel down. Each one is a .pteroext package (a zip archive) that you upload under Admin, Extensions (up to 50 MB) or install from the shell:

cd /var/www/pterodactyl
php artisan p:extension:install /path/to/server-notes.pteroext --enable
chown -R www-data:www-data /var/www/pterodactyl/extensions /var/www/pterodactyl/public/assets/extensions

Installing from a URL only works with URLs that Pterodactyl has signed with its Ed25519 key. The docs warn that extensions run with the panel's own access to your database, settings and users' data, so install only ones you trust. If one breaks the panel, PTERODACTYL_EXTENSIONS_ENABLED=false in .env turns them all off.

Pterodactyl Themes

Themes restyle the panel or replace whole pages, can build on other themes, and bring a dark and light switch and their own settings. In beta.2 a theme installs like an extension; the admin Themes page activates it, lets you preview it for yourself first and edits its settings. From the shell:

php artisan p:theme:list
php artisan p:theme:activate <id>
php artisan p:theme:reset

A theme that fails to load falls back to the built-in classic theme, and ?safe_mode=1 on a panel address shows your session in classic without extension bundles (?safe_mode=0 ends it). The docs' Themes page, last changed on 6 October, still describes a p:theme:apply command that beta.2 doesn't have.

Pterodactyl Eggs: Catalog and Tags

The egg catalog in the admin area imports eggs in one click. It reads its index from eggs.pterodactyl.io and caches it for an hour, so the panel needs outbound HTTPS to that host. On 1 November 2026 the index held 320 eggs (253 games, 55 applications, 12 generic) from Pterodactyl's own egg repositories. Tags replace nests to group and match eggs and nodes, an egg can have several, and eggs exported from 1.x import into 2.0. For your own eggs, see our custom eggs guide.

Admin Area, Console, Security and API

• Admin area: admin and user pages are one app with one design, and the admin area uses a new Admin API at /api/admin. The Client and Application APIs keep their paths.
• Console: scrolls smoothly and works on phones.
• Security: sign-in doesn't reveal which usernames exist, reset tokens stay private, file paths are strictly checked, secrets are masked in the UI, and every API route checks its permissions.
• API: fully typed and documented, with clear validation errors.
• Stack: Vite, React 19, TanStack, Tailwind 4 and Laravel 13.

Requirements: 1.x Compared With 2.0

PostgreSQL and SQLite are not supported. Only Ubuntu 24.04 ships PHP 8.3 itself; the others need an extra PHP repository. Check a server with php -v, php -m | grep intl and mariadb --version.

Wings stays as it is: in the docs' tests, Wings 1.13.2 and 1.13.3 ran power actions, files, the console, SFTP, schedules and backups with the 2.0 panel unchanged. The newest Wings, 1.13.4 (14 October), isn't on that list yet.

What Changes When You Upgrade From 1.x

From the docs' Changes From 1.x page, the changes that matter most:

• Never move to 2.0 with php artisan p:upgrade or the 1.x update steps. Both unpack 2.0 over your 1.x files and leave the panel offline. The upgrade guide installs 2.0 in a new directory instead.
• Billing modules. The Application API's /api/application/nests endpoints now return 404. Update the official WHMCS module first (its new version works with 1.x and 2.0) and ask the developer of any other module about 2.0. Existing API keys keep working.
• Nests become tags. A nest named after a built-in game such as Minecraft or Rust gives its eggs that game's tag, a custom nest with two or more eggs becomes a tag with its name, and an egg alone in a custom nest ends up with no tag.
• Your changes to 1.x files stay behind. The upgrade copies only .env, so edited themes, modified pages and files from an addon installer stay in the 1.x folder. Rebuild them as a 2.0 theme or extension.
• A new /assets/ web server block serves the files that themes and extensions publish as plain files, never through PHP.
• Older databases. MySQL 5.7 and MariaDB 10.2 aren't tested with 2.0, so upgrade the database server first.

What stays: the cron line, pteroq, .env, Wings, passwords, two-factor and SSH keys, API keys, servers with their schedules, backups and databases, and panel settings.

How to Test the Upgrade on a Separate VPS

The upgrade guide's own limits are the best reason to test. It was tested with Panel 1.15.1, MariaDB 10.11 and Wings 1.13.2 on Ubuntu 24.04, and not yet with large databases, MySQL or other MariaDB versions, HTTPS, multiple nodes, server transfers, S3 backups or extensions. If your panel uses any of those, you are the tester.

Any VPS with root access and Ubuntu or Debian works. Our Standard VPS-S is a KVM VPS with full root access, 3 vCores, 4 GB RAM and 60 GB NVMe SSD on an AMD EPYC 7452, and you can reinstall Linux from its panel between test runs.

1. Copy the Live Panel

Update the live panel to 1.15.2 first (see the 1.15.2 section below), then dump its database and copy .env. For InnoDB tables, --single-transaction "does not need to lock the tables at all", MariaDB's docs say, so the panel keeps running:

mysqldump --single-transaction --routines --triggers panel > /root/panel-copy.sql
cp /var/www/pterodactyl/.env /root/panel-copy.env
scp /root/panel-copy.sql /root/panel-copy.env root@test.example.com:/root/

2. Build and Isolate the Copy

On the test VPS, install PHP, MariaDB, Redis, Nginx and Composer as in steps 1 and 2 of our Pterodactyl install guide, then the live panel's version (php artisan p:info on the live panel shows it) with the live .env:

mkdir -p /var/www/pterodactyl && cd /var/www/pterodactyl
curl -L https://github.com/pterodactyl/panel/releases/download/v1.15.2/panel.tar.gz | tar -xzv
chmod -R 755 storage/* bootstrap/cache/
cp /root/panel-copy.env .env
COMPOSER_ALLOW_SUPERUSER=1 composer install --no-dev --optimize-autoloader
grep -E '^DB_' .env

Create the database and user from those DB_ values in mariadb -u root, then import the dump. Skip php artisan key:generate: the copy needs the live APP_KEY to read node tokens and other encrypted data.

CREATE USER 'pterodactyl'@'127.0.0.1' IDENTIFIED BY 'the DB_PASSWORD value';
CREATE DATABASE panel;
GRANT ALL PRIVILEGES ON panel.* TO 'pterodactyl'@'127.0.0.1' WITH GRANT OPTION;
exit

mariadb panel < /root/panel-copy.sql

Now cut the copy off from everything live. Set these in its .env:

APP_URL=https://panel-test.example.com
MAIL_MAILER=log
APP_BACKUP_DRIVER=wings
AWS_ACCESS_KEY_ID=
AWS_SECRET_ACCESS_KEY=

APP_URL gives the copy its own address, with its own DNS record, Nginx site and certificate. MAIL_MAILER=log writes mail to the panel log instead of to your users (mail settings saved in the panel only apply to smtp). Without the S3 keys, the copy can't delete objects in your live bucket, and test backups stay on the test node. If REDIS_HOST points at another machine, set it to 127.0.0.1.

Block the test VPS from reaching your live nodes, database hosts and mail server, with one UFW rule per IP address:

ufw deny out to 203.0.113.20

The rules apply once UFW is enabled; our game panel firewall guide opens SSH, 80, 443, 8080 and 2022 first. Your own browser talks to Wings directly for consoles and file transfers, so in the copy, only open servers on the test node. Keep the queue worker and the cron line off until the counts match. Record them now:

mariadb panel -e "SELECT (SELECT COUNT(*) FROM users) users, (SELECT COUNT(*) FROM servers) servers, (SELECT COUNT(*) FROM eggs) eggs, (SELECT COUNT(*) FROM nodes) nodes, (SELECT COUNT(*) FROM allocations) allocations, (SELECT COUNT(*) FROM schedules) schedules, (SELECT COUNT(*) FROM backups) backups, (SELECT COUNT(*) FROM api_keys) api_keys;"

3. Run the Upgrade on the Copy

Follow Upgrading From 1.x as on the live panel, and time the migration. pteroq isn't running on the copy yet, so its systemctl lines are left out. On PHP 8.4, use php8.4-intl and php8.4-fpm.

apt install php8.3-intl
cd /var/www/pterodactyl
php artisan down
mysqldump --single-transaction --routines --triggers panel > /root/panel-1.x.sql
cp /var/www/pterodactyl/.env /root/panel-1.x.env
tar -czf /root/panel-1.x-files.tar.gz -C /var/www/pterodactyl .

mkdir /var/www/pterodactyl-2.0 && cd /var/www/pterodactyl-2.0
curl -L https://github.com/pterodactyl/panel/releases/download/v2.0.0-beta.2/panel.tar.gz | tar -xzv
cp /var/www/pterodactyl/.env /var/www/pterodactyl-2.0/.env
COMPOSER_ALLOW_SUPERUSER=1 composer install --no-dev --optimize-autoloader
php artisan down
time php artisan migrate --force

chown -R www-data:www-data /var/www/pterodactyl-2.0
mv /var/www/pterodactyl /var/www/pterodactyl-1.x
mv /var/www/pterodactyl-2.0 /var/www/pterodactyl

Add the /assets/ block to /etc/nginx/sites-available/pterodactyl.conf, next to location / in the server block that listens on 443:

location ^~ /assets/ {
    location ~ /\. {
        deny all;
    }

    try_files $uri =404;
}

nginx -t && systemctl reload nginx
cd /var/www/pterodactyl
php artisan optimize:clear
systemctl restart php8.3-fpm
php artisan up

If the migration stops with "This database is missing 1 Pterodactyl Panel 1.x migration(s)", nothing has changed yet: update 1.x, run php artisan migrate --force there and start again.

4. Check the Copy, Then Practice the Rollback

Run the count query again; the numbers should match. Then add the cron line and pteroq.service from the install guide, and work through the docs' checklist:

• Sign in with an existing account, including one that uses two-factor authentication.
• Call the Application and Client APIs with an existing key.
• Add a test node with Wings on the test VPS, under its own name such as node-test.example.com. Start, stop and restart a test server, and open its console, files and SFTP.
• Run a schedule and create a backup.
• Create, suspend and delete a test service through your billing module, pointed at the copy.
• Check your eggs' tags, then enable extensions one at a time.

Finish by rolling the copy back to 1.x with the docs' steps:

cd /var/www/pterodactyl
php artisan down
systemctl stop pteroq
mv /var/www/pterodactyl /var/www/pterodactyl-2.0-failed
mv /var/www/pterodactyl-1.x /var/www/pterodactyl
mysql -e 'DROP DATABASE panel; CREATE DATABASE panel;'
mysql panel < /root/panel-1.x.sql
cd /var/www/pterodactyl
php artisan cache:clear
php artisan config:clear
php artisan view:clear
systemctl restart php8.3-fpm
systemctl start pteroq
php artisan up

Don't use php artisan migrate:rollback; it can't undo the upgrade. A rollback restores only the panel: servers created on 2.0 stay on the nodes, database passwords rotated on 2.0 no longer match, and backups made on 2.0 stay in storage. For the live upgrade, plan a maintenance window, decide in advance when you'd roll back instead of fixing forward, and keep /var/www/pterodactyl-1.x and the backups until you're sure. Our Pterodactyl backup guide lists what else to save.

Still on 1.x? Install 1.15.2 and Update PHP

Panel 1.15.2 (21 October 2026) is, in its release notes' words, a "security release for php2shell (CVE-2026-109618, CVE-2026-109619)". The fix is PHP itself:

• Docker: the 1.15.2 image runs PHP 8.3.36 and disables session.upload_progress in PHP-FPM. Set the image to ghcr.io/pterodactyl/panel:v1.15.2, then run docker compose pull and docker compose up -d. Pin the version: the example Compose file uses latest, which will point to 2.0 once it's released.
• Native install: as the release says, update PHP to 8.2.35 or 8.3.36 and every PHP package together. Then restart PHP-FPM (php8.2-fpm on 8.2) and the queue worker, so running processes load the new PHP:

sudo apt update && sudo apt install --only-upgrade 'php8.*'
sudo systemctl restart php8.3-fpm pteroq
php -v

Compared with 1.15.1, the 1.15.2 tag changes no panel code (only the README, contributing guide, images and Docker files), so on a native install the PHP update is the fix. Still update the panel to 1.15.2, since the 2.0 upgrade guide recommends the latest 1.x first: use the 1.x update steps with the pinned v1.15.2 download, or php artisan p:upgrade --release=1.15.2. Never run p:upgrade without --release: once 2.0 is released, it downloads 2.0 over your 1.x files. The same apt command updates PHP 8.4 on a 2.0 test panel.

php -v shows 8.3.36 (or 8.2.35) when PHP comes from the ondrej/php repository on Ubuntu or Sury's on Debian, which the 1.x guides add. Ubuntu 24.04's own php8.3 packages keep the number 8.3.6: Ubuntu lists both CVEs as fixed in 8.3.6-0ubuntu0.24.04.13, and apt-cache policy php8.3-fpm shows your installed version and where it came from.

FAQ

Is Pterodactyl 2.0 stable yet? No. On 1 November 2026, 2.0.0-beta.2 from 14 October was the newest 2.0 release, and neither the release notes nor the docs give a date for 2.0.0. The docs say to try it on a test panel before you upgrade a production one.

Do my Pterodactyl themes and addons work on 2.0? Not as they are. Edited 1.x files stay behind in the upgrade, so a theme or addon that changed panel files needs a 2.0 theme or extension version, from its developer or rebuilt by you.

Do Pterodactyl eggs from 1.x work in 2.0? Yes. Eggs keep working through the upgrade, and 2.0 imports egg files exported from 1.x. What changes is the grouping: nests become tags.

Pelican vs Pterodactyl: does 2.0 change the choice? Both panels now have add-ons and themes: Pterodactyl 2.0 through extensions, Pelican through plugins. Both new major versions are still pre-release (Pelican's newest is 1.0.0-rc.2 from 22 October 2026), and the licences differ: Pterodactyl 2.0 stays MIT, its README says, while Pelican's panel is AGPL-3.0. See our Pterodactyl vs Pelican comparison.

Sources

All opened on 1 November 2026:

• Pterodactyl Panel releases: v2.0.0-beta.1, v2.0.0-beta.2, v1.15.2, changes from v1.15.1 to v1.15.2, CHANGELOG at v2.0.0-beta.1, README at v1.15.2, container images
• Pterodactyl 2.0 docs: Getting Started, Requirements, Changes From 1.x, Upgrading From 1.x, Testing the Upgrade, Upgrading PHP, Docker Deployment, Extensions, Themes, Upgrading Wings
• Pterodactyl 1.x docs: Getting Started, Updating the Panel, Debian Dependencies
• Panel 2.0.0-beta.2 source: composer.json, package.json, EggCatalogService.php, ExtensionUrlDownloader.php, extension install command, InstallExtensionRequest.php, theme commands activate, list and reset, RememberThemeFlags.php, Themes page, config/mail.php, config/backups.php, SettingsServiceProvider.php
• Panel 1.15.2 source: config/mail.php, SettingsServiceProvider.php, config/backups.php, UpgradeCommand.php, InfoCommand.php, WebsocketController.php, docker-compose.example.yml
• Pterodactyl egg catalog index
• Wings v1.13.4 release
• Ubuntu security: CVE-2026-109618, CVE-2026-109619
• MariaDB: mariadb-dump
• Pelican: Panel v1.0.0-rc.2, comparison page