When the Windmill Community Edition is enough and when Enterprise is needed
The free self-hosted Community Edition fits a small team that runs a few workspaces, keeps its user and group count under the limits, and can manage accounts by hand. Enterprise becomes the better choice once an identity provider mandate, an audit evidence requirement or growth pushes you past those limits. Windmill's pricing page lists Community with unlimited executions but capped at 3 workspaces, 50 users and 4 groups as of October 2026, so count your current workspaces, users and groups, plus the people you expect to add within the planning period. If you are under all three caps and no policy requires automated identity provisioning, Community covers the core platform: scripts in Python, TypeScript, Go, Bash and more, composed into flows and low-code apps.
Choose Enterprise when a policy or control names a capability that Community does not list. The pricing page lists SAML and SCIM for identity provider mandates, audit logs for audit evidence, external secret backends such as Vault and AWS Secrets Manager, full Git sync for Git-based change control, autoscaling, and Prometheus and OpenTelemetry support. Ask Windmill whether any Community workaround exists for the feature you need, and who would build and maintain it, since that work carries its own cost. Enterprise is priced per developer and operator on top of compute units, with a starting point of $120 per month for the self-hosted tier according to the pricing page as of October 2026, so request a quote built on your actual seat mix.
Which Windmill features are free and which are paid
This table compares the free self-hosted Community Edition with the paid Enterprise Edition by workspace limits, identity, audit, secrets and operations features. Read it as a list of what changes when a team grows past three workspaces or needs SSO provisioning, audit trails or external secret backends. The feature list and limits come from Windmill's pricing page as of October 2026, so confirm current limits with Windmill before you buy.
| Capability | Community Edition | Enterprise Edition |
|---|---|---|
| Executions | Unlimited executions | Unlimited executions, with compute units priced on top; confirm how units are metered |
| Workspaces | Up to 3 workspaces | Confirm the workspace limit for your plan with Windmill |
| Users and groups | Up to 50 users and 4 groups | Priced per developer and per operator; confirm user and group limits |
| SAML and SCIM | Not listed as included | Included |
| Audit logs | Not listed as included | Included |
| External secret backends | Not listed as included | Included, including Vault and AWS Secrets Manager |
| Full Git sync | Not listed as included | Included |
| Autoscaling | Not listed as included | Included |
| Prometheus and OpenTelemetry | Not listed as included | Included |
How licensing and support differ between the two editions
The Community Edition and Enterprise Edition differ in what you may legally do with the code and in what the vendor commits to after purchase. Read the license split first, then the support and update terms, because they determine who in your organization can run Windmill and under what conditions.
Source under AGPLv3 and Apache-2.0
Source compiled without the enterprise feature flag is available under AGPLv3 and Apache-2.0. The AGPLv3 network clause matters if you modify Windmill and offer it to users over a network, so have counsel confirm how your internal changes and any customer-facing portal would be treated. Confirm which license applies to each file you build from before you fork or patch anything.
Proprietary code in prebuilt images
The prebuilt Community Edition images include proprietary code. That code is free for internal use, so an internal team running Windmill for its own automation is covered. Building from source with the enterprise feature flag left off does not carry that proprietary code, which is a different path to confirm with your legal team before you choose a deployment method.
Commercial license for managed services
Offering Windmill as a managed service to other organizations, or reselling it, requires a commercial license under the terms the repository describes. This applies to consultancies and MSPs that host Windmill for clients, even when the client pays for the infrastructure. Ask Windmill in writing whether your delivery model needs a commercial license before you quote it to a customer.
What Enterprise changes for support
Enterprise is a paid self-hosted edition, so the purchase changes the commercial relationship: you are buying a contract alongside the software. Ask whether vendor support is included, what hours and response channels apply, and which severity levels are covered. Support terms and any SLAs are set out in your contract, so confirm them in writing with Windmill rather than assuming them from the public pricing page.
Update and patch access
Ask Windmill how security patches and version upgrades reach each edition, and whether Enterprise customers receive fixes on a defined schedule. Windmill's release cadence is frequent, with v1.840.0 released on October 17, 2026, so an upgrade plan matters even on the free edition. Your internal team should plan who applies updates, how they test them, and how long a patched version stays supported.
Price structure and what to quote
The public Enterprise price starts at $120 per month and is billed per developer at $20 per month each, per operator at $10 per month each, plus compute units. These are recurring charges, so model them for every year you run Windmill. Request a written quote that lists the developer and operator counts, compute units, support scope and any term or renewal conditions.
What the free edition is missing for typical enterprise needs
Most enterprise reviews of Windmill start with the same controls, and the Community Edition covers some of them without covering all. Centralized identity lifecycle is the first gap to check. Community Edition is capped at 3 workspaces, 50 users and 4 groups, so an organization that exceeds 50 users or needs more groups than that will hit the limit before it reaches any feature question. Enterprise adds SAML for single sign-on and SCIM for automated provisioning and deprovisioning, which is the control that removes departing staff from the platform when the identity provider removes them. Audit logs cover the evidence side of the same review, and the team should ask which events they record and how long they are retained in the deployment they plan to run.
The next controls concern how scripts handle credentials and change. Community Edition has no external secret backend in the supplied feature list, while Enterprise adds external secret backends such as Vault and AWS Secrets Manager, so credentials can stay out of script bodies and be retrieved at run time. Change review is the other gap: Enterprise adds full Git sync, which lets scripts and flows move through the same pull request and approval path as other infrastructure code. Elastic workers are the last item. Enterprise adds autoscaling, and the team should size the worker pool against its peak load using the one-worker-per-vCPU rule of thumb in Windmill's README rather than assuming the free tier will scale on its own.
Some of these needs can be met outside the platform. An identity provider with its own lifecycle tooling, an existing secrets manager reached through a script, or a Git review process enforced in the deployment pipeline may satisfy the auditor without a paid feature. Ask your security and compliance leads to write each requirement as a control statement, then check whether Windmill itself, your surrounding tooling or a paid feature closes it. Confirm the current feature list and license terms directly with Windmill on its pricing page before you rely on this comparison, since the tiers and limits are published by the vendor and may change.
Which Windmill edition fits which team
A single platform team with a small user base usually starts on the free self-hosted Community Edition. Its limits of 3 workspaces, 50 users and 4 groups fit a team where a few engineers build scripts and flows in one or two workspaces. Executions are unlimited, so run volume alone does not force a paid plan. Enterprise becomes relevant only when the team needs one of the features Community does not include.
- Headroom on the limits: Count workspaces, users and groups for the next budget cycle, not only for today.
- Proprietary code in images: Prebuilt Community images include proprietary code that is free for internal use. Confirm that your use stays internal, because managed services or reselling need a commercial license.
- Sizing: The README gives a rule of thumb of one worker per vCPU with 1 to 2 GB of RAM. Treat it as a starting point and measure your own job load.
- Operations ownership: A small team still owns upgrades, backups and the database. The README documents external PostgreSQL services such as AWS RDS, GCP Cloud SQL and Azure, which can reduce that work.
Check the current limits on the Windmill pricing page before deciding, since the figures are listed as of October 2026.
A regulated organization with an identity provider mandate usually needs centralized sign-in, automated provisioning and audit evidence from day one. The Windmill pricing page places SAML, SCIM and audit logs in the Enterprise Edition, so an identity mandate often moves the decision from Community to Enterprise regardless of team size. The question then becomes which Enterprise features map to your control set and what the paid tier costs at your headcount.
- Single sign-on and provisioning: SAML and SCIM are Enterprise features. Confirm how your identity provider handles SCIM deprovisioning against Windmill's current documentation before you rely on it.
- Secrets custody: External secret backends such as Vault and AWS Secrets Manager are Enterprise features. Check whether your key custody policy requires them.
- Change control: Full Git sync is an Enterprise feature. Ask how scripts and flows move through your review and approval process.
- Cost drivers: Enterprise pricing is set per developer, per operator and by compute units. Ask for a written quote that states the headcount and compute assumptions behind each line.
Ask the vendor to confirm which features apply to your deployment model. Auditors and certification bodies, not the vendor or DeployOpen, decide whether the controls satisfy your framework.
A multi-team internal developer platform puts many product teams on one Windmill instance. The Community limits of 3 workspaces, 50 users and 4 groups are the first constraint this model reaches, because each team typically wants its own workspace and group structure. Once teams share queues and workers, capacity planning and observability become platform concerns, and several of the tools for those concerns sit in the Enterprise tier.
- Workspace and group count: Three workspaces and four groups can run out quickly once each team has its own space. Map teams to workspaces before you commit to a tier.
- Autoscaling: Autoscaling is an Enterprise feature. Without it, you plan worker capacity by hand using the per-vCPU sizing guidance.
- Monitoring: Prometheus and OpenTelemetry support is an Enterprise feature. Confirm that it matches the monitoring stack you already run.
- Shared queue behavior: Workers pull jobs from a PostgreSQL queue and jobs are sandboxed with nsjail. Ask how the platform keeps one team's heavy jobs from delaying others.
Test with a representative multi-team workload and confirm the Enterprise feature set on the current pricing page before buying seats for every developer.
What drives the cost of Windmill Enterprise
This table breaks down what you pay for when you self-host Windmill, separating the free Community license from the Enterprise subscription and the infrastructure and staff time that both editions consume. Read it as a checklist: each row shows who is paid, whether the cost is one-time or recurring, and what to request in writing before you compare totals. The main takeaway is that the license line is only one part of the total cost of ownership.
| Cost component | Who is paid, one-time or recurring | What drives it, and what to ask for |
|---|---|---|
| Community Edition license | No license fee. Recurring infrastructure and staff time still apply. | Free self-hosted use with unlimited executions, capped at 3 workspaces, 50 users and 4 groups (Windmill pricing page, October 2026). Confirm the caps fit your org chart. |
| Enterprise base subscription | Recurring, from $120 per month for self-hosted Enterprise (Windmill pricing page, October 2026). | Starting price only. Ask the vendor which tiers, minimums and billing terms apply to your deployment size. |
| Per-developer seats | Recurring, $20 per month per developer (Windmill pricing page, October 2026). | Count developers who publish or edit scripts and flows. Ask whether read-only or viewer users are billed. |
| Per-operator seats | Recurring, $10 per month per operator (Windmill pricing page, October 2026). | Count people who run or monitor jobs without editing. Ask how operators are defined in the contract. |
| Compute units | Recurring, billed on top of seats (Windmill pricing page, October 2026). | Driven by worker capacity you run. Ask how units are metered, how they scale with autoscaling and what happens at peak. |
| Self-hosted infrastructure | Recurring, paid to your cloud or data center provider. | Workers, API servers and a PostgreSQL database, including external managed PostgreSQL. Sizing guidance in the README is roughly one worker per vCPU with 1 to 2 GB of RAM. Confirm with your own load tests. |
| One-time setup and integration | One-time, paid to your staff or an implementation partner under a written scope. | SAML and SCIM configuration, external secret backend wiring, Git sync setup and migration of existing scripts. Ask for a fixed-scope deliverables list with acceptance criteria. |
| Ongoing operations and upgrades | Recurring, paid to your staff or a retainer provider. | Frequent releases mean regular upgrade testing. Ask the vendor for its upgrade and support terms for your edition, and budget the review time. |
Moving from Community to Enterprise and back
This sequence shows how a self-hosted Windmill team moves from Community Edition to Enterprise, then checks what a return to Community would break. Each step ends with a record your team can review before the next one starts.
Confirm the license and edition entitlement
Before changing anything, the license owner confirms with Windmill which edition and seat counts the organization has purchased, and that the self-hosted Enterprise Edition covers the way you run it. Windmill's pricing page describes Enterprise as priced per developer, per operator and per compute unit, so the quote should state those counts in writing. Ask Windmill how the Enterprise feature flag is enabled in your build and which images you should pull. You are done when the purchased counts and the enabled edition match a written record that the platform owner has signed off.
Review workspace, user and group counts
The platform owner exports the current number of workspaces, users and groups and compares them with the Community limits of 3 workspaces, 50 users and 4 groups listed on Windmill's pricing page. Anything above those limits is a reason to move before adding new people or teams. Record which workspaces and groups hold production flows, since those are the ones that cannot be interrupted. You are done when the inventory shows current counts against each limit and a named owner for each production workspace.
Plan identity and secrets integration
The identity owner maps how users will sign in once SAML and SCIM are enabled, including which groups from your directory should map to Windmill groups and who deprovisions leavers. The security team decides which secret backends, such as Vault or AWS Secrets Manager, will replace secrets stored inside Windmill, and lists every script that reads a secret today. Confirm the exact configuration steps with Windmill and test them in a non-production instance first. You are done when a test user can sign in through the new identity path and every secret reference has a planned replacement.
Move scripts and flows under Git sync
The platform team connects each production workspace to a Git repository using the full Git sync feature, then commits the current scripts and flows as the baseline. Review diffs against the running instance so that no unreviewed change is pushed into production. Restrict direct edits in the UI for production workspaces so changes flow through commits and reviews. You are done when a deployed change can be traced to a commit and a reviewer, and the repository contains every production script and flow.
Test autoscaling against realistic job load
The operations team enables autoscaling in a staging copy and replays representative job volumes, including the longest-running scripts and any scheduled bursts. Windmill's README gives a sizing rule of one worker per vCPU with 1 to 2 GB of RAM, which is a starting point, not a guarantee, so measure queue wait times and memory use yourself. Confirm scaling limits and cost behavior with Windmill before production use. You are done when test runs show queued jobs clearing within the targets your operations team has set and a rollback to fixed workers has been rehearsed.
Enable observability and cut over production
The operations team connects Prometheus or OpenTelemetry to the Enterprise instance, sets alerts on queue depth, worker health and failed jobs, and schedules a cutover window agreed with the teams that depend on the flows. Keep the Community instance and its database snapshot available until the Enterprise instance has run through a full business cycle. You are done when alerts fire in a test, the cutover runbook has been signed off, and the rollback point is documented.
Check limits before reducing back to Community
If you later return to Community Edition, the platform owner compares current counts of workspaces, users and groups with the 3 workspaces, 50 users and 4 groups limits. Anything above those numbers may block existing content from being used until it is reduced, so decide in advance which workspaces, users or groups to retire or merge. Also list Enterprise-only features your flows depend on, including SAML and SCIM sign-in, external secret backends, full Git sync and autoscaling, and plan how each one will be replaced. You are done when a written reduction plan shows every item that exceeds a limit or depends on an Enterprise feature.
Confirm the procedure with Windmill
Before any downgrade, the license owner asks Windmill to confirm in writing how Community limits are enforced on existing content, what happens to data and secrets stored under Enterprise features, and which image and configuration to use. Ask whether the Community image still contains the proprietary code described in its repository and what license terms apply to your internal use. Keep the answers with the change record. You are done when Windmill's written confirmation is filed alongside the reduction plan and approved by the platform owner.
Questions buyers ask before choosing a Windmill edition
Can we run Windmill Community Edition in production inside our own company?
Yes, for internal use, provided your team stays within the Community limits. The free self-hosted Community Edition allows unlimited executions, with a cap of 3 workspaces, 50 users and 4 groups, as listed on Windmill's pricing page as of October 2026. The prebuilt Community images include proprietary code that is free for internal use, but managed services or reselling the product require a commercial license. Confirm with Windmill's licensing terms how your own use case is classified before you depend on it. If you expect more workspaces, users or groups, or you need features beyond the Community limits, the Enterprise Edition becomes the relevant option.
What does the Windmill Enterprise price depend on?
The published self-hosted Enterprise Edition starts at $120 per month, according to Windmill's pricing page as of October 2026. The total is driven by developer seats, which are listed at $20 per month each, operator seats, listed at $10 per month each, and compute units. Your bill therefore grows with the number of people who build flows and apps, the number who only operate or run them, and how much compute your workloads consume. Ask Windmill for a quote that states seat counts for each role, the compute assumptions behind it and whether any figures change at renewal. Separately, DeployOpen prices its work from a written scope, so the platform fee and the implementation fee should be requested as two distinct lines.
How much effort does self-hosting Windmill take?
Windmill documents self-hosting with Docker Compose or Kubernetes Helm charts, and it supports external PostgreSQL databases such as AWS RDS, GCP Cloud SQL and Azure. Windmill's README gives a sizing rule of thumb of one worker per vCPU with 1 to 2 GB of RAM, which is a starting point rather than a capacity plan. The main effort sits in choosing the deployment target, provisioning and backing up PostgreSQL, sizing workers for your script mix, setting up identity and secrets, and keeping up with a release cadence that is frequent. Windmill's backend uses stateless API servers and workers that pull jobs from a PostgreSQL queue, so the database deserves the most attention in your runbooks.
How long does a migration from Community to Enterprise take, and what drives it?
No migration duration is published in the researched facts, so confirm the timeline with Windmill and with your own environment before planning. The work depends on how much you have built: the number of workspaces, users and groups, the scripts and flows in use, and whether you already use external secret stores or identity providers. Moving to Enterprise features such as SAML and SCIM, external secret backends, full Git sync and autoscaling changes how identity, secrets and deployments are wired. A fixed-scope plan with written deliverables makes the effort visible, and a DeployOpen engagement would be scoped in writing after an assessment of your current setup.
Can DeployOpen plan, implement and harden Windmill inside our infrastructure?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. That applies to Windmill whether you run the Community or Enterprise Edition, with the scope agreed in writing before work starts. Most engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so the quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
What does our team need to provide for a Windmill project?
Your team needs to decide who owns the platform after go-live, and to supply access to the environment where Windmill will run. Typical inputs include a target for Docker Compose or Kubernetes, an external PostgreSQL service with backup and restore responsibilities defined, identity provider details if you plan to use SAML or SCIM, and a secret store if you plan to use external secret backends. Someone on your side should own script review, workspace and group structure, and access approvals. Ask any implementation partner to list these dependencies in the written scope so gaps are visible before the work starts.
Which Windmill features need the Enterprise Edition?
According to Windmill's pricing page, the Enterprise Edition adds SAML and SCIM, audit logs, external secret backends such as Vault and AWS Secrets Manager, full Git sync, autoscaling, and Prometheus and OpenTelemetry support. If your requirements include single sign-on with user provisioning, central audit trails, or secrets held outside the platform, those are the features to verify. Check whether your security team needs audit log retention or export that goes beyond what the Community Edition provides, and confirm current feature availability with Windmill before you sign.
How DeployOpen scopes Windmill edition work
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside the client's own infrastructure, including their cloud accounts, data centers and air-gapped networks. For a Windmill deployment, that work can cover the Docker Compose or Kubernetes Helm setup, the external PostgreSQL database, worker sizing, identity wiring and the backup and upgrade routine. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts. Quotes follow from that written scope. DeployOpen does not publish a price list, so a quote will not be a rate card applied to a number of seats.
The edition decision changes the scope. If your team needs the Enterprise features covered on this page, such as SAML and SCIM, external secret backends, full Git sync or autoscaling, the written scope should name each one, the identity provider or secret store involved and who will test it. Ask the vendor to confirm current seat and compute pricing on its pricing page before the quote is finalized, since those figures change over time. Ask for the Community Edition limits to be checked against your planned workspace, user and group counts as well.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, so the scope should list the evidence DeployOpen will prepare and leave the assessment itself with your auditor. Ongoing support, upgrades and continuous testing are available as a retainer, which suits teams that expect frequent Windmill releases to be applied and tested after the initial deployment.
