Deploy and Host Pterodactyl on Railway

Pterodactyl is the open-source game server panel: a web control panel and API for running Minecraft, Rust, Source-engine and hundreds of other game servers, with per-user permissions, file management, backups and a live console. This template deploys the panel, its database and its cache, already wired together, with an administrator account waiting for you.

About Hosting Pterodactyl

Three services, all from official upstream images:

Panel — the web interface and API, on a public domain with TLS. Runs nginx, PHP-FPM, the queue worker and the scheduler, exactly as upstream's image intends.
MariaDB — accounts, servers, nodes, schedules and the egg catalogue, on a volume.
Redis — sessions, cache and the job queue, on a volume.

Everything is filled in on the deploy screen; there is nothing you have to type. When the deploy finishes, open the domain and sign in with the ADMIN_USERNAME and ADMIN_PASSWORD shown in the Panel service's variables.

Read this before you deploy: the panel is not the game server. Pterodactyl is two halves. This half is the control panel. The other half is Wings, a daemon that runs each game server in its own Docker container and needs root and its own Docker socket on a machine you control — which is not something Railway, or any container platform, can host. So this template gives you the panel; you point it at one or more Wings nodes on your own hardware or VPS. That is the normal split for Pterodactyl, and the panel is the fiddly half: PHP, nginx, a database, a queue worker, a cron, and TLS. The template generates the exact wings configure command for each node you add, on the node's Configuration tab.

Four things this template does that are worth knowing about:

Someone made you an account. The official image migrates the database on boot and then hands over to supervisord; creating the first user is php artisan p:user:make, an interactive command that assumes you have a shell on the container. On Railway you do not. This template runs that command for you on first boot, as an administrator, with a generated password — and it checks first, so a redeploy never creates a second account and never overwrites a password you have since changed.

The panel's errors reach your logs. As shipped, supervisord captures each child process's output into files inside the container, and PHP-FPM discards its workers' output outright. The result is a log that shows the migrations and then falls silent, no matter how many requests the panel serves or exceptions it throws — the first thing you need when something breaks is the one thing you cannot get. Two lines of configuration at boot put PHP-FPM, the queue worker and nginx back on the container's stdout.

Redis can actually write its snapshot. A Redis container on a Railway volume cannot write to it unless it is told to start as root and fix the ownership itself. Left alone, the first background save fails, and Redis's own default then makes it refuse every write — which surfaces in the panel as a 500 on any page that touches a session, minutes after a deployment that looked perfectly healthy. It is a five-character fix and it is easy to not know about.

It pins released versions. Panel v1.15.0, the current release, rather than the latest tag that moves under you; MariaDB 11.8.8, the LTS branch that upstream's own compose file targets; Redis 8.10.0. Nothing is built from a fork or a third-party starter repository, so what you deploy is what Pterodactyl published.

Common Use Cases

A hosting business, or a very organised friend group: sell or hand out game servers with quotas, sub-users and per-server permissions, while the panel itself costs a few dollars a month.
One panel, several machines: add a Wings node per box — a home server, a rented dedicated box, a VPS in another region — and manage them all from one place.
Minecraft without the SSH: file manager, backups, scheduled restarts, a live console and a startup-variable editor, so the people running the server never need a terminal.
A panel that outlives the box under it: the panel's state is in a managed database on a volume, so rebuilding a game node does not cost you your users, servers or schedules.

Dependencies for Pterodactyl Hosting

Deployment Dependencies

Pterodactyl Panel — the upstream project and its official release image
Wings — the daemon that actually runs game servers, installed by you on a machine with Docker
MariaDB for the panel's data, Redis for sessions, cache and the queue

Implementation Details

Your administrator password is a variable. It is generated at deploy time and visible in the Panel service's variables. Change it in the panel once you are in; the bootstrap will not touch it again.
Mail is off, deliberately. MAIL_MAILER ships as array, which accepts and discards messages, because the alternative — upstream's smtp default pointed at a server that does not exist — throws a full stack trace into your logs every time an account is created, including the one this template creates. Set it to smtp and the Mail page appears under Admin → Settings, where the host, port and credentials live. Until then, password resets cannot be emailed.
The login form has a captcha, using Pterodactyl's own shared keys. That is upstream's default and it works. If it ever gets in your way, RECAPTCHA_ENABLED=false is a variable rather than something buried in the database — which matters, because the settings page that would turn it off is behind the login you cannot get through.
APP_KEY encrypts stored secrets and HASHIDS_SALT generates server URLs. Both are generated for you. Changing APP_KEY makes existing two-factor secrets unreadable; changing HASHIDS_SALT changes every server's URL. Neither is validated at startup.
Nothing but the panel has a public address. MariaDB and Redis are reachable only from inside the project — no TCP proxy, no password on the wire to the internet.
Adding a node needs a real hostname. Pterodactyl checks that a node's FQDN resolves, and Wings needs its own certificate for the browser's console and file transfers. Point a subdomain at the machine before you add it.
The panel does not need much. nginx and PHP-FPM idle small; the memory goes to MariaDB.

Resource Usage and Cost

The three services idle at roughly 500–800 MB of RAM together, plus 4 GB of volume — about $8–15/month. The panel's load is people clicking around a web interface, not running games; the game servers cost you whatever your Wings machines cost, which is a separate bill from someone else.

Why Deploy Pterodactyl on Railway?

The Pterodactyl panel is the part of a game-hosting setup that has nothing to do with games: a PHP application behind nginx, a MySQL-compatible database, a Redis instance, a queue worker, a cron entry and a TLS certificate you have to keep renewing. It is also the part that must stay up when a game node does not, since it holds the accounts and the server definitions.

Railway runs that half as three managed services with a private network between them, a volume each, and a domain with TLS that renews itself — while the machines that actually run the games stay wherever you want them, doing the one thing they are good at.