--- title: "Deploy Windmill | Open Source Retool Alternative" description: "Self-hostable Retool/n8n/Airflow alternative for scripts & workflows" category: "Automation" url: https://railway.com/deploy/windmill-workflows --- # Deploy Windmill | Open Source Retool Alternative Self-hostable Retool/n8n/Airflow alternative for scripts & workflows **[Deploy Windmill | Open Source Retool Alternative on Railway](https://railway.com/template/windmill-workflows)** - **Creator:** katsuba.dev - **Category:** Automation ## Template content ### Postgres https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/postgresql.svg - **Image:** postgres:17.10-alpine ### Windmill Worker https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/windmill.svg - **Image:** ghcr.io/windmill-labs/windmill:1.785.0 - **Start command:** `bash -c 'for i in $(seq 1 90); do (echo > /dev/tcp/$DB_WAIT_HOST/$DB_WAIT_PORT) 2>/dev/null && break; echo "waiting for postgres ($i/90)"; sleep 2; done; exec windmill'` ### Windmill https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/windmill.svg - **Image:** ghcr.io/windmill-labs/windmill:1.785.0 - **Start command:** `bash -c 'for i in $(seq 1 90); do (echo > /dev/tcp/$DB_WAIT_HOST/$DB_WAIT_PORT) 2>/dev/null && break; echo "waiting for postgres ($i/90)"; sleep 2; done; exec windmill'` - **Health check:** / - **Public domain:** Yes ## Documentation # 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](https://www.windmill.dev/) — 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. ## Similar templates - [N8N Main + Worker](https://railway.com/deploy/n8n-main-worker) — Deploy and Host N8N with Inactive worker. - [Evolution API with n8n](https://railway.com/deploy/evolution-api-with-n8n) — [Jul'26] WhatsApp automation platform using Evolution API, n8n & PostgreSQL - [Postgres Backup](https://railway.com/deploy/postgres-s3-backups) — Cron-based PostgreSQL backup to bucket storage Open this page in a browser: https://railway.com/deploy/windmill-workflows