Self-hosted Retool alternative: run Windmill without managing Docker

Internal tools often start with one useful script. Then the script needs a form, a schedule, a webhook, approval steps, secrets, logs, and a safe place to run. At that point the small automation has quietly become a platform you have to maintain.

Windmill tackles that problem by turning scripts into workflows, APIs, scheduled jobs, and internal applications. It is now available in the Caliber Node Cloud Apps catalog with its complete server, worker, and PostgreSQL stack.

What is Windmill?

Windmill is an open-source developer platform for building automations and internal tools. You can write code in languages such as Python, TypeScript, Go, Bash, PHP, Rust, and SQL, expose scripts as webhooks, connect steps into flows, and build interfaces on top of them.

That makes Windmill a useful self-hosted alternative to Retool for internal applications, while also overlapping with workflow tools such as n8n and job orchestrators such as Airflow or Temporal. It is especially compelling when your team already has scripts and would rather reuse real code than rebuild every task in a proprietary visual editor.

What you can build

• Internal tools: create forms, dashboards, and operational interfaces backed by scripts.
• Workflows: connect code steps with branching, retries, approvals, and reusable inputs.
• Webhooks and APIs: turn a script into an endpoint without writing a separate web service.
• Scheduled jobs: run reports, synchronization tasks, cleanup jobs, and recurring operations.
• Database automations: query or update supported databases from controlled resources and scripts.
• Secrets and resources: keep credentials separate from the source code that consumes them.

Why self-host Windmill?

Automation systems sit in a sensitive position. They often hold API keys, database credentials, deployment tokens, and access to business data. Self-hosting gives you control over where those workflows and secrets live, how the instance is exposed, and when the software is updated.

The trade-off is operational work. Windmill is not honestly a one-container application. Its self-hosting architecture requires PostgreSQL for state, a public server for the interface and API, and one or more private workers that execute jobs. Someone still has to connect those pieces, persist the database, generate credentials, route HTTPS, and keep updates from replacing state.

What Caliber Node deploys

Choosing Windmill from our catalog creates the complete small-instance topology:

• a Windmill server for the web interface and API
• a private Windmill worker for scripts and workflows
• a private PostgreSQL database holding the instance state and job queue
• persistent database, dependency-cache, and worker-log volumes
• a generated administrator password shown in the Credentials tab
• an HTTPS app address with optional custom-domain support

Windmill's upstream first login is documented as admin@windmill.dev with the password changeme. Leaving that account exposed on a fresh public hostname would create a claim race. Our deployment signs in locally during provisioning, replaces the fixed password with a unique generated credential, verifies the new login, and only then reports first-run account setup as complete.

A deliberate security boundary

Windmill can optionally use privileged container features for additional worker process isolation. A privileged worker is not an acceptable default on a shared application host because it weakens the Docker boundary protecting the host and other customers.

Our managed template therefore gives the worker no privileged mode and no Docker socket. Standard scripts, flows, schedules, webhooks, and internal applications work normally, but a workflow that specifically expects to launch sibling Docker containers is outside this template's scope. We would rather state that boundary clearly than make a broad feature promise by weakening tenant isolation.

What we tested

Before adding Windmill, we booted the same three-service topology on a live Caliber Node app host with the production capability restrictions. We confirmed that the server health endpoint answered, PostgreSQL migrations completed, and the worker registered and listened for jobs.

We also tested the credential transition end to end: the documented default login worked only during the private provisioning step, the password-change API accepted the generated credential, the old changeme password stopped working, and the generated password successfully signed in. The test containers, network, and volume were removed after validation.

How much capacity does it need?

Windmill is heavier than a single static website or small SQLite application because it runs a database, server, and worker together. The Caliber Node template requires at least 1 vCPU and 2 GB RAM. That is a practical starting point for personal automations, testing, and light internal workloads rather than a promise of high-throughput job processing.

If your flows run several CPU-heavy or memory-heavy jobs at once, allocate more capacity. Windmill's own guidance recommends roughly one worker per vCPU with 1–2 GB of memory for the worker, so the work your scripts perform matters more than the idle dashboard.

Deploy Windmill without assembling the stack

1. Open the Caliber Node Cloud Apps catalog and select Windmill.
2. Choose a subscription with at least 1 vCPU and 2 GB RAM available.
3. Select the region, storage allocation, and app address.
4. Deploy the app and open its Credentials tab.
5. Sign in with the generated administrator password, confirm the instance settings, and create your first workspace.

If you want to turn scripts into useful tools without maintaining a Docker host around them, explore Caliber Node Cloud Apps and deploy Windmill from the catalog.