Skip to content

Updating and Rollback

DevRock edited this page Sep 1, 2026 · 2 revisions

Updating and Rollback

Safe update checklist

Before every update:

cd /var/www/pterodactyl
tar -C /var/www/pterodactyl \
  -czf /root/pterodactyl-before-rock-update.tar.gz .
mariadb-dump -u pterodactyl -p panel \
  > /root/panel-before-rock-update.sql
cp .env /root/pterodactyl-env-before-rock-update

Adjust the database name and dump command for your environment. Confirm the backup files exist before continuing.

Update with the manager

Download and review the current manager once, then run the update from that local copy:

curl -fsSL https://raw.githubusercontent.com/devrock07/Rockdactyl/main/install.sh \
  -o /tmp/rockdactyl-install.sh
less /tmp/rockdactyl-install.sh
bash /tmp/rockdactyl-install.sh update

The manager creates an additional safety snapshot, verifies the release checksum, runs migrations and caches, repairs permissions, and returns the panel to service.

Restore the manager backup

bash /tmp/rockdactyl-install.sh restore

The built-in restore action always restores /var/backups/rock-theme/original-panel.tar.gz, the snapshot captured before the first managed theme installation. It does not automatically select the newest before-update-<timestamp>.tar.gz snapshot. The current .env, storage, and database migrations are preserved.

Timestamped update snapshots are recovery points for an operator-reviewed manual file rollback. A complete version rollback may also require the matching database dump. Never restore an older database without reviewing migrations and the data that would be lost.

Manual recovery

If an interrupted operation leaves maintenance mode enabled:

cd /var/www/pterodactyl
php artisan up

Review the failed stage before retrying. Never repeatedly extract an archive over a partially migrated production installation without a verified backup.

To restore a full manual snapshot, put the panel into maintenance mode, move the failed directory aside, restore the archive and .env, restore the database when necessary, repair ownership, clear caches, and only then run php artisan up.

Browser cache after an update

Hashed assets normally invalidate cleanly. If the old interface persists:

  1. Run php artisan view:clear and php artisan config:clear.
  2. Restart the PHP worker or PHP-FPM service.
  3. Purge any reverse-proxy or CDN cache.
  4. Hard-refresh the browser or test in a private window.

Clone this wiki locally