Deploy and Host Ontime on Railway

Built for an LLM agent to deploy and use. The deploy form has no fields to fill: the password is generated for you. Ontime is a browser-based event rundown and stage timer used by live-event, broadcast, theatre and conference crews. One rundown drives the operator view and the screens the room sees: a stage timer, a countdown, a backstage view and a cuesheet, all kept in sync over WebSocket, with a REST API and a WebSocket API for automation (AGPL-3.0).

This template runs the official getontime/ontime image pinned by digest, with a volume on /data so rundowns, projects and settings survive redeploys. People use it as a self-hosted alternative to paid cue-and-timer SaaS for running a show from any browser on the network.

About Hosting Ontime

Ontime is a single Node.js server that serves the operator UI, the stage views and the APIs on one port. The image honours Railway's injected PORT, so no wrapper is needed. The template sets one variable, SESSION_PASSWORD, generated as a Railway secret at deploy time. With a password set, every UI route and every API call requires it: a browser asks for it on /login, and a client sends a Bearer token that is derived from it (the base64url SHA-256 of the password, no padding). Without that token, reads and writes both answer 401.

State lives under /data on a Railway volume: rundowns, project files, user settings and logs. Redeploys keep the same password and the same rundowns. Ontime's OSC input and output use UDP, which Railway does not route, so integrate over HTTP or WebSocket instead. Note that Ontime's /api/ action routes are GET requests that change the running timer; they need the same token.

Agent contract

Public URL: https://RAILWAY_PUBLIC_DOMAIN (the generated domain of the ontime service)
Private URL: http://ontime.railway.internal:8080
Credentials: the variable SESSION_PASSWORD, set on the ontime service
Auth: send Authorization: Bearer TOKEN where TOKEN is the base64url (no padding) SHA-256 of SESSION_PASSWORD; a browser can pass the same TOKEN as the token cookie or token query parameter
Health: GET /login returns 200 without credentials

# needs: SITE_URL (public https URL of the ontime service) and SESSION_PASSWORD (its variable)
TOKEN=$(printf %s "$SESSION_PASSWORD" | openssl dgst -sha256 -binary | openssl base64 -A | tr '+/' '-_' | tr -d '=')
curl -s -o /dev/null -w "health: %{http_code}\n" "$SITE_URL/login"
curl -s -o /dev/null -w "read without key: %{http_code}\n" "$SITE_URL/data/rundowns"
curl -s -H "Authorization: Bearer $TOKEN" "$SITE_URL/data/rundowns" | head -c 200; echo
curl -s -o /dev/null -w "write without key: %{http_code}\n" -X POST -H 'content-type: application/json' -d '{"title":"agent-check"}' "$SITE_URL/data/rundowns"
curl -s -o /dev/null -w "write wrong key: %{http_code}\n" -X POST -H 'content-type: application/json' -H "Authorization: Bearer wrong" -d '{"title":"agent-check"}' "$SITE_URL/data/rundowns"
curl -s -o /dev/null -w "write with key: %{http_code}\n" -X POST -H 'content-type: application/json' -H "Authorization: Bearer $TOKEN" -d '{"title":"agent-check"}' "$SITE_URL/data/rundowns"

A fresh deploy prints health: 200, read without key: 401, a JSON object listing the demo rundowns (Main Stage, Backstage Track and Broadcast), then write without key: 401, write wrong key: 401 and write with key: 201.

Why Deploy Ontime 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 Ontime 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 - no deployer fields, a contract block and one script that proves read, write and refusal.
Locked by default - a generated SESSION_PASSWORD protects the UI and the whole API; unauthenticated writes answer 401.
Data survives redeploys - a volume on /data keeps rundowns, projects and settings.
Light - one Node.js container, measured about 45 MiB idle.
Health-checked - Railway restarts the service if /login stops answering.

Common Use Cases

Live events and conferences - one rundown drives the speaker timer, the backstage screen and the operator view.
Broadcast and streaming - cue sheets and countdowns for a production crew in any browser.
Theatre and church services - a shared running order with a stage timer for the speaker.
Automation - drive start, pause and next from a script or another system over REST or WebSocket.

Dependencies for Ontime Hosting

None. A custom domain is optional.

Deploy Ontime | (Just Updated) Event Rundown and Stage Timer with REST API, Password Set at Boot, Data Survives Redeploys