Managed Windmill hosting

Workflow and dataOn-prem or your region

Scripts, workflows and internal tools in Python, TypeScript, Go, Bash or SQL, run by workers on your own machines and operated by Pilae. Pilae runs it on your own servers, or in Zurich, Switzerland, and eleven other Pilae Cloud regions.

Talk to us about Windmill

Licence: AGPL-3.0 (Community Edition)
Runs on: Your own hardware, or any of 10+ Pilae regions — six of them in Switzerland and the EU
Upgrades: Pinned, tested against your configuration, applied in your window
Upstream: www.windmill.dev

Running Windmill in production: what it takes

Pin and deploy
A version we have run, not whatever the latest tag is on the day, with PostgreSQL on its own machine or a managed Pilae instance behind it.
Split the workers
A default group for quick jobs and a separate group for heavy or long ones, each sized for its work, so adding capacity is a number rather than a rebuild.
Keep the code in Git
Scripts and flows sync to a repository you own, so a change is a reviewed commit and the instance can be rebuilt from it.
Back up and restore on a schedule
The database goes offsite daily, encrypted. Once a month we restore it into a scratch environment and run a test flow there.
Upgrade in your window
Windmill releases often. The Pilae Agent plans each upgrade, runs it against a copy of your instance first, waits for your approval and applies it in your window.

What Windmill is, and who runs it

Self-hosted Windmill for scripts and workflows

Windmill turns a script into a job. You write a function in Python, TypeScript, Go, Bash or SQL, and Windmill gives it a form, a schedule, a webhook, a run history and a place in a flow with branches, retries and approvals. It covers the ground of Retool Workflows, and it runs on machines you choose.

We operate it on dedicated machines in any of 10+ Pilae Cloud regions, six of them in Switzerland and the EU, or on your own hardware. Workers sit on your private network, so a job that reads the ERP or writes to an internal database does so directly. Nothing internal has to face the internet for an automation to reach it.

Windmill in production: workers, PostgreSQL and Git

PostgreSQL is not optional in Windmill. It holds the code, the run history and the job queue, so we size it, back it up daily to an offsite location in your chosen country and restore it every month. Workers are split into groups so that heavy jobs and quick ones do not compete. Scripts and flows sync to a Git repository you own, which makes every change reviewable and the whole instance rebuildable from the repository and a backup.

Probes check the instance every 60 seconds, and a stuck queue or a failing worker alerts a Pilae engineer. Upgrades go through the Pilae Agent: planned, tested on a copy, approved by you, applied in your window and recorded.

Windmill licence and editions

Its licence file is stricter than the AGPL alone, so the arrangement set out below is settled before anything is deployed.

If you are rebuilding automations as well as scripts, n8n sits next to Windmill for integration-heavy work. Talk to us about the workflows you want to move.

The Community Edition compiled from the public repository is AGPL-3.0. The licence file adds that it may not be sold, resold, served as a managed service, modified or wrapped without an explicit agreement with Windmill Labs, and some features are Enterprise-only under a commercial licence: the Community Edition caps SSO at ten users, has no audit log and keeps job details for up to thirty days. Before deployment we settle the arrangement with Windmill Labs, either an agreement covering our operation of your instance or an Enterprise licence in your name, and state it in your proposal.

Windmill system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

Server: 2 vCPU · 4 GBServes the editor, the API and the scheduler. It does not run jobs.
Workers: 2 or more · 2 GB eachJobs run here. Worker groups separate heavy or long jobs from quick ones so a nightly export cannot hold up a webhook.
Database: PostgreSQLRequired. It holds scripts, flows, run history and the job queue itself, which is why its backup is the backup of the whole instance.
Object storage: S3-compatible bucketFor large job inputs and outputs, and for the dependency cache workers share.
Network reach: Private mesh + egress listWorkers reach your internal systems over the private network. Outbound calls to the internet go only where you allow.
DNS and TLS: 1 hostnameBehind the Pilae gate on port 443. Webhook routes that must be public are opened one by one.

Migrating from Retool Workflows to Windmill

Retool Workflows do not export into Windmill, so each workflow is rebuilt. The work is smaller than it looks, because the logic inside a Retool workflow block is already JavaScript, Python or SQL, and Windmill runs those as ordinary scripts. What changes is the frame around them: triggers become schedules, webhooks or HTTP routes, resources become Windmill resources, and each step becomes a script in a flow you can keep in Git.

List what runs and who calls it
Every workflow, its trigger, its schedule and the systems it touches, from the run history rather than the sidebar. Workflows nobody has run in months are marked for retirement, not migration.
Move the code, then the wiring
Step logic comes across as Windmill scripts in the same language. Credentials become resources and secrets held in the instance, re-issued against the new host rather than copied.
Compare outputs side by side
The same input goes to the old workflow and the new one, and the results are compared before anything is switched.
Cut over trigger by trigger
Schedules and webhooks move one at a time. The old platform stays readable until the monthly and quarterly jobs have run once on Windmill.

A night of jobs on a Windmill worker group

windmill · worker-group heavy7 lines

00:30infojob f/finance/ledger_export: ok in 4m18s, 38,114 rows

01:00infobackup windmill database: ok, checksum verified, copied offsite

01:12infojob f/ops/sync_inventory (python): ok in 11.2s

02:30inforestore drill: ok, 214 scripts and 37 flows present, test flow ran

03:05infojob f/crm/on_signup (webhook): retry 1 of 3, upstream 503

03:05infojob f/crm/on_signup (webhook): ok in 0.9s

05:45infodependency cache warm for python and bun: ok

An example overnight window: a heavy export runs on its own worker group, a webhook job retries against a slow upstream, and the database backup is restored in a scratch environment to prove it.

What Pilae is responsible for

A pinned version

A version we have run, not whatever latest resolves to that day.

A runbook

What it depends on, how it fails, what to do about it. In your repository.

A restore drill

Backups restored on a schedule. A backup nobody has restored is a file.

A patch window

Security updates in a window you agreed, with a rollback ready.

Someone watching

Every endpoint probed on the minute. An alert reaches a person, not a dashboard nobody opens.

Where it runs: zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware
Who holds the credentials: You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.
If you leave: The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What running Windmill costs

On Starter, Windmill runs in Pilae Cloud for CHF 449EUR 479USD 559 a month, hosting and onboarding included. On Business, it is one of up to three apps for CHF 1,590EUR 1,690USD 1,990 a month, on your own servers or in Pilae Cloud. Enterprise is quoted. The plans set what each includes; these are the inputs that move the price around them.

Instance size: The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.
High availability: One machine with tested restores, or a replicated setup that keeps serving when a node fails.
Storage and backups: How much data it holds, how long backups are kept, and point-in-time recovery for its database.
Plan and support: Starter, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.
Region: Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where machines are priced per month. On Starter, Pilae chooses the site.
Sign-on and integrations: Single sign-on, directory sync, mail relays and the other systems the app has to reach.

Windmill: common questions

Is Windmill open source?

The Community Edition is AGPL-3.0, with conditions in the licence file on serving it as a managed service, and some features are Enterprise-only under a commercial licence. We settle the arrangement with Windmill Labs before deployment and write it into your proposal.

What languages can Windmill scripts use?

Python, TypeScript on Bun or Deno, Go, Bash, PowerShell and SQL among others. Each script declares its dependencies and the worker resolves them, so there is no shared environment to break.

Is Windmill a replacement for Retool Workflows?

For scheduled and triggered backend jobs, yes. Windmill also builds simple internal apps on top of scripts. If your team relies heavily on complex Retool front ends, we look at those separately before promising a like-for-like move.

Can Windmill reach systems that are not on the internet?

Yes, and that is the main reason to run it yourself. Workers sit on your private network and call the ERP, the database or the file share directly, without publishing them to a SaaS vendor.

Where are secrets for connected systems kept?

In the instance, encrypted, and visible only to the scripts and groups you grant. Pilae engineers work with named accounts, and every session is recorded in the audit trail of the Pilae console.

Back to apps

Bring us your Windmill. We will tell you what it takes.

Thirty minutes on the deployment you already have, or the one you are about to start.

Start with one workload Book a 30-minute briefing