Deploy and Host AzuraCast on Railway

AzuraCast is a self-hosted web radio station in one package: Icecast for the stream, Liquidsoap for automated playlists and scheduling, a browser-based WebDJ for live shows, media management, podcasts, listener analytics and a full REST API. It is the open-source answer to paying a hosted radio provider per listener.

This template deploys it as one service on a volume, with the administrator account created during boot instead of being left for whoever finds the URL first.

About Hosting AzuraCast

AzuraCast's setup wizard authenticates nobody. On a fresh install App\Controller\Frontend\SetupController::registerAction serves GET /setup/register and accepts its POST from any caller at all, for as long as the users table is empty — and the account it creates carries the Super Administrator role. That is the correct design for a box on your own LAN. On Railway the public HTTPS URL exists the moment the deploy goes healthy, which is normally minutes before the deployer opens the page, and the station, its media library, its stream keys and its listener data sit behind that window. Reproduced against the stock image: anonymous GET /setup/register → 200 with a usable CSRF token, anonymous POST → 302, and azuracast:account:list then shows one Super Administrator nobody deployed.

This template seeds the account from AZURACAST_ADMIN_PASSWORD after the database migrations and before nginx starts, so there is no interval where the site answers and the account does not exist — polled every three seconds from container start, the first response /setup/register ever gives is 403, in the same second /api/status first returns 200. Deployed with an empty password the container refuses to start rather than publishing a claimable instance.

Ten volumes folded onto one. The upstream image declares the MariaDB data directory, station media, backups, uploads and six storage directories as separate Docker volumes. Railway attaches exactly one per service, so all ten are relocated onto the mount at /data before any service starts, and their ownership is repaired — Railway mounts volumes as uid 0 and none of these services run as root. Verified across a redeploy: the seeded password still logs in, the settings and the station media are still there, and the second boot reports the existing account instead of re-seeding.

Pinned, and built here rather than on your build minutes. This deploys a prebuilt ghcr.io/bon5co/azuracast-railway image pinned to AzuraCast 0.23.7. AzuraCast's database migrations are one-way, so a template that builds FROM ghcr.io/azuracast/azuracast:latest hands every future redeploy an unrequested version upgrade with no way back — and charges the deployer for rebuilding a ~4 GB image each time.

Pool sizes come from the container, not from a constant. Upstream fixes php-fpm at 20 workers with a 256M memory limit each, and InnoDB's buffer pool at 128M, whatever the service is running on. Both are computed from /sys/fs/cgroup at boot — in a 2 GiB container that is php_fpm_max_children=4 innodb_buffer_pool_size=307M — and both stay overridable.

Common Use Cases

Run an internet radio station with automated playlists, scheduled shows, jingles and ads
Broadcast live from the browser with WebDJ, with rotating DJ accounts and per-DJ permissions
Host a community or podcast station with listener analytics, song history and a public player

Dependencies for AzuraCast Hosting

None. MariaDB, Redis/Valkey, Icecast, Liquidsoap, nginx, php-fpm and the cron runner all run inside the single container, so there is no database or cache service to attach.
A Railway volume mounted at /data, which the template creates for you.

Deployment Dependencies

AzuraCast — the application
AzuraCast documentation
bon5co/azuracast-railway — the image this template deploys, and the reproductions behind every claim above

Implementation Details

One service, one volume, no configuration:

azuracast   ghcr.io/bon5co/azuracast-railway:latest   volume /data   healthcheck /api/status

Sign in at the deployed URL as admin@example.com with the generated AZURACAST_ADMIN_PASSWORD from the service's variables, then create your first station. Set AZURACAST_ADMIN_EMAIL before the first deploy if you want a different login address; it is also changeable from the UI afterwards.

Railway injects PORT into every service and it overrides the image's own ENV. AzuraCast's nginx template reads AZURACAST_HTTP_PORT and never looks at PORT, so the entrypoint copies one to the other — without that, nginx listens on 80 while Railway's HTTP healthcheck dials the injected port, the container logs look perfect and the deploy never goes healthy.

Listener streams are served through AzuraCast's own web proxy on the same HTTPS domain (/listen/...), which is on by default, so a station needs no extra ports. Two things a single Railway HTTP domain cannot carry: a live DJ connecting over the Icecast/SHOUTcast source protocol and SFTP media upload on port 2022 — both want a raw TCP port. Browser WebDJ and web media upload work normally.

Why Deploy AzuraCast on Railway?

Railway gives the whole station a persistent volume, an HTTPS domain and a restart policy without a VPS, a reverse proxy or a docker-compose file to maintain, and the usage-based pricing suits a service that is genuinely always on. AzuraCast wants roughly 2 GB of memory to be comfortable — this image sizes its own pools to whatever it is given, so a small plan behaves rather than being oversubscribed by a constant that assumed a bigger box.