How Pterodactyl Handles Security and Extensions

Updated

Pterodactyl secures a deployment in two layers: access control at the panel (bcrypt password hashing, two-factor authentication, and scoped tokens passed to Wings) and isolation at the workload level (every game server runs in its own locked-down Docker container with hard CPU, memory, and disk limits). Extensions work differently from typical panels: they plug into versioned panel APIs rather than editing core files, so they survive updates and a broken extension is skipped instead of taking the panel down. This applies to self-hosted Pterodactyl installs; it is not a managed hosting product with its own security guarantees.

Access control: bcrypt, 2FA, and scoped tokens

The panel's stated design is "security first" at the door:

  • bcrypt password hashing — account credentials are stored hashed rather than in plaintext, so a database leak does not directly expose passwords.
  • Two-factor authentication (2FA) — an additional factor is required at login, which limits the value of a stolen password.
  • Scoped tokens through Wings — the panel does not hand Wings (the daemon running on each node) unlimited authority. It issues tokens limited to the scope needed for the operation, so a compromised or misbehaving node process has a narrower blast radius.

The practical consequence for an admin: enabling 2FA on your own account and on staff accounts is the highest-value single step, because panel access is the path to every server on every connected node.

Isolation: one Docker container per server

Each game server is sealed in its own Docker container with hard CPU, memory, and disk limits. The site's own framing is that one server "can throw the loudest party on the node, and the rest of the street sleeps through it" — noisy neighbours are contained.

What this means in practice:

Concern How it is handled
Resource hogging Hard CPU, memory, and disk limits per container
Cross-server interference Separate containers per server
Host exposure Locked-down Docker container as the final boundary
Moving load Servers can be relocated between nodes

Limits are the mechanism, not a suggestion: a container that hits its memory ceiling is constrained rather than allowed to consume the node. When you size a plan, set memory and disk limits with headroom for the game's peak, because the limit is enforced.

Extensions: versioned APIs instead of core edits

The stated principle is "extend it without forking it." Extensions plug into versioned panel APIs and never touch core files. Three consequences follow:

  1. They survive updates. Because nothing in the core is modified, upgrading the panel does not overwrite extension work.
  2. A broken extension is skipped. A failing extension does not take the panel down; it is bypassed.
  3. Versioning is the contract. Extensions target a specific API version, so compatibility depends on that version rather than on the panel's internal file layout.

The site's own example extension list — SSO, Announcements, Custom Buttons, Redirect, Dark Theme — shows the intended scope: authentication, messaging, navigation, and theming, all without forking. The panel reports "installed 0 / 5 · core files touched 0," which is the design goal stated as a metric.

What an Egg is, and why it matters for both topics

An Egg is a portable recipe for a game: its Docker image, startup command, and configurable variables. A Paper Minecraft egg, for example, specifies a Java Docker image, a startup command using {{SERVER_MEMORY}} and {{JARFILE}}, and variables like the server jar file and Minecraft version.

Eggs matter here because they are the unit that connects isolation to game support: the Docker image in the egg is what the server actually runs inside, and the variables are what the panel exposes to the user. You can install from the community library or author your own, and the same panel runs every one of them. The site lists Minecraft, Rust, ARK, Counter-Strike 2, Garry's Mod, Valheim, Terraria, Palworld, FiveM, Project Zomboid, Discord Bots, Teamspeak, SCP: SL, Factorio, and Satisfactory among supported games.

Choosing based on your situation

  • If you run a small community server: the defaults already give you container isolation and per-server limits. Turn on 2FA for every admin account first.
  • If you host for others: scoped Wings tokens and hard per-container limits are what keep one tenant from affecting others; verify limits per plan rather than assuming.
  • If you need custom behaviour: prefer an extension against the versioned API over editing core files, so updates stay painless. If an extension breaks, expect it to be skipped rather than to break the panel.
  • If you need a game not in the list: check whether an Egg exists in the community library or write one; the panel is not limited to the games shown.

Pterodactyl is described as free, open source, MIT licensed, with no seats, feature gates, or monthly bill, and in production since 2015. Those claims cover the software itself; hosting, nodes, and any third-party services are separate.