Deploy Pterodactyl | (Just Updated) Game Server Panel That Actually Boots
Game server panel that boots: migrated DB, seeded admin, working reset
mariadb
Just deployed
/var/lib/mysql
Just deployed
/app/var
redis
Just deployed
/data
Deploy and Host Pterodactyl Panel on Railway
Pterodactyl is the open-source game server management panel: a web UI and REST API for creating, starting, stopping and monitoring game servers, with user accounts, permissions, subusers, file management, scheduled tasks, databases and backups. This template deploys the panel with MariaDB and Redis, on three services and three volumes.
The panel boots with a migrated database and an administrator account already created, and every redeploy re-applies that credential, so a lost password is one redeploy away from being fixed.
About Hosting Pterodactyl Panel
Pterodactyl is a Laravel application, and Laravel deployments fail in a particular way: the container starts, PHP-FPM and nginx come up, the platform reports the deployment healthy, and every page returns HTTP 500 because the database migration never completed. The upstream entrypoint does not stop when the migration fails, so nothing in the deploy status shows it.
Two things make that migration fail on a hosted platform. The panel's cache, session and queue
drivers all point at Redis, so the migration aborts if Redis is not reachable yet — the upstream
entrypoint waits for the database only. And the panel image ships MariaDB's client binaries, which
Laravel shells out to when it loads the stored schema; a recent MariaDB client verifies the server
certificate by default, so pairing the panel with the official MySQL image — whose certificate is
self-signed and auto-generated — ends the schema load with
ERROR 2026 (HY000): TLS/SSL error: self-signed certificate in certificate chain and leaves the
database empty.
This template waits for both dependencies, uses MariaDB, and fails the deployment when the migration fails instead of serving an error page. It also creates the administrator: the panel has no signup page and no seeding variable of its own, so a stock deploy has no account and no way to make one.
Why Deploy Pterodactyl Panel on Railway?
Railway supplies the panel, its database and its cache as one deployable unit with persistent volumes, private networking between them and HTTPS on the public URL, with no VM to maintain and no web server to configure. The database and Redis stay on the private network rather than being exposed through public TCP proxies. Billing follows usage, and a redeploy is a clean restart on the same data.
Common Use Cases
- Managing game servers hosted on your own machines from a panel you do not have to keep patched.
- A control plane and REST API for a small hosting business or a gaming community.
- Delegating server access to subusers with scoped permissions rather than sharing credentials.
- A staging panel for testing eggs, nests and scheduled tasks before touching production.
Dependencies for Pterodactyl Panel
- The official
ghcr.io/pterodactyl/panelimage, pinned to v1.15.1 and wrapped for Railway (bon5co/pterodactyl-railway). - MariaDB 11.8 and Redis 8.2, both deployed by this template on the private network.
Deployment Dependencies
- Volumes for the panel (
/app/var), MariaDB and Redis, all created by this template. PTERODACTYL_ADMIN_EMAILandPTERODACTYL_ADMIN_PASSWORD— both generated by default; the container refuses to start with either one empty.- A Wings node, if you want to run game servers. Wings is Pterodactyl's daemon and needs privileged Docker access, which Railway does not grant, so run it on your own host and connect it to this panel. The panel, its API and its user management work without one.
Implementation Details
nginx listens on the port Railway injects, APP_URL is derived from the deployment's public
domain, and TRUSTED_PROXIES is set so the panel reads the client address through Railway's edge.
APP_KEY and HASHIDS_SALT are persisted on the panel's volume, so sessions and encrypted values
survive a redeploy. Telemetry is disabled, and reCAPTCHA is disabled because upstream defaults it on
with shared keys and domain verification that does not match a *.up.railway.app hostname. The
administrator is seeded before nginx binds the public port, so the first request the deployment ever
serves is against a panel that already has an owner.
Template Content
mariadb
mariadb:11.8.3MARIADB_USER
MARIADB_DATABASE
DB_PORT
REDIS_PORT
DB_DATABASE
DB_USERNAME
redis
redis:8.2.1-alpine