Prefect vs Windmill: when each one is the right choice
Choose Prefect when your work is data pipelines written by Python engineers and your team wants orchestration code to live as ordinary Python functions. Prefect is Apache-2.0 licensed and turns decorated functions into flows with scheduling, caching, retries and event-based automations. Choose Windmill when you need scripts, flows and internal apps written in several languages, and you want one platform to host both the jobs and the screens that operators use to run them. Windmill is also open source with a self-hosted path, and it supports Python, TypeScript, Go, Bash, SQL and more. Both are viable self-hosted options, so the decision turns on who writes the work and how your governance requirements are met, not on which tool is better overall. Start with the authors. If your data engineers already maintain Python codebases and tests, Prefect fits that workflow directly. If your automation is written by platform, security or operations staff who work in Bash, PowerShell, SQL or TypeScript, Windmill's language range matters more. Next, list the governance controls you must demonstrate. In Prefect, SSO, RBAC and audit logs are documented as Prefect Cloud features that the self-hosted server does not include, so you must either pay for Prefect Cloud or build those controls yourself. In Windmill, SAML, SCIM and audit logs sit in the paid Enterprise Edition for a self-hosted deployment. Ask both vendors for current prices in writing, because the plan you need determines the real recurring cost.
Finally, decide whether you want one platform for apps as well as jobs. Windmill can compose scripts into flows and low-code apps, which suits internal tools with approval screens. Prefect focuses on orchestration and observability of pipeline runs, so a separate application layer is usually part of the design. Check the operating model before you commit. Self-hosted Prefect server needs PostgreSQL for production, and multi-server setups add Redis and a load balancer. Windmill's workers pull jobs from a PostgreSQL queue and its README suggests roughly one worker per vCPU with 1 to 2 GB of RAM as a starting point. Run a pilot with one real pipeline, one script in your second language, and one access-control review, then compare the results against your audit requirements.
Which platform fits which scenario
This table matches common situations to the platform with the better starting fit, with the condition under which the other platform wins. Read each row as a starting point, then test it against your team's languages, your hosting constraints and whether you need SSO or audit logs before you pay for a plan.
| Situation | Better fit | Why, and when the other platform wins |
|---|---|---|
| Python data pipelines owned by data engineers | Prefect | Flows are plain Python functions with scheduling, retries and caching, and Prefect requires Python 3.11 or later. Windmill fits better if the pipeline team also needs SQL, TypeScript or Go steps in the same workflow. |
| Mixed-language internal tooling | Windmill | Windmill scripts can be written in Python, TypeScript, Go, Bash, SQL, GraphQL, PowerShell and Rust, then composed into flows or low-code apps. Prefect is Python-first, so Prefect wins if every author writes Python. |
| Ops automation for infrastructure teams | Windmill | Shell, PowerShell and API calls can run as scripts with sandboxed jobs, and workers pull from a PostgreSQL queue. Prefect fits better if the automation is already Python and needs event-based automations tied to pipeline runs. |
| Internal web apps built over scripts | Windmill | Windmill composes scripts into low-code apps in the same product. Prefect's UI monitors flow runs and does not replace an internal app builder, so choose Prefect only if the front end is a separate project. |
| Air-gapped sites | Depends on the stack (confirm with both vendors) | Both can run self-hosted, and Windmill documents Docker Compose and Kubernetes Helm charts with external PostgreSQL. Confirm image sourcing, dependency mirroring and licensing for your network with each vendor before choosing. |
| Teams needing SSO without a paid plan | Neither, without a paid plan | Prefect's documentation places SSO and audit logs in Prefect Cloud, and its pricing lists SSO from the Team plan. Windmill lists SAML, SCIM and audit logs in Enterprise Edition, so the free Community Edition does not meet this need in either product. |
| Teams that need a free self-hosted edition with no workspace limits | Prefect | Prefect is Apache-2.0 and self-hosted server is open source. Windmill Community Edition is limited to 3 workspaces, 50 users and 4 groups, so Windmill suits this only while the team stays inside those limits. |
How Prefect and Windmill run work and what that means for operations
Both platforms split work between a control plane that stores state and workers that execute it, but they store and dispatch that state differently. The cards below follow those components in turn and name the operational consequence of each, so a platform team can see where the database, the queue, the messaging layer and the sizing rules will land on their own infrastructure.
Prefect server holds the run state
The self-hosted Prefect server bundles an API, a UI and a database that records flow and task run state, logs, deployments, concurrency limits, variables, artifacts, work pool status, events and automations. Everything the team later audits or troubleshoots lives in that database. Confirm where it will run, who owns its backups and how long run history must be retained in your environment.
Prefect production needs PostgreSQL
Prefect server defaults to SQLite, which suits evaluation rather than a shared production environment. For production the self-hosted documentation points to PostgreSQL, and a multi-server deployment requires PostgreSQL 14.9 or later. Ask your DBA whether an existing managed PostgreSQL service meets that version floor and how failover will be handled.
Prefect multi-server adds moving parts
Running more than one Prefect server adds Redis for event messaging and a load balancer in front of the API servers. Each added component needs its own patching, monitoring and failure plan. Teams that only need one server should avoid these pieces until the workload justifies them, and should confirm whether their platform team already operates Redis and load balancers at the required availability.
Prefect work pools and workers dispatch runs
Work pools and workers sit between the server and your execution environment. The server records work pool status, and workers poll for scheduled runs and launch them on your infrastructure. Consequently, the place where workers run, their network path back to the server and their credentials determine whether runs start at all. Confirm worker placement for each execution zone before committing to a deployment layout.
Windmill workers pull from PostgreSQL
Windmill's API servers are stateless, and its workers pull jobs from a PostgreSQL queue. That makes PostgreSQL the single place where queued work, job state and the service's own records converge, so its capacity, backups and high-availability design affect every workspace at once. Ask whether the database will be a dedicated instance and how queue depth will be monitored under peak load.
Windmill sizes workers by vCPU
Windmill's documented rule of thumb is one worker per vCPU with 1 to 2 GB of RAM. Treat that as a starting estimate, not a capacity guarantee, because real script memory use depends on the languages and dependencies each team runs. Benchmark a representative set of scripts in your environment and build the worker count and memory budget from those results.
Windmill sandboxes jobs with nsjail
Windmill runs jobs in a sandbox built on nsjail, which limits what a script can reach on the host. This matters when teams let many users submit scripts that call internal systems. Security teams should confirm how the sandbox behaves on their host operating system and container runtime, and whether it meets their internal isolation requirements for untrusted code before approving broad script authorship.
Capabilities that decide the choice, side by side
This table sets Prefect's Python-first model against Windmill's polyglot platform on the capabilities that usually settle the shortlist. Read each row as a question to answer for your own team, then confirm any cell marked for confirmation against current documentation before you commit.
| Capability | Prefect | Windmill |
|---|---|---|
| Authoring languages | Python only; requires Python 3.11 or later | Python, TypeScript, Go, Bash, SQL, GraphQL, PowerShell, Rust and more |
| Composition model | Python functions turned into flows and tasks | Scripts composed into flows or low-code apps |
| License | Apache-2.0 | AGPLv3 and Apache-2.0 without the enterprise feature flag; prebuilt Community Edition images include proprietary code free for internal use |
| Backend and job execution | Work pools and workers; server stores run state, logs, deployments and events | Stateless API servers and workers pulling jobs from a PostgreSQL queue |
| Self-hosted database | SQLite by default; PostgreSQL for production; PostgreSQL 14.9 or later, Redis and a load balancer for multi-server | PostgreSQL queue; external PostgreSQL such as AWS RDS, GCP Cloud SQL or Azure supported |
| Sandboxing of jobs | Confirm with the vendor how worker isolation is handled in your setup | Jobs sandboxed with nsjail |
| Self-hosted deployment options | Self-hosted Prefect server alongside managed Prefect Cloud | Docker Compose or Kubernetes Helm charts |
| SSO and SCIM | SSO from the Team plan in Prefect Cloud; confirm SCIM support | SAML and SCIM on Windmill Enterprise Edition |
| Audit logs and RBAC | RBAC, audit logs and SSO are Prefect Cloud features, not part of self-hosted server | Audit logs on Windmill Enterprise Edition; confirm RBAC scope in the Community Edition |
| External secret backends | Confirm the options available in your deployment | Vault and AWS Secrets Manager on Windmill Enterprise Edition |
What each license and edition includes and what is paid for
Prefect is licensed under Apache-2.0, so the framework and the self-hosted server can be run inside your own infrastructure without a license fee. The self-hosted server bundles an API, a UI and a database that records flow and task run state, logs, deployments and automations. Prefect Cloud is a separate, paid, managed service with its own plan structure, and the open-source server does not include the RBAC, audit logs or SSO that the server documentation attributes to Cloud.
- Hobby plan: free, listed on the Prefect pricing page as the entry tier for Prefect Cloud.
- Starter plan: listed at $100 per month.
- Team plan: listed at $100 per user per month, and SSO is included from this tier.
- Enterprise plan: custom pricing, with object-level RBAC and multiple workspaces.
- Self-hosted server: no license fee under Apache-2.0, but your team pays for the PostgreSQL, Redis and upgrade work described in the self-hosted documentation.
Before you commit, confirm with Prefect which plan includes the identity and audit features your auditors expect, and whether per-user pricing on Team will scale with the people who need access to flows.
Windmill's source code compiled without the enterprise feature flag is licensed under AGPLv3 and Apache-2.0, but its prebuilt Community Edition images include proprietary code. That code is free for internal use, and managed services or reselling require a commercial license. The free self-hosted Community Edition offers unlimited executions, with limits on the number of workspaces, users and groups, so a growing team may hit those limits before it hits a usage cap.
- Community Edition: free to self-host, with unlimited executions, limited to 3 workspaces, 50 users and 4 groups as of October 2026.
- Enterprise Edition: self-hosted, starting at $120 per month as of October 2026.
- Developer seats: priced at $20 per month each in Enterprise.
- Operator seats and compute: operators are priced at $10 per month each, and compute units are billed on top.
- Enterprise features: SAML and SCIM, audit logs, external secret backends, full Git sync, autoscaling, and Prometheus and OpenTelemetry support.
Confirm with Windmill whether a managed service or internal reselling would trigger the commercial license, and ask for a quote that separates developer seats, operator seats and compute units.
SSO and audit logs are where the two products charge differently. In Prefect, SSO starts at the Team plan and object-level RBAC sits in Enterprise, so the cost scales with user count and the tier you need. In Windmill, SAML, SCIM and audit logs are bundled in the Enterprise Edition, so the cost scales with seats, operators and compute rather than with an identity feature tier.
- Prefect SSO: included from Team, priced per user per month.
- Prefect RBAC and workspaces: object-level RBAC and multiple workspaces are Enterprise features with custom pricing.
- Windmill SAML, SCIM and audit logs: included in Enterprise, which starts at $120 per month.
- Self-hosted Prefect identity: the open-source server does not include these controls, so plan for compensating controls at the network or proxy layer.
- Totals: exact totals depend on headcount, operator count and compute, and must be quoted by each vendor against your written scope.
Ask each vendor for a line-item quote covering users, seats, compute and the identity features your auditors require, and compare those totals rather than list prices alone.
What drives the running cost of each platform
Infrastructure is the first recurring cost for both platforms, and it grows with how you deploy. A self-hosted Prefect server stores run state, logs, deployments and events in a database, which the documentation says should be PostgreSQL for production. A multi-server setup adds PostgreSQL 14.9 or later, Redis for event messaging and a load balancer. Windmill's stateless API servers and workers share a PostgreSQL queue, so that database is the critical dependency. Its README suggests one worker per vCPU with 1 to 2 GB of RAM as a sizing rule of thumb. Size the worker pool against your real job volume, then price the managed PostgreSQL service, and Redis and the load balancer for Prefect, as separate line items.
People shape the recurring cost more than hardware does. Prefect asks your team to write and maintain Python flows, so the skill pool is engineers who already work in Python data pipelines. Windmill accepts Python, TypeScript, Go, Bash, SQL and other languages, which can reduce the number of specialists needed for scripts and internal apps, but each language adds review, testing and on-call work for whoever owns that code. The paid tier adds its own cost. Prefect Cloud's Team plan is priced at $100 per user per month and includes SSO. Windmill Enterprise starts at $120 per month, priced at $20 per developer and $10 per operator plus compute units, and adds SAML, SCIM and audit logs. Ask for the seat count for each role to be written into any quote, and confirm which audit and identity controls each tier includes in your environment.
Upgrades and one-time work set the rest of the budget. Prefect 3.8.8 was released on October 6, 2026, and the 2.x line still received 2.20.26 on September 2, 2026, so a team on 2.x must plan a migration. The server documentation also warns that new clients can be incompatible with old servers, so client and server versions must move together. Windmill's v1.840.0 release on October 17, 2026 reflects a frequent release cadence, which means recurring patch windows. One-time costs include migrating flows, rewriting schedules, provisioning the database and identity setup, and porting existing scripts. Recurring costs include seats or licenses, hosting, patching and support retainers. Ask for a fixed scope for migration, the database and cache sizing assumptions, the upgrade windows and who performs them, and whether support is priced separately.
Moving work from Prefect to Windmill, or the reverse
This sequence moves a team's scheduled work, code and access model from one orchestrator to the other with the old and new systems running side by side until each job has been proven on the target.
Inventory flows, schedules, deployments and access
The platform owner and the team leads who maintain flows list every Prefect flow, its deployment, schedule, concurrency limit, variable and work pool, or every Windmill script, flow, schedule and app, along with the secrets each one reads and the users and groups that can run or edit them. The output is a single inventory sheet with an owner, a trigger and a required secret for each item. The step is done when every scheduled run in the old system maps to a line in the sheet and someone who did not write the inventory has checked it against the server's run history.
Decide what is rewritten and what is kept
Engineers sort each inventory item into one of three groups: Python flow logic that can run unchanged as a Windmill Python script, logic that must be rewritten in another language Windmill supports, or work better left in place for now. Windmill supports Python, TypeScript, Go, Bash, SQL and other languages, so the choice is made per job, not per platform. The output is a decision record that names the language and owner for each rewritten item. The step is done when the record is signed off by the data platform lead and the security reviewer, who confirm that rewritten jobs keep their inputs, retries and failure alerts.
Stand up the target database and workers
The platform team installs the target system in the team's own infrastructure. For Prefect, that means a self-hosted server backed by PostgreSQL for production, with Redis and a load balancer if more than one server runs. For Windmill, that means Docker Compose or a Kubernetes Helm chart with an external PostgreSQL database and workers sized to the vCPU and memory rule of thumb in the Windmill README. The output is a running target with its database, backups and monitoring in place. The step is done when a test job runs end to end and a restore from backup has been rehearsed in the team's own environment.
Recreate deployments, work pools and permissions
Configuration that does not live in code is rebuilt by hand or by script. In Prefect this covers deployments, work pools, worker types, concurrency limits, variables and automations. In Windmill it covers workspaces, groups, schedules, resource and secret bindings, and app layouts. Permissions are set to match the inventory from the first step, and any SSO, SCIM, audit log or external secret backend settings are configured now because they depend on the edition you run. The output is a configuration checklist signed off against the inventory. The step is done when each item in the checklist has been created and a named reviewer has confirmed that access matches the original.
Run jobs in parallel on both systems
For a defined period, each job runs on both the old and new systems, and the outputs are compared. The team checks result tables, file outputs, alert behavior, retry handling and run duration, and it records any difference. Client and server version compatibility rules differ between the two platforms. Prefect's server documentation notes that old clients work with new servers, but new clients can be incompatible with old servers as fields are added to the REST API, so the team must pin client and server versions and test upgrades during this phase. The output is a parallel-run log. The step is done when every job has matched its baseline output across the agreed window with no unexplained differences.
Cut over schedules and disable old triggers
Once the parallel log is accepted, the team moves each schedule and event trigger to the target system in a planned order, starting with the least critical jobs. The old schedules are paused rather than deleted so they can be re-enabled if a problem appears. The on-call contacts and alert routes are updated at the same time. The output is a cutover record that lists each job, its new trigger and the time it moved. The step is done when the old system shows no active schedules and the target has produced the expected runs for the cutover window.
Retire the old server and keep the evidence
After a stable period agreed by the owners, the old server, workers and database are shut down. Before that, the team exports run history, logs and configuration snapshots that the audit or compliance process needs, and stores them in the team's own database or archive. Git-managed code moves with the repository, but database contents, secrets and users do not transfer automatically and must be handled according to policy. The output is a retirement record with the archive location and the list of revoked credentials. The step is done when access to the old system has been removed and the archive has been tested for readability.
Where implementation projects with each platform usually run long
The most common source of overrun with Prefect is the database and multi-server decision made late. Prefect server uses SQLite by default and PostgreSQL for production, so a team that builds on the default and migrates later will repeat configuration and validation work. Multi-server deployments add PostgreSQL 14.9 or later, Redis for event messaging and a load balancer in front of the API, and each of those needs its own hardening, backup and monitoring plan. Python runtime management is the second recurring cost: Prefect requires Python 3.11 or later, so every worker image, base environment and developer laptop must agree on that version before flows are deployed. Work pool design also needs an early decision, because the mapping of pools to workers, infrastructure and concurrency limits is hard to change once dozens of deployments reference it. Confirm the PostgreSQL and Redis topology with your platform team before the first deployment.
With Windmill, the overrun risk sits in infrastructure sizing and the self-hosting path. The README's rule of thumb is one worker per vCPU with 1 to 2 GB of RAM, which the team should translate into a capacity plan for its own job volume rather than assume it will hold. Windmill's workers pull jobs from a PostgreSQL queue, so the external database (AWS RDS, GCP Cloud SQL or Azure, as the repository documents) becomes part of the critical path and needs its own sizing, failover and backup decisions. Teams also need to choose between Docker Compose and the Kubernetes Helm chart early, since that choice shapes upgrade and secret handling work later. Workspace and group design is a further design task: the Community Edition is capped at 3 workspaces, 50 users and 4 groups, so an access model that exceeds those numbers forces a licensing change mid-build.
Three areas cut across both platforms and usually drive overruns. The first is rewriting existing ad hoc scripts into flows. The effort depends on how much logic lives in scripts that assume local state, shared credentials or manual steps, and that inventory should be finished before any estimate is accepted. The second is identity and audit integration. Prefect Cloud reserves RBAC, audit logs and SSO for paid tiers, and Windmill places SAML, SCIM and audit logs in Enterprise Edition, so the identity model and log retention requirements must be specified before build starts. The third is the edition decision itself. Teams that discover mid-project that they need SSO or audit logs face a choice between a paid plan and a redesign. Ask each vendor for written edition comparisons against your user count, workspace model and retention needs, and make the edition choice a documented gate in the scope.
Questions buyers ask before choosing Prefect or Windmill
Which is cheaper to run self-hosted, Prefect or Windmill?
Both self-hosted cores are free to download, so the difference comes from what you need beyond the free edition and from the people who run it. Windmill's free Community Edition has unlimited executions but is limited to 3 workspaces, 50 users and 4 groups. Its self-hosted Enterprise Edition starts at $120 per month, priced by developers at $20 per month each, operators at $10 per month each and compute units, per Windmill's pricing page as of October 2026. Prefect Cloud plans are Hobby (free), Starter at $100 per month, Team at $100 per user per month and Enterprise at custom pricing, per Prefect's pricing page. Prefect's self-hosted server has no per-user line item, but you pay for PostgreSQL, Redis for multi-server setups, a load balancer and the engineering time to run them. Ask each vendor for a written quote built on your user count, workspace count and compute profile.
Is Windmill Community Edition enough if we need SSO?
No. SAML and SCIM are listed as Windmill Enterprise features on its pricing page, so the free Community Edition does not give you SSO provisioning through those standards. Enterprise also adds audit logs, external secret backends such as Vault and AWS Secrets Manager, full Git sync, autoscaling, and Prometheus and OpenTelemetry support. Confirm the current feature list on the pricing page before you sign, because editions change. If your identity provider requires SAML or SCIM from day one, price the Enterprise tier into the comparison rather than treating the Community Edition as the baseline.
Can Prefect server run in production on SQLite?
No. Prefect server uses SQLite by default, and the self-hosted documentation recommends PostgreSQL for production. Multi-server deployments need PostgreSQL 14.9 or later, Redis for event messaging and a load balancer. Plan the database, backups and connection settings before you move past a single-server test. A pilot on SQLite is reasonable for evaluation, but it should not become the production state store.
What skills does the team need for Prefect compared with Windmill?
Prefect asks for Python. Flows are Python functions, and Prefect requires Python 3.11 or later, so your engineers need to write, test and deploy Python code and understand work pools and workers. Windmill accepts scripts in Python, TypeScript, Go, Bash, SQL, GraphQL, PowerShell, Rust and more, and can compose them into flows or low-code apps. That breadth suits mixed teams, but operators still need to understand the Rust backend, the PostgreSQL job queue and the sandboxing model at a working level. Map the skills you already have against each platform's administration tasks, then decide who owns upgrades and incident response.
How long does implementation take?
It depends on scope, and the timeline must be agreed in writing before work starts. Drivers include the number of workflows to migrate, how many identity and secrets integrations you need, whether you run multi-server Prefect with PostgreSQL and Redis, whether you need Windmill's Enterprise controls, and how much of your existing automation is already scripted. A narrow pilot covering one team's scripts moves faster than a platform-wide rollout with audit and SSO requirements. Ask any implementation partner, including DeployOpen, for a written scope with deliverables and dates.
Can DeployOpen implement this alone, or does it need our team?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. Whether DeployOpen works alone or alongside your staff depends on the scope you agree, including who owns identity decisions, data access and on-call duties. Your team should stay involved in design decisions and handover, so you can run the platform after the engagement ends.
Can our own team do the setup and run it without outside help?
Often yes, if you already run Python services on PostgreSQL and have the people to handle upgrades. Prefect's self-hosted server is a documented path, and Windmill documents Docker Compose and Kubernetes Helm deployments with external PostgreSQL such as AWS RDS, GCP Cloud SQL or Azure. The harder parts are production hardening, backup and restore testing, SSO integration, audit evidence and keeping pace with frequent releases. Prefect 3.8.8 followed 3.8.7 within weeks, and Windmill's README gives a sizing rule of one worker per vCPU with 1 to 2 GB of RAM. Assess your capacity honestly, pilot one workflow, and confirm the upgrade process with the vendor before you commit.
How DeployOpen helps teams choose, implement or migrate
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Prefect vs Windmill, we start by agreeing on what the platform must run, who writes and maintains the jobs, and which identity and audit requirements apply before any build work begins.
How we scope
- Written scope lists which languages, flows or scripts, and which workers and queues, are in the engagement.
- We record whether SSO, audit logs and RBAC are needed, since these shape the Prefect Cloud or Windmill Enterprise decision.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing can be added as a retainer once the scope is settled.
How we build
- We deploy the chosen platform in your environment, including the database, workers and network paths it needs.
- For Prefect, we configure the server, work pools and workers. For Windmill, we set up workers, the PostgreSQL queue and sandboxing.
- We test representative flows or scripts end to end, including retries, failures and access controls.
- We document sizing assumptions, such as worker counts per vCPU, so you can check them against your own workload.
How we hand over
- You receive configuration records, runbooks and an architecture summary that your platform team can maintain.
- We walk your engineers through authoring, deploying and monitoring jobs on the platform you selected.
- Upgrade steps, backup procedures and version compatibility notes are documented for your own change process.
- Open items, such as licensing questions for managed or commercial use, are listed with the owner who must confirm them.
How we support
- Retainers can cover upgrades, monitoring reviews and incident support for the Prefect or Windmill deployment.
- Security testing of the deployed platform and its integrations can be scoped separately under the same written agreement.
- We help you prepare evidence for internal reviews or external assessments, though auditors and certification bodies issue any formal reports.
- Support boundaries and response expectations are written into the retainer, so you know what is covered before you sign.
