SuperDaemon

SuperDaemon is a fork of Pterodactyl Wings. It provides the same HTTP API and SFTP access to manage game-server containers, but is developed independently.

SuperDaemon provides an HTTP API allowing you to interface directly with running server instances, fetch server logs, generate backups, and control all aspects of the server lifecycle.

In addition, SuperDaemon ships with a built-in SFTP server allowing your system to remain free of Pterodactyl-specific dependencies, and allowing users to authenticate with the same credentials they would normally use to access the Panel.

Migrating from Wings

SuperDaemon is a drop-in replacement for Wings in most setups. The binary name is superdaemon instead of wings, but the configuration layout and paths intentionally stay compatible:

Wings	SuperDaemon
wings	superdaemon
/etc/pterodactyl/config.yml	/etc/pterodactyl/config.yml (same location)
/var/lib/pterodactyl	/var/lib/pterodactyl
/var/log/pterodactyl	/var/log/pterodactyl

To migrate from an existing Wings installation:

1. Download the superdaemon_linux_amd64 or superdaemon_linux_arm64 release asset for your platform.
2. Stop the running wings service.
3. Replace the binary path in your systemd unit (or container image) with superdaemon.
4. Start the superdaemon service. Your existing config.yml and server data continue to work unchanged.

Server websocket

The panel connects to GET /api/servers/{server}/ws. The handshake carries no token — the first auth message on the socket does — so this is the one route where a request without credentials still reaches a handler. An id this node does not host gets the same handshake and the same answers as a real one, so the endpoint cannot be used to find out which servers are hosted here.

Status codes before the upgrade

Status	Body / header	When
101		Handshake accepted, including for an id this node does not host. That socket then answers every token with jwt: server uuid mismatch, exactly like a real socket given a token for another server.
400	Too many open websocket connections.	The id already holds 30 authenticated sockets. This is answered to every caller for that id, whether or not it has a token.
400	Bad Request	Not a websocket handshake: missing Connection: upgrade or Upgrade: websocket, unsupported Sec-WebSocket-Version, malformed Sec-WebSocket-Key.
403	Forbidden	Origin is neither panel_location nor listed in allowed_origins.
429	Too many pending websocket connections., Retry-After: 1	This address already has 5 sockets that have not authenticated.
429	Too many connection attempts, slow down., Retry-After: 1	The address used up its handshake rate: 5 in a burst, refilled at one per second. Checked before the server id is looked up.

The rate limit and the per-address budget apply to real and unknown ids alike; the 400 for a full server does not, because an unknown id can never authenticate a socket.

Budgets

• 30 authenticated sockets per server, across all users. Only sockets that completed auth count.
• 5 unauthenticated sockets per client address, per server and for unknown ids alike.
• 30 unauthenticated sockets in total per server (and for the shared bag of unknown ids). At that ceiling one unauthenticated socket is dropped to accept the new handshake, because the newcomer may be the panel's console and an unauthenticated socket never is. The check runs before the upgrade, so a concurrent burst can overshoot it briefly.

After the upgrade

• A socket that has not authenticated within 10 seconds is closed and its slot returned. The deadline is cleared by the first valid token and is not extended by other traffic.
• auth with a token that verifies but names another server is answered with jwt: server uuid mismatch; the socket is not authenticated and no listeners are registered.
• A message is limited to 4 KiB on the wire; a text frame that exceeds 32 KiB after decompression is dropped without an answer. More than 10 messages within 200 ms triggers a single throttled event and the excess messages are dropped.
• Close codes: 4409 server is suspended is sent right after the upgrade if the server is suspended. 1009 is sent when a message exceeds the 4 KiB read limit. No other close code comes from the daemon — a socket dropped for the pre-auth deadline is closed without a close frame (clients see 1006), and 1000, 1001, 1005, 1006 and 1012 are treated as normal client disconnects and not logged as warnings.

Releases

Pre-built binaries are attached to each GitHub Release. The release names use the SuperDaemon binary name:

• superdaemon_linux_amd64
• superdaemon_linux_arm64

Documentation

Upstream Wings documentation is a good starting point because SuperDaemon keeps the same configuration format and API surface:

• Wings Documentation
• Community Guides

For SuperDaemon-specific issues, please use this repository.

Reporting Issues

Please use the MrSchnirschuh/SuperDaemon repository to report issues or make feature requests for SuperDaemon.

Security issues should be reported privately to the repository maintainer.

Development

SuperDaemon is written in Go 1.26+. To run the test suite locally, use

make test

This executes go vet ./... and go test ./.... If you do not have Go installed, you can run bash scripts/run-tests.sh, which downloads Go 1.27.3 into ~/.local/go-download automatically.

To build release binaries, run make build; it cross-compiles linux/amd64 and linux/arm64 into build/.