Deploy and Host Windmill Self-Hosted on Railway

Windmill is the open-source platform that turns scripts into workflows, APIs, and internal tools. Write in Python, TypeScript, Go, Bash, or SQL, chain them into flows with branching and error handling, and get a usable UI generated automatically, no proprietary low-code language, no per-builder bill.

About Hosting Windmill-Self-Hosted

Retool's Business plan runs $50-65 per builder per month, plus extra charges once you exceed the included end users. A team of 5 builders is already looking at $250-325/month before anyone's actually used the internal tools they've built, and that number only grows as the team does. Windmill self-hosted on Railway costs a flat infrastructure fee no matter how many people write scripts, build flows, or use the resulting apps.

The bigger reason teams move to Windmill specifically isn't only the price curve. It's that Windmill is code-first: your automation logic is plain Python or TypeScript, not locked inside a proprietary drag-and-drop builder that's hard to version-control, hard to test, and hard to migrate away from. Scripts live as actual code, reviewable in a normal pull request, runnable outside Windmill if you ever need to.

It's worth being specific about what makes Windmill different from "yet another Airflow alternative" or "yet another Retool alternative." It does both jobs at once: it's a workflow orchestrator (Airflow's territory) and an internal-tool/UI builder (Retool's territory), from the same scripts. Write a Python function once, and it becomes a callable API, a scheduled job, a step in a larger flow, and the backend for an auto-generated form UI, without rewriting it four different ways for four different tools.

This isn't a small or unproven project either. Windmill has crossed 12,000 GitHub stars and describes itself as roughly 13 times faster than Airflow for equivalent workloads, a real, benchmarked claim rather than marketing language. That kind of traction matters for infrastructure specifically: a workflow engine your internal tools depend on is worth trusting to a project with real momentum behind it, not a smaller side project that might stall.

Common Use Cases

Internal tools without per-builder fees: Admin panels, approval workflows, and internal dashboards without a Retool-style per-seat bill that grows with every team member who needs access.
Script-to-API in minutes: Turn any Python, TypeScript, or Go script into a callable HTTP API automatically, without standing up a separate API framework and deployment pipeline for it.
Scheduled automation and cron jobs: Data syncs, report generation, cleanup tasks, and recurring maintenance scripts, with built-in retry logic and error handling out of the box.
API integration workflows: Chain calls across multiple third-party APIs into a single flow with real branching logic, without an expensive iPaaS subscription for what's fundamentally a few connected API calls.
Data pipeline orchestration: A meaningfully lighter alternative to Airflow for teams whose actual pipeline complexity doesn't justify Airflow's operational overhead.
Ops and DevOps automation: Incident response scripts, deployment helpers, and infrastructure automation, callable on-demand or on a schedule, versioned like real code because it is real code.

Dependencies for Windmill-Self-Hosted Hosting

PostgreSQL for scripts, flows, execution history, and user data.
A separate worker process to actually execute jobs, distinct from the API server.

Deployment Dependencies

This template provisions Railway-managed PostgreSQL automatically, wired to both the windmill server and windmill worker services over Railway's private network. Both services run the identical Docker image, differentiated only by a MODE variable, matching Windmill's own proven, widely-deployed simple architecture rather than the full 7-service setup documented in Windmill's official docker-compose reference. Reference: Windmill GitHub Repository, Windmill Documentation, Windmill Self-Host Guide.

Implementation Details

This template runs ghcr.io/windmill-labs/windmill:1.775.2, a specific verified release tag, not a floating tag that could change under you, worth re-verifying close to publish time since Windmill ships releases frequently. Because the server and worker connect to the same repository, railway.toml deliberately leaves out deploy-level configuration like the healthcheck path, this project has already confirmed that config-as-code in that file applies to every service connected to a repo, not just the one it was intended for, so per-service settings are configured through the dashboard instead.

How Windmill Compares to the Alternatives

Vs. Retool: Retool has a polished proprietary builder and requires no infrastructure knowledge, but its Business plan runs $50-65 per builder per month and self-hosting needs an Enterprise contract. Windmill trades some of that polish for code-first scripts you fully own, at no per-builder cost.

Vs. Airflow: Airflow is the established standard for complex data pipelines at scale, but typically needs a scheduler, webserver, and meaningfully more infrastructure to run well. Windmill runs as a lightweight server-plus-worker pair, a real fit for teams whose orchestration needs don't require Airflow's full operational weight.

Vs. n8n: n8n is visual-node-first, connecting pre-built integration blocks with optional code steps. Windmill flips that: script-first, with an optional visual flow layer on top, plus the ability to auto-generate a usable UI directly from a script's parameters, something n8n doesn't do.

Getting Started

After deploying, give the healthcheck a moment to pass, then open your Railway domain.

Log in with the default credentials, admin@windmill.dev and changeme, and change the password immediately. This isn't a placeholder specific to your deployment, it's Windmill's own publicly documented default superadmin account, seeded into the database the moment it first starts up. Treat it exactly like you would any other exposed default credential: change it before doing anything else, not after you get around to it.

Once you're in, write your first script in whatever language you're most comfortable with. Windmill auto-generates a basic UI from the script's parameters immediately, useful for testing it works before building anything more elaborate. From there, chain it into a flow if it needs to run alongside other steps, add a schedule if it needs to run automatically, or build a custom app around it using the drag-and-drop app builder if you need something more polished than the auto-generated form.

One thing worth confirming directly rather than assuming: trigger a script that's genuinely meant to run in the background (not just test it inline in the editor) and confirm it actually completes via the worker, not just that it queues. The server and worker are separate processes here, and a queued-but-never-executed job is a real failure mode worth ruling out on day one, not discovering the first time you actually depend on a scheduled job firing.

It's also worth setting up your first real schedule early and letting it fire at least once before building anything that depends on it. Cron-based automation is easy to configure and forget about, and the only real way to know a schedule works is watching it actually trigger, not just confirming the cron expression parses correctly when you save it.

Why Deploy Windmill-Self-Hosted 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 Windmill-self-hosted 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.

Frequently Asked Questions

Is the default login actually a security risk?

Yes, and it's worth taking seriously. admin@windmill.dev / changeme is documented publicly by Windmill itself, not something unique to your instance. Change the password the moment you first log in, before doing anything else on the deployment.

Do I need both the server and worker running for anything to work?

Yes. The server handles the API, UI, and scheduling logic; the worker is what actually executes scripts and flows. Without a worker running, jobs queue but never complete.

Can I use Windmill without learning a new language?

Yes, that's the core design. Scripts are plain Python, TypeScript, Go, Bash, or SQL, whatever your team already knows, not a proprietary DSL.

Does this template include code-editor autocomplete?

No. This template matches Windmill's simpler, widely-deployed architecture (server, worker, Postgres), which doesn't include the optional LSP service. Scripts write, save, and run normally, without Monaco-editor-style autocomplete while writing them.

Will my scripts and flows survive a redeploy?

Yes, as long as the Postgres database this template provisions stays attached to your project. Scripts, flows, execution history, and user accounts all live there.

Where can I download Windmill?

Source code is at github.com/windmill-labs/windmill, with Docker images published to ghcr.io/windmill-labs/windmill. This template pulls a specific verified version automatically.