Deploy and Host orchestrator on Railway

Orchestrator is a single-binary workflow orchestration tool. Flows are ordered lists of tasks — each task type is a drop-in plugin bundle (an executable in any language, with http.request shipped built-in) — with typed inputs, variables, cron triggers, parallel fan-out, retries, and full run observability. One Rust binary serves the web UI, JSON API, scheduler, and executor; all state lives in a single SQLite file.

About Hosting orchestrator

Orchestrator ships as a prebuilt multi-arch Docker image (ghcr.io/webstonehq/orchestrator:latest), so hosting it is just that image plus a persistent volume — no build step on Railway. The binary is self-contained: the web UI is embedded, the http.request plugin is bundled, and state lives in one SQLite database. It binds 0.0.0.0:$PORT and reads the PORT Railway injects, so networking works with no target-port configuration. Mount a volume at /data to persist the database and the encrypted master.key across redeploys. One setting is easy to miss: because the image runs as a non-root user and Railway mounts volumes as root, set RAILWAY_RUN_UID=0 so the service can write to /data.

Common Use Cases

• Scheduled HTTP workflows — cron-triggered API calls, scrapes, and report generation with timezone-aware schedules and catch-up policies
• Parallel fan-out jobs — run a task once per item across an array (e.g. per-region or per-record API calls) with bounded concurrency and per-item error handling
• Self-hosted, single-tenant automation — a lightweight alternative to heavier orchestration platforms for personal or small-team pipelines, with encrypted secrets and full run observability

Dependencies for orchestrator Hosting

• A persistent volume mounted at /data (holds the SQLite database and encrypted master.key)
• The published Docker image ghcr.io/webstonehq/orchestrator:latest (public GHCR package — no build toolchain required)

Deployment Dependencies

• Docker image: ghcr.io/webstonehq/orchestrator
• Source & docs: github.com/webstonehq/orchestrator
• Railway deploy guide: docs/railway.md

Implementation Details

The service provisions from a single Docker image with these settings:

Optional variable: RUST_LOG (e.g. info or info,orchestrator=debug) for log verbosity. Leave PORT unset — Railway manages it.

> ⚠️ Orchestrator has no built-in authentication. A service with a public domain is reachable by anyone who has the URL — meaning full control of your flows, runs, and decrypted secrets. Gate it behind Railway's access controls, an authenticating proxy, or private networking before exposing it, and don't put real secrets in a publicly exposed instance.

Why Deploy orchestrator 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 orchestrator 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.