n8n or Windmill: which self-hosted automation platform fits your team
Choose n8n when the people building automations are business analysts, service owners or ops staff who want a visual canvas connecting SaaS apps and APIs, and choose Windmill when developers want to write scripts, flows and internal apps in languages such as Python, TypeScript or SQL. A platform team shortlisting self-hosted automation should first settle three questions, because each one can eliminate an option before any feature comparison starts. The first is licensing: n8n is under the Sustainable Use License, which limits use to internal business, non-commercial or personal purposes, while Windmill's source compiled without the enterprise feature flag is under AGPLv3 and Apache-2.0, with prebuilt Community Edition images containing proprietary code. The second is who builds and maintains the workflows, since that determines whether a canvas or a code repository is the working surface. The third is whether SSO and Git-based environments must be available without a paid plan.
Those three answers point in different directions, so write them down before the pilot. Ask legal to confirm in writing whether your intended use, including any internal tool you might later offer to a subsidiary or customer, fits the Sustainable Use License or requires a commercial arrangement. Ask engineering leads to name who will change a flow after go-live, and whether that person prefers reviewing a canvas or a pull request. Then check the current n8n pricing page and the Windmill pricing page for the SSO, SAML, SCIM and Git sync features your security team expects in the tier you plan to run, and confirm the editions in the vendors' own documentation rather than relying on this summary. The paragraphs below work through each driver in order.
Which scenarios favor n8n and which favor Windmill
This table maps common team situations to the platform that fits better and the condition that makes it true. Read each row against your own licensing position, identity requirements and who will build the automations. The main takeaway is that n8n favors visual, app-to-app automation and Windmill favors script-first internal tools, and the license terms decide the answer when you plan to embed or resell.
| Scenario | Better fit | Condition that makes it hold |
|---|---|---|
| Business teams wiring SaaS apps together with no-code builders | n8n | Your builders work on a visual canvas and need the 1,500-plus integrations n8n advertises, and they do not need to write code for each step. |
| Developers shipping internal tools and scripts in Python, TypeScript or Go | Windmill | Your engineers want scripts in several languages composed into flows or low-code apps, and they want those scripts to be the primary unit of work. |
| Teams that need SAML SSO in a free tier | Neither as a free feature | n8n SAML SSO is on the Business and Enterprise plans, and Windmill SAML and SCIM sit in its Enterprise Edition. Confirm current tier placement with each vendor before you commit. |
| Teams that must run the tool in an air-gapped or tightly controlled network | Depends on your scale of operations | Both are self-hostable. Confirm the Docker Compose or Kubernetes path, external PostgreSQL options and any outbound license checks in your own environment. |
| Teams that must embed the product in a commercial offering | Neither without a commercial license | n8n's Sustainable Use License limits use to internal business or non-commercial purposes. Windmill managed services or reselling require a commercial license. Get written terms from both vendors. |
| Teams that want a free self-hosted tool with no user cap | Windmill Community Edition, with limits | Windmill Community Edition is free with unlimited executions but caps workspaces at 3, users at 50 and groups at 4. n8n's free Community edition covers self-hosting, so check which features your team needs. |
| Teams that need Git-based environments and deployment promotion | Windmill (Enterprise) or n8n (Business or Enterprise) | Windmill lists full Git sync in Enterprise. n8n lists environments with Git in Business and Enterprise. Verify the exact workflow each vendor supports. |
| Teams that run large parallel data processing with worker pools | Windmill, to be confirmed in testing | Windmill workers pull jobs from a PostgreSQL queue and sizing starts at one worker per vCPU. n8n queue mode uses Redis and workers, but multi-main high availability is Enterprise only. |
How n8n queue mode and Windmill workers differ in operations
Both platforms split the control plane from the execution plane, but they do it differently and the difference shows up in day-two work. n8n queue mode adds Redis and a shared encryption key, while Windmill keeps its queue inside PostgreSQL and sizes workers by CPU. The cards below cover what each design asks your operations team to run, secure and size.
n8n main instance and Redis
In queue mode, the main instance takes triggers and webhooks and passes executions through Redis to workers. That means Redis becomes a component you must deploy, monitor, back up and secure alongside n8n. Ask your team who owns Redis availability and what happens to queued executions if it fails during an incident. Redis is a second stateful service you must operate.
Worker pool reading PostgreSQL
Workers run executions and read and write workflow data in PostgreSQL, so the database is shared by the main instance and every worker. Running queue mode on SQLite is not recommended, so plan for a production-grade PostgreSQL instance from the start. Check connection limits and backup scope before you add workers, since each one adds load on the same database.
Shared encryption key across processes
The main instance's encryption key must be shared with every worker and webhook processor so they can decrypt credentials stored in the database. Key rotation and secret distribution therefore touch every process in the topology, not just one. Confirm how your team stores that key, who can read it, and how a rotation is rolled out without breaking running workers.
Windmill API servers and Rust workers
Windmill's backend is written in Rust, with stateless API servers and workers that pull jobs from a PostgreSQL queue. Because the API tier holds no job state, you scale the two tiers independently and avoid a separate broker to operate. Confirm how your team will monitor queue depth and worker health in PostgreSQL, since that table becomes the operational signal.
Sandboxed jobs with nsjail
Windmill runs jobs in a sandbox built on nsjail, which limits what a script can reach on the worker host. Security teams should review this boundary against their own threat model for user-submitted scripts, especially when many developers can write code. Ask the vendor and your own testers to confirm the isolation behaves as expected in your container or Kubernetes setup.
Compose, Helm and external PostgreSQL
Windmill documents self-hosting with Docker Compose or Kubernetes Helm charts and supports external PostgreSQL services such as AWS RDS, GCP Cloud SQL and Azure. Choosing a managed database shifts backups and patching to your cloud team but keeps the queue in one place you already run. Decide early whether Compose suits a pilot or whether Helm and a managed database fit your production standard. The one-worker-per-vCPU rule of thumb in Windmill's README, with 1 to 2 GB of RAM per worker, is a starting point to validate with load tests rather than a capacity guarantee.
Feature by feature: licensing, languages, triggers, SSO and self-hosting
This table compares the two tools on the features that most often decide a shortlist, from license and editions to languages, SSO, audit, secrets, Git and high availability. Read each row with your own license counsel and edition requirements in mind, because several gaps close only on paid tiers. Where a fact was not supplied, the cell tells you what to confirm.
| Capability | n8n | Windmill |
|---|---|---|
| License | Sustainable Use License, which allows internal business, non-commercial or personal use only; files with .ee in their name need an n8n Enterprise License | AGPLv3 and Apache-2.0 when compiled without the enterprise feature flag; prebuilt Community Edition images include proprietary code free for internal use, and managed services or resale need a commercial license |
| Editions and entry paid tier | Free self-hosted Community edition; Business plan is self-hosted only and unlocks SSO, Git environments and log streaming; Enterprise is custom priced | Free self-hosted Community Edition with limits of 3 workspaces, 50 users and 4 groups; Enterprise starts at $120 per month, priced by developer and operator seats plus compute units |
| Languages for code | Custom JavaScript or Python code inside a visual canvas | Python, TypeScript, Go, Bash, SQL, GraphQL, PowerShell, Rust and more, composed into flows or low-code apps |
| Integration breadth | Advertises more than 1,500 integrations; pricing states all plans include every integration | Built around scripts and internal apps; confirm the count and type of prebuilt connectors you need against current documentation |
| Trigger types | Webhooks and schedules are central to the model; confirm the full trigger list for your workflows in current docs | Confirm which trigger types (schedule, webhook, event) your flows need in the current Windmill documentation |
| SAML and SCIM | SAML single sign-on on Business and Enterprise; SCIM not covered by the supplied facts, so confirm it | Enterprise adds SAML and SCIM |
| Audit logs and log streaming | Log streaming is included in Business and Enterprise; audit logs are not covered by the supplied facts, so confirm them | Enterprise adds audit logs |
| External secrets | Enterprise tier feature for external secret stores; confirm the supported backends before committing | Enterprise adds external secret backends such as Vault and AWS Secrets Manager |
| Git version control | Environments with Git are included in Business and Enterprise | Full Git sync is included in Enterprise |
| Multi-main high availability | Restricted to Enterprise self-hosted deployments; not available in Community or n8n Cloud | Autoscaling is an Enterprise feature; confirm the high availability design for your deployment model |
| Self-hosting deployment options | Self-hosted in regular mode or queue mode with Redis and PostgreSQL; queue mode on SQLite is not recommended | Docker Compose or Kubernetes Helm charts, with external PostgreSQL such as AWS RDS, GCP Cloud SQL or Azure |
What the Sustainable Use License and AGPLv3 each allow
n8n is licensed under the Sustainable Use License, which is a fair-code license and not an OSI open-source license. It allows you to use and modify the software for your own internal business purposes, and for non-commercial or personal use. Distribution is permitted only free of charge and only for non-commercial purposes, so the license does not cover offering n8n as a managed service or reselling it.
- Internal business use: Your company can run and modify self-hosted n8n for its own workflows without a commercial license, under the terms in the license file.
- Non-commercial and personal use: Individuals and non-commercial projects fall within the permitted purposes.
- Managed services and resale: Hosting n8n for third parties or selling access to it is outside the license terms and needs a separate agreement with n8n.
- Enterprise files (.ee): Files with .ee in their name or directory are not covered by the Sustainable Use License and require a valid n8n Enterprise License.
- Plan features: SSO and LDAP, environments with Git, and log streaming are listed on n8n's pricing page as Business and Enterprise features, and multi-main high availability is restricted to Enterprise self-hosted deployments.
Confirm with n8n's license file and pricing page which features your planned edition includes before you design around them.
Windmill's source code, when compiled without the enterprise feature flag, is available under AGPLv3 and Apache-2.0. The prebuilt Community Edition images are different: they include proprietary code that is free for internal use. Managed services or reselling require a commercial license, so the source license and the binary terms need to be read separately.
- AGPLv3 source: Compiling the source without the enterprise feature flag gives you code under AGPLv3 and Apache-2.0 terms, including the network-use obligations that AGPLv3 carries.
- Proprietary Community binary: The prebuilt Community Edition image is free for internal use but is not open source in its entirety.
- Managed services and reselling: Offering Windmill to others as a service or reselling it requires a commercial license from Windmill.
- Community limits: The free self-hosted Community Edition is limited to 3 workspaces, 50 users and 4 groups, as of October 2026.
- Enterprise pricing: The self-hosted Enterprise Edition starts at $120 per month, with developers priced at $20 per month each and operators at $10 per month each, plus compute units, according to Windmill's pricing page as of October 2026. Enterprise adds SAML and SCIM, audit logs, external secret backends, full Git sync, and autoscaling.
Confirm the current pricing and limits on Windmill's pricing page before you budget, because compute unit charges are not covered by the per-seat figures.
Both licenses restrict something that many teams assume is allowed, so the decision belongs with your legal counsel and not only with the engineering team. The questions are about how the software is run, who uses it, whether any part of it reaches customers, and which code or binary you actually deploy. Answers differ between an internal automation platform, an internal developer platform serving several business units, and a product that exposes workflows to outside customers.
- Deployment scope: Document whether the instance serves only your own employees and whether any subsidiary or contractor uses it.
- Customer exposure: Check whether workflows or apps are delivered to external customers, since that can fall under managed service or resale terms.
- Artifact choice: Record whether you run the prebuilt image, a source build, or a vendor-hosted service, because each carries different license terms.
- Enterprise file use: For n8n, confirm whether any .ee code will be deployed and whether you hold a valid Enterprise License for it.
- Written confirmation: Ask each vendor to confirm the applicable terms in writing for your planned use.
Have counsel review the license text and the vendor's written answers before you commit to a platform.
How SSO, SCIM and audit requirements change the free-tier choice
If your environment requires named sign-in through a corporate identity provider, the free tier decision changes quickly. n8n's SAML single sign-on sits in the Business and Enterprise plans, not the free Community edition, and n8n's pricing page places SSO and LDAP in those same paid tiers. n8n publishes step-by-step SAML guides for Okta Workforce Identity and Azure AD, so a team already standardized on one of those providers can scope the integration early. Windmill's free Community Edition is also limited to 50 users, so a larger population is pushed toward a paid tier either way.
Windmill's Enterprise Edition adds SAML and SCIM, audit logs, external secret backends and full Git sync, according to its pricing page. SCIM matters most when joiner, mover and leaver events must flow automatically from the identity provider, because a deprovisioning gap leaves former staff with active automation access. Audit logs matter when you must show who ran or changed a script or flow during an access review. For a regulated team, the condition that makes these gaps decisive is a control that requires periodic access reviews or traceable change history. If that control is in scope, the free tier is unlikely to satisfy it on either platform.
Before buying, confirm current plan contents on each vendor's pricing page, since editions and feature placement change. Ask n8n whether SAML, LDAP, log streaming and Git environments are all included in the plan you price, and ask Windmill whether SCIM and audit logs are included in the Enterprise tier at the user counts you need. Record the answers in writing alongside your access review requirements so the purchase can be checked against them later.
What drives the running cost of each platform
Running either tool costs more than its license line. The main drivers are the plan or edition you need for SSO and governance, the infrastructure and people who keep the platform up, and how often you must upgrade. Use the items below to build a quote request that compares like with like.
License tier and edition gating
n8n's free Community edition covers self-hosting, but SSO and LDAP, environments with Git, and log streaming sit in the Business and Enterprise plans, and multi-main high availability is Enterprise self-hosted only. Windmill's free Community Edition has limits on workspaces, users and groups, and SAML, SCIM, audit logs and full Git sync sit in its Enterprise Edition. Map each governance requirement to the tier that includes it before comparing headline prices.
Per-user and per-execution pricing
n8n counts one execution as one run of a whole workflow regardless of the number of steps, and its plans include unlimited users and workflows, so cost tracks run volume. Windmill's Enterprise pricing charges per developer and per operator, plus compute units, so cost tracks headcount and compute. Estimate both against your real run counts and the number of people who build and operate flows.
Database and Redis infrastructure
A queue-mode n8n deployment needs PostgreSQL for workflow data and Redis for passing executions to workers, and running queue mode on SQLite is not recommended. Windmill uses PostgreSQL as its job queue and supports external managed databases. Both add backup, high availability and patching work that recurs every month, so ask who will run those databases and what they cost on your cloud or data center.
Worker sizing and compute
Windmill's README gives a rule of thumb of one worker per vCPU with 1 to 2 GB of RAM, which gives a starting point for compute. n8n workers scale horizontally behind the queue, and the main instance must share its encryption key with every worker and webhook processor. Compute cost depends on execution volume, script runtime and how many workers stay warm, so test your heaviest workflows before sizing.
Skills for TypeScript and Rust-backed tooling
n8n is built with TypeScript and Node.js and extends with custom JavaScript or Python, so Node-experienced staff can operate and extend it. Windmill's backend is written in Rust and its scripts run in Python, TypeScript, Go, Bash, SQL and more, so your team needs skills in its runtime and sandboxing with nsjail. Staff time to learn and maintain each stack is often the largest recurring cost, so count it explicitly.
Upgrade effort across release lines
n8n's current stable line is 2.x, and 1.x still receives releases, so you must decide when to move and test your workflows across that change. Windmill ships releases frequently, and its latest release on its GitHub page as of October 2026 was v1.840.0, so the upgrade cadence is faster. Budget testing time for each upgrade and ask each vendor for its support window and migration guidance in writing.
Moving workflows between n8n and Windmill without rebuilding everything
This sequence moves each workflow from a visual n8n canvas to a Windmill script or flow in a controlled order, so you keep a working copy of every automation until the cutover is verified. Nothing transfers automatically, so the work is inventory, rebuild and verification.
Inventory workflows, credentials and schedules
The owning team lists every n8n workflow, its owner, its active status, its triggers (webhook, schedule, app event or manual), and every credential it uses. Record which workflows run in production, which are dormant and which exist only for testing. Export the workflow definitions from n8n and store them under version control so you have a rollback reference. Check with n8n which export formats your edition supports, and confirm how credentials can be exported, since credentials are stored encrypted with the instance encryption key and do not move with the workflow JSON. The step is done when you have a signed-off list with one row per workflow and a separate list of credentials that must be re-entered in the target system.
Classify each workflow as canvas flow or script
Review each inventoried workflow and decide where it belongs. Workflows that mainly connect SaaS applications through prebuilt nodes, and that business users need to edit, often stay as n8n canvas flows or move to a Windmill flow that calls scripts. Workflows with custom logic, data transformation, loops, database work or unit-testable functions are better candidates for Windmill scripts in a language your developers already use, such as Python or TypeScript. Assign each workflow an owner who will maintain it after the move. The check is complete when every workflow has a target type and a named maintainer, and the team agrees which workflows stay on n8n for now.
Map triggers and integrations to target equivalents
For each workflow, write down the triggers and each integration node, then identify the Windmill counterpart. A webhook trigger needs a Windmill endpoint or trigger definition, a schedule needs a Windmill schedule, and each app node may need a script that calls that application's API directly or a connector your team has verified. Where no equivalent exists, flag the workflow as a rebuild risk and decide whether to implement the call yourself. Confirm current trigger and integration coverage in Windmill's documentation and in your own environment rather than assuming parity. The output is a mapping sheet with one line per trigger and integration, marked as direct, custom or unresolved.
Rebuild in the target language and secrets model
Developers rebuild each workflow as a Windmill script or flow, using the language chosen in the classification step. Credentials are recreated in Windmill's secret or resource management, and values are supplied by the people who hold the original accounts, not copied from n8n. Where your organization uses an external secret backend, confirm with Windmill which backends the edition you have supports, since the pricing page lists external secret backends such as Vault and AWS Secrets Manager as an Enterprise feature. Add tests or sample inputs so the rebuilt logic can be checked. The step is done when each rebuilt workflow runs in a non-production workspace and its credentials are held only in the target system.
Run old and new in parallel and compare outputs
Keep the n8n workflow active while the Windmill version runs against the same inputs, or in a shadow mode that writes to a test destination. Compare outputs, side effects and error paths for a period the owner agrees on. Watch for differences in retries, rate limits, timezone handling and idempotency, because a rebuilt workflow can duplicate actions if both versions write to the same system at once. Record every mismatch and resolve it before cutover. The check is complete when the owner signs off that outputs match for the agreed cases and that duplicate side effects were prevented.
Cut over webhooks and schedules
Move traffic in a controlled order. Point the webhook sender to the Windmill endpoint or change the upstream system's callback URL, and disable the matching n8n trigger only after the new endpoint has received and processed test events. Enable the Windmill schedule and disable the n8n schedule in the same change window so that a job is not run twice or skipped. Keep the n8n workflow in an inactive state rather than deleting it. Record the time of each switch in your change log. The step is done when every production trigger has one active path and the change log shows which system answers each trigger.
Verify execution history and retire the old workflow
Execution history does not transfer between n8n and Windmill, so decide in advance which n8n execution records must be retained for audit or troubleshooting and export them before any retention limit or instance change removes them. Confirm the export options for execution logs with each vendor and with your own log platform. Once the new workflow has run cleanly and the retention requirement is met, archive the n8n workflow definition, remove its credentials from the n8n instance, and update the workflow inventory to show the new owner. The sequence is complete when the inventory marks each workflow as migrated, retired or deliberately retained on n8n, with the archive location recorded.
Where n8n and Windmill implementation projects usually run long
The work that extends an n8n project most is usually the self-hosted runtime rather than the workflows themselves. In queue mode, the main instance handles triggers and webhooks and passes executions through Redis to workers that read and write workflow data in PostgreSQL. The main instance's encryption key must also be shared with every worker and webhook processor so they can decrypt stored credentials. Teams should plan a written check of key distribution, secret rotation and Redis and database sizing before anything goes live, and confirm with n8n which high availability option their license permits, since multi-main is restricted to Enterprise self-hosted deployments. Credential migration is the second long item. Existing credentials and their owners often need to move between environments, and node governance, meaning which community and custom nodes are allowed, needs an approval path that someone owns.
Windmill projects run long for different reasons. Scripts in Python, TypeScript, Go, Bash, SQL and other languages are executed in jobs sandboxed with nsjail, so the review effort sits in the code itself, in what each script may reach, and in how workers are configured to run it. Teams should schedule script review and sandbox testing as named work items, not as a final check. External PostgreSQL is the third item. Windmill workers pull jobs from a PostgreSQL queue, so the choice between a bundled database and a managed service such as AWS RDS, GCP Cloud SQL or Azure changes backup, failover and connection planning. Sizing follows the README's rule of thumb of one worker per vCPU with 1 to 2 GB of RAM, which should be checked against real job volume.
Identity is the item both platforms share. SSO wiring, and for Windmill the SAML and SCIM provisioning that sits in its Enterprise Edition, depends on how groups map to roles, workspaces and n8n projects. Designing the access model (who builds, who runs, who approves and who administers) usually takes longer than the identity connection itself. Effort depends on the environment: the number of identity providers, the size of the credential estate, the network layout and the compliance evidence required. None of these durations are fixed, so ask for each work item to be written into the fixed scope with its own deliverable before work starts. Confirm current edition limits and feature availability with each vendor before you finalize that scope.
Questions buyers ask before choosing n8n or Windmill
Is n8n Community enough if we need single sign-on?
No, not if SSO is a hard requirement. According to n8n's pricing page, SSO and LDAP are included only in the Business and Enterprise plans, and n8n's SAML single sign-on is available on those same plans, with setup guides for Okta Workforce Identity and Azure AD. The free self-hosted Community edition covers the workflow engine itself, so the decision is a licensing one: budget for Business (self-hosted only) or Enterprise, or accept local accounts for the platform. Ask n8n to confirm the current plan list before you commit, since packaging changes between releases.
Can we use Windmill Community Edition commercially?
It depends on how you run it. Windmill's repository states that source compiled without the enterprise feature flag is under AGPLv3 and Apache-2.0, while prebuilt Community Edition images include proprietary code that is free for internal use. Managed services or reselling require a commercial license. Internal use inside your own organization fits the free tier, with limits of 3 workspaces, 50 users and 4 groups on the pricing page as of October 2026. Have counsel confirm how your deployment and any customer-facing use fit those terms.
What does the internal team need to run either platform?
Both platforms need a team that can operate a database, containers and upgrades, and the skill mix differs. n8n is built around a visual canvas, so business automation owners can build flows, but production use needs someone to run PostgreSQL, Redis in queue mode and the encryption key handling. Windmill assumes engineers who write scripts in Python, TypeScript, Go or SQL, and it runs on PostgreSQL with stateless API servers and workers. Ask who will own upgrades, backups and secret handling, and whether that person has time for them each month.
Can a developer team run Windmill without outside help?
Often yes, if the team already operates containers and PostgreSQL. Windmill documents self-hosting with Docker Compose or Kubernetes Helm charts and supports external PostgreSQL services such as AWS RDS, GCP Cloud SQL and Azure. Its README gives a rule of thumb of one worker per vCPU with 1 to 2 GB of RAM, which helps with sizing. Gaps usually appear around SAML and SCIM, audit logs and external secret backends, which the pricing page lists under Enterprise. A fixed-scope engagement can cover the setup, hardening and documentation if the internal team lacks capacity.
How long does a migration take and what drives it?
Duration depends on the number of workflows, their integrations, credential migration and the testing they need, so no general figure applies. Start by inventorying flows and classifying them: simple visual automations move differently from scripts with custom logic. Credentials, encryption keys and webhook URLs often take the most work. Ask for a written scope that lists the workflows in each wave, the test approach, cutover steps and rollback, since DeployOpen agrees scope, deliverables and timelines in writing before work starts.
How does the Sustainable Use License affect embedding n8n?
The Sustainable Use License permits use or modification only for your own internal business purposes or for non-commercial or personal use. Distribution is allowed only free of charge for non-commercial purposes. Embedding n8n inside a product you sell or offer to customers falls outside those terms, so it needs a commercial arrangement with n8n. Files with .ee in their name require a valid n8n Enterprise License. Windmill's AGPLv3 core is a different model, so compare the two license texts against your actual distribution plans with legal counsel.
What should we request in a quote for either platform?
Ask for a written scope that names the platform, edition or license tier, the number of workflows or apps, identity integration, database and secret stores, backup and upgrade responsibilities, and the testing and documentation deliverables. Separate one-time work such as migration and hardening from recurring items such as retainers, upgrades and continuous testing. List who pays for platform licenses, cloud infrastructure and any Enterprise plan, since those are paid to the vendor rather than to the implementation partner. DeployOpen does not publish a price list, so a quote follows from the written scope.
Official sources to check licenses and plan contents
Before you shortlist either tool, confirm the license and plan details against the primary sources, because both vendors change their terms and editions over time. For n8n, start with the n8n LICENSE.md file in the n8n-io/n8n repository and read what the Sustainable Use License permits for internal business use, and check which files carry .ee in their names, since those require an n8n Enterprise License. For Windmill, read the Windmill GitHub repository to see which code is AGPLv3 and Apache-2.0 when compiled without the enterprise feature flag, and which prebuilt Community Edition image components are proprietary.
Next, compare the plan contents against the vendor pricing pages. The n8n pricing page lists which features sit in the Business and Enterprise plans, including SSO and LDAP, Git environments and log streaming, and the Windmill pricing page lists the Community Edition workspace, user and group limits and the Enterprise features such as SAML, SCIM and external secret backends. Ask each vendor, in writing, which features apply to the self-hosted edition you plan to run, since pricing pages can differ from the license terms that govern your deployment.
If you plan to scale n8n beyond a single process, check the n8n queue mode documentation for the required components, the shared encryption key that workers need, and which high availability setup requires an Enterprise license. Finally, read the Windmill v1.840.0 release notes and the release history before you pin a version, and record the version you tested so your upgrade plan matches the release you actually validated.
How DeployOpen helps teams choose, implement or migrate between them
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the n8n or Windmill decision is tested against your environment before anything is built. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Map which workflows are business app automations and which are scripts, internal apps or scheduled jobs.
- Confirm your license position for internal use, embedding and any resale before choosing a platform.
- Define which SSO, Git environment, audit log and secrets features the written scope requires, and at which edition.
How we build
- Deploy the chosen platform with its database, queue or worker layout sized to your execution volume.
- Connect identity, secret stores and logging to your existing systems, with configuration kept in version control.
- Build or migrate a representative set of flows or scripts and test failure handling, retries and credential access.
How we hand over
- Document the architecture, deployment steps, encryption key handling and backup procedures for your operators.
- Deliver runbooks for upgrades, including how each platform's release line is tracked and tested before rollout.
- Walk your team through building and reviewing flows or scripts so ownership stays with your staff.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover platform upgrades, backup verification and security testing of exposed workflow endpoints.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
