Deploy and Host AList on Railway

Built for an LLM agent to deploy and use. The deploy form has one field and it is already filled: ALIST_ADMIN_PASSWORD is generated for you. AList, the open-source file list and WebDAV server, comes up with an admin account that already exists, a volume that keeps its database and files across redeploys, and a public HTTPS address. The contract below lists every address, variable name and one script that signs in, mounts a storage and writes a file over WebDAV.

AList here is the official xhofe/alist image, version 3.66.0, pinned by digest. It puts many storages behind one web UI and one API: local disk, S3-compatible buckets, WebDAV, FTP/SFTP and dozens of cloud drives. Every storage is also served as a WebDAV share, so any WebDAV client, rclone or an agent's HTTP tool reads and writes through the same login.

About Hosting AList

This template runs one service from the upstream image, with a start command that does the three things the image's defaults get wrong on Railway: it makes AList listen on Railway's injected PORT (the healthcheck dials that port, not the domain's target port), it binds the dual-stack wildcard so other services reach it over the private network as well as the public edge, and it creates /opt/alist/data/files on the volume so a Local storage has a root folder from the first minute.

The admin account is created on the first boot from ALIST_ADMIN_PASSWORD (username admin). The account lives in the SQLite database on the volume mounted at /opt/alist/data, together with the JWT secret and the storage list, so the password and every mounted storage survive redeploys. Changing the variable later does not change an existing account's password; change it in AList's admin page.

AList stores no files of its own beyond what you put in the Local storage. The Local storage at /opt/alist/data/files is on the volume, so files written there persist. Other storages (S3, WebDAV, cloud drives) hold their data at the provider and AList keeps only the connection settings.

Agent contract

Public URL: https://$RAILWAY_PUBLIC_DOMAIN (the alist service's generated domain)
Private URL: http://alist.railway.internal:8080
Credentials: username admin, password in the variable ALIST_ADMIN_PASSWORD
Auth: the JSON API takes the token from POST /api/auth/login ({"username","password"} returns data.token) in the Authorization header, with no Bearer prefix; WebDAV at /dav/MOUNT/PATH takes HTTP Basic with the same username and password and answers 401 without it
Health: GET /ping returns 200 pong without authentication

# needs: RAILWAY_PUBLIC_DOMAIN of the alist service, and ALIST_ADMIN_PASSWORD from its variables
BASE="https://$RAILWAY_PUBLIC_DOMAIN"
curl -s -w "\nhealth: %{http_code}\n" "$BASE/ping"
TOKEN=$(curl -s -X POST "$BASE/api/auth/login" -H 'Content-Type: application/json' -d "{\"username\":\"admin\",\"password\":\"$ALIST_ADMIN_PASSWORD\"}" | jq -r .data.token)
# mount the volume folder /opt/alist/data/files (created at boot) as the Local storage /files
curl -s -X POST "$BASE/api/admin/storage/create" -H "Authorization: $TOKEN" -H 'Content-Type: application/json' -d '{"mount_path":"/files","driver":"Local","order":0,"cache_expiration":30,"webdav_policy":"native_proxy","addition":"{\"root_folder_path\":\"/opt/alist/data/files\",\"mkdir_perm\":\"777\"}"}'
echo
curl -s -o /dev/null -w "write without key: %{http_code}\n" -X PUT --data hello "$BASE/dav/files/hello.txt"
curl -s -o /dev/null -w "write with key: %{http_code}\n" -u "admin:$ALIST_ADMIN_PASSWORD" -X PUT --data hello "$BASE/dav/files/hello.txt"
curl -s -u "admin:$ALIST_ADMIN_PASSWORD" "$BASE/dav/files/hello.txt"; echo
curl -s -X POST "$BASE/api/fs/list" -H "Authorization: $TOKEN" -H 'Content-Type: application/json' -d '{"path":"/files"}' | jq -c '.data.content[].name'

A fresh deploy prints pong and health: 200, then {"code":200,"message":"success","data":{"id":1}} for the storage, write without key: 401, write with key: 201, hello and "hello.txt". Run the storage-create call once; a second run answers with a duplicate-mount error and the rest of the script still works.

Why Deploy AList on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying AList on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Agent-ready - a generated admin password, a contract block and one working sign-in, mount and WebDAV-write script.
Persistent - a volume at /opt/alist/data holds the database, JWT secret, storage list and the Local storage folder; the image is pinned by digest.
Private-network reachable - the server binds IPv4 and IPv6, so other Railway services use alist.railway.internal:8080.
Health-checked - Railway restarts the service if /ping stops answering.
One login, many storages - S3, WebDAV, FTP/SFTP and cloud drives behind one UI, one API and one WebDAV endpoint.

Common Use Cases

WebDAV endpoint for agents and apps - give a tool one authenticated place to read and write files, backed by a volume or a bucket.
Unified view over S3 and cloud drives - browse several providers in one web UI without syncing them.
Personal file portal - share folders by link from storage you already pay for.
Front for rclone and backup jobs - point rclone's WebDAV backend at /dav/ and keep the destination swappable.

Dependencies for AList Hosting

Nothing else to run. Add storages (an S3 bucket, a WebDAV server, a cloud-drive account) from the admin page or the API when you want files beyond the volume.

Deployment Dependencies

Implementation Details

Variable	Purpose
`ALIST_ADMIN_PASSWORD`	Generated at deploy. Password of the `admin` account, applied when the account is first created.

AList listens on Railway's PORT (8080). The data directory is /opt/alist/data.