Deploy and Host Windmill on Railway

Windmill is an open-source developer platform and workflow engine — a self-hostable alternative to Retool, n8n, Airflow and Temporal. Turn scripts in Python, TypeScript, Go, Bash, SQL and more into internal apps, UIs and scheduled or event-driven workflows, with a job queue, permissions and secrets built in.

About Hosting Windmill

This template runs Windmill the way it is meant to run in production: as three separate services rather than one all-in-one container. A server node serves the web UI and API and runs the database migrations, a dedicated worker node pulls jobs from the queue and executes them, and a PostgreSQL database holds every workflow, script, job and secret on a persistent Railway volume. Splitting the server from the worker is Windmill's own recommended architecture — the API stays responsive while heavy jobs run on the worker, and you scale the two independently.

Everything is pinned to the exact upstream image ghcr.io/windmill-labs/windmill:1.785.0. Windmill ships roughly one release a day and runs its schema migrations on startup, so an image that floats on :latest can rewrite your database the next time it restarts. A pinned tag means the version you deploy is the version you keep until you choose to move it.

Server + worker split — the intended production shape, not a single standalone process.
Pinned engine version — no surprise upgrades or migrations on redeploy.
Persistent Postgres volume — scripts, flows, schedules, secrets and job history survive restarts and redeploys.
Database wait on boot — the server and worker wait for Postgres before starting, so a cold start never fails the migration on a race.

Common Use Cases

Internal tools and admin panels: build UIs and endpoints over your databases and APIs without a frontend stack.
Scheduled and event-driven automation: cron jobs, ETL, webhooks and background tasks with retries, concurrency limits and full logs.
Orchestrating scripts across languages: chain Python, TypeScript, Bash, Go and SQL steps into one flow with typed inputs and outputs.

Dependencies for Windmill Hosting

Deployment Dependencies

Windmill — the upstream engine and web app (windmill-labs/windmill).
PostgreSQL 17 — the single source of truth for all Windmill state.

Implementation Details

First login: sign in as admin@windmill.dev with the password changeme. Windmill forces you to set a new password on that first login — do it before exposing the instance. The encryption key that protects your secrets is generated by the server on first boot and stored in the database; the worker reads it from the same database, so there is nothing to configure by hand.
Adding workers: one worker is included. To run more jobs in parallel, duplicate the Windmill Worker service (same image, same MODE=worker and DATABASE_URL) — each extra worker joins the default group automatically.
Job isolation: Railway does not grant the privileged/unshare capability, so jobs run without kernel-level PID isolation between them. This is appropriate for a single-team, self-hosted instance; do not use one instance as a multi-tenant sandbox for untrusted code.
Resource usage: measured on a fresh deploy, the three services idle at roughly 1 GB of RAM combined (server ~0.5 GB, worker ~0.2 GB, Postgres ~0.3 GB). Workers grow with whatever your scripts do — Windmill's own guidance allows up to ~2 GB per worker for heavy jobs — so expect a few dollars a month idle and to scale toward ~$15–30/month under regular job load, more if you run large or highly concurrent workloads.

Why Deploy Windmill on Railway?

Railway provisions the Postgres database, the persistent volume and the public domain as part of one deploy, so Windmill comes up configured and reachable on the first try — no compose file, reverse proxy or manual DATABASE_URL wiring. Because the server and worker are separate Railway services, scaling throughput is a matter of adding worker replicas, and the pinned image keeps every deploy reproducible.