This checklist exists to help you close the door before someone else opens it. A Pterodactyl Panel is not just a control panel; it is a web application with root-equivalent reach into every game server you run. When a panel gets compromised, the game servers behind it usually fall next, and the host under them often follows.
It is written for owners and administrators running Panel plus Wings with a small team and one or more nodes. The controls are ordered by impact, not effort. They come from auditing live Pterodactyl installs on Ubuntu 22.04 and 24.04, checking each item against the official Pterodactyl documentation and published advisories, and testing the firewall and Docker behavior on real nodes.
The Panel Is the Front Door
Think about what the panel can do. An admin account can create a server from any image, mount host paths, read the console of every instance, and issue commands through Wings to a daemon running as root. There is no meaningful separation between “web login” and “the machine” once an attacker is inside. Panel hardening is host hardening with a browser attached.
The strongest single control is to stop the panel being publicly reachable at all. Put it behind WireGuard or Tailscale, Cloudflare Access with an identity provider, or an IP allowlist in nginx. If your team works from changing addresses, a VPN beats a growing list of CIDRs. If you must stay public, terminate TLS at a reverse proxy on 443, never hand out 8080 or 8443 directly, and rate-limit the login route. Keep panel and game nodes on separate machines, and allow the Wings port only from the panel’s IP.
Priority table: what to fix first
| Priority | Check | Why it matters | Command or setting |
|---|---|---|---|
| P0 | Panel not exposed on 8080/8443 | Login pages are scanned constantly | proxy_pass on 443 plus VPN or allowlist |
| P0 | TLS valid, HSTS on, secure cookies | Otherwise credentials travel in clear text | SESSION_SECURE_COOKIE=true |
| P0 | 2FA enforced on every admin | Stolen passwords are the top entry path | Profile, then Enable Two-Step |
| P1 | Wings port open only to panel IP | The daemon is root-adjacent | ufw allow from PANEL_IP to any port 8080 |
| P1 | Registration closed, subusers scoped | Open signup widens the blast radius | Admin, Settings, then Advanced |
| P2 | Encrypted off-site backups, restore drill | Recovery survives a full compromise | restic backup over cron |
| P2 | Update cadence and advisory watch | CVEs are mass-scanned within days | composer update, Wings update |
Authentication and Access Control
Assume every password will eventually leak through a reused login, a phishing page, or a breached database elsewhere. Your job is to make that leak useless. Generate a long, unique admin password in a password manager, then put a second factor on everything, because 2FA is the difference between a bad afternoon and a rebuilt node.
Work through this list in the panel:
- Enforce 2FA for every admin. TOTP is enough; hardware keys are better. Store recovery codes offline.
- Close public registration. An open signup form is a free reconnaissance account.
- Scope subusers tightly. Per-server permissions instead of Full Access, and a separate admin account from the one you play on.
- Review accounts quarterly. Remove departed staff the same day.
- Prune API keys. One key per integration, least scope, with an expiry date. Revoke anything without a named owner.
- Clear stale sessions. Force a reset if a laptop is lost.
The staff side is where audits fail. Sign-in logs only help if someone reads them, which is the argument in our guide to two-factor authentication and audit logs for Minecraft staff. Choosing a platform at all? Our Pterodactyl vs Multicraft comparison covers the tradeoffs.
Network and Host Hardening
Panel security is only as good as the operating system under it. Start with patching, because unpatched kernels and PHP releases are the cheapest route in. Enable unattended upgrades, reboot when the kernel changes, and check that reboots actually happen rather than pending forever in /var/run/reboot-required</code.
Then reduce what is listening. A default-deny firewall plus SSH keys only, disabled password auth, and fail2ban on sshd and the panel's nginx access log removes most automated noise. Bind MySQL and Redis to localhost, because an exposed 3306 with a weak password hands over every user hash and server record. Run the panel as a non-root service user, keep .env at mode 640, and stop the web root serving dotfiles. Clock drift also breaks TLS validation and TOTP codes, so keep NTP running.
Verify it, do not assume it
Run these on the panel host and on each node, and read the output:
ss -lntp # what is actually listening, and as whom
ufw status verbose # default policy and every open port
systemctl status pterodactyl wings nginx --no-pager
docker ps --format '{{.Names}} {{.Ports}}'
curl -sI https://panel.example.com | grep -i strict-transport
timedatectl status # clock synced?Anything bound to 0.0.0.0 that is not a game port or your reverse proxy deserves an explanation. Our walkthrough of SSH keys and UFW for Minecraft servers covers the host layer in depth, and the proxy firewall guide handles the game-port side.
Docker, Wings, and Node Isolation
Docker socket access is effectively root on the host. Anyone who can talk to /var/run/docker.sock can start a container that mounts / and rewrites anything, so treat container control as a root grant. The Docker security documentation says this plainly, and it is the most commonly ignored fact in game panel setups. Never let an untrusted subuser or third-party plugin drive Docker for you.
Read /etc/pterodactyl/config.yml line by line. Confirm the panel URL, daemon token, SFTP settings, and port, and confirm the file is not world-readable. Rotate the node token if it has been pasted into a ticket, and update Wings alongside the panel.
Then bound the damage a single server can do. Set memory and CPU limits per server and enforce disk quotas on /var/lib/pterodactyl/volumes, because an unbounded container can starve every other server on the node. Separate nodes along trust boundaries: public servers on one host, staff and build servers on another, each with its own SSH keys and Wings token. Protect the panel database and .env too. The APP_KEY encrypts sensitive columns and signs sessions, so a leaked copy is worse than a leaked password. OWASP ASVS is a useful yardstick here.
Backups, Updates, and Incident Response
Backups are the only control that works after an attacker has already won. Take encrypted backups of the panel database, the .env, and every server volume, and push them off the node to object storage with restic or borg. A backup on the same disk is not a backup; it is a second copy of the thing about to be deleted.
Then prove the restore works. Restore the panel database into a staging container once a quarter and start one game server from a restored volume. Owners who skip this drill find out on the worst day that the dump was truncated for eight months.
Updates belong on a schedule with a rollback plan, not on vibes. Snapshot the database before running migrations, pin versions you depend on, and update Wings, Docker, and game jars in one maintenance window. Watch the Pterodactyl security advisories and CISA's known exploited vulnerabilities catalog so you hear about a bug from the source rather than from a scan.
If you think you are compromised
- Revoke all sessions and API keys, and force password resets for every admin.
- Rotate the database password and the
APP_KEY, then re-encrypt anything that depended on the old key. - Preserve logs before you clean anything: nginx, panel activity, Wings, and auth logs.
- Rebuild the node from a clean image instead of cleaning it in place, and restore data from a backup taken before the intrusion.
- Notify players if personal data such as emails or IPs was exposed, and check your local breach-notification rules.
Pros and Cons: Self-Hosted Panel vs Managed Panel
Every item above is work you own when you self-host. That is not an argument against self-hosting, only a bill that arrives eventually.
- Pros of self-hosting Pterodactyl: full control over images, limits, and networking; no per-slot pricing; direct access to Wings config and logs; freedom to isolate nodes.
- Cons: you are the security team for a public web app, a Docker daemon, and sometimes several hosts; patching and incident response land on one volunteer.
- Pros of a managed panel: the provider patches the panel and daemon, handles TLS, and absorbs DDoS traffic.
- Cons: less control over Docker tuning and node topology, plus recurring cost per slot.
A reasonable middle ground is a self-hosted panel behind a VPN, one node per trust boundary, and a written quarterly review so the checklist is not a one-time event.
Common Mistakes and Expert Tips
- Opening 8080 "just to test." Temporarily exposed panels are how most of these incidents start.
- One shared admin account. If everyone logs in as the same user, you cannot attribute a change or revoke one person.
- Running Wings as root and calling it done. Root is the default; the real question is who can reach the daemon port and Docker socket.
- Backups on the same node. A wipe takes the backup with it. Off-site, encrypted, and versioned or it does not count.
- Ignoring Wings updates. People patch the panel and forget the daemon that owns the containers.
- No restore drill. A backup you have never restored is a hope, not a control.
Frequently Asked Questions
It ships with sane application defaults such as hashed passwords and CSRF protection, but it does not configure your firewall, TLS, or Docker isolation. Treat the install as a starting point and harden the host yourself.
Preferably not. Put it behind a VPN, Cloudflare Access, or an IP allowlist. If it must be public, force TLS, enable HSTS, rate-limit logins, and require 2FA for every admin.
Yes, effectively. A process that can talk to the Docker socket can start a privileged container that mounts the host filesystem, which means reading and writing anything on the machine. Only grant it to people you would give a root shell.
Patch security advisories within days, and run a routine update window monthly for the panel, Wings, Docker, and game jars. Snapshot the database before panel migrations so you can roll back.
Start With the Front Door Tonight
Work down the P0 rows tonight: stop exposing the panel, confirm TLS and HSTS, and put 2FA on every admin account. That is under an hour of work and removes most realistic attack paths. Then book a maintenance window for P1 and P2, and put the quarterly review and restore drill on a calendar.
If you inherited a panel and are unsure what is exposed, run the verification commands above before changing anything, and keep the output. You cannot tell whether hardening worked without a before picture. Our host hardening walkthrough is the next step once the panel sits behind a VPN.
Leave a Reply