Deploy and Host a Live Service Queue with Railway

Deploy Chirp Queue as a private, durable waiting line for small service desks, event check-in, and lightweight in-person operations. One click provisions the web application and PostgreSQL with generated credentials and no required input.

About Hosting Chirp Queue

Chirp Queue runs as one async Chirp web service backed by Railway PostgreSQL. Guests join without accounts and receive a private capability link. Operators use revocable tokens to call, recall, start, skip, complete, or cancel tickets while a number-only wallboard and each private ticket update live through server-rendered HTML, named OOB blocks, and EventStream.

PostgreSQL remains the only queue truth across browser reconnects, application restarts, releases, and rollbacks. The supported deployment deliberately uses one web worker and one database—there is no Redis, background worker, email provider, or SPA.

Why Deploy Chirp Queue on Railway

• Zero-input deployment with generated owner, signing, and PostgreSQL secrets.
• Private ticket links and a public wallboard that never renders entrant names.
• Revocable operator access and Railway-variable owner recovery.
• Atomic FIFO claims, explicit state transitions, stale-action protection, and idempotent replay.
• Live display, operator, and ticket convergence without browser-side queue state.
• Seven-day name erasure, 30-day history retention, and bounded CSV export.
• Built-in CSRF, request limits, throttling, readiness, migrations, and restart policy.
• Upstream update notifications, deployment rollback, and GitHub repository ejection.

Common Use Cases

• Community events, workshops, and conference help desks.
• Repair counters, office hours, and campus service desks.
• Pop-up retail, pickup windows, and appointment overflow.
• Internal support queues for small, low-sensitivity teams.
• A self-hosted queue you can inspect, eject, update, and fully own.

Chirp Queue is not intended for medical, government, emergency, identity, or other regulated workflows.

Dependencies for Chirp Queue Hosting

The template uses only the included Chirp application and Railway PostgreSQL. No cache, message broker, object store, identity provider, notification vendor, or third-party queue service is required.

Deployment Dependencies

• Python 3.14 via Railpack
• Chirp 0.10.x with PostgreSQL and signed-session extras
• Railway PostgreSQL 18 with a persistent data volume
• Generated CHIRP_SECRET_KEY and QUEUE_ADMIN_TOKEN
• Private ${{Postgres.DATABASE_URL}} service reference
• One web replica/worker for the process-local EventStream wakeup bus

Live demo:

Source, releases, and support: