Windmill vs Itential
Both sit above your devices, your source of truth and your playbooks, and both are honest orchestrators. Itential models that layer as a visual canvas with a network-domain product around it. Windmill models it as code. Eight questions teams ask during a bake-off, with an honest answer on each one.
- 01What you can buildWhich solution fits for your specific use case
- 02TargetWho the platform is built for
- 03Build experienceHow you build on each platform
- 04IntegrationsHow the platform integrates with your existing stack
- 05Migration & lock-inHow hard to get in, how hard to get out
- 06Enterprise requirementsAudit logs, observability, security, performance
- 07Licensing & pricingOpen source, pricing, self-hosting
- 08VerdictThe verdict
Windmill in one sentenceAn open-source workflow engine and developer platform to build and orchestrate all your internal software: scripts, workflows, data pipelines, AI agents and internal apps, with Ansible as one of its native script languages. Made for engineers who want full code flexibility and a local dev experience, both to build internal software and to run the network and the infrastructure under it.
Itential in one sentenceA platform for network and infrastructure orchestration, built around a drag-and-drop Studio canvas, Operations Manager for triggers and job history, Inventory Manager for devices, Work Center for human approvals, Configuration Manager for backups and golden-config compliance, and Itential Gateway as the Git-native engine that runs Ansible, Python and OpenTofu, with 300+ open-source adapters to the vendors a network team already owns.
Which internal software can you build and orchestrate?
Itential is deep in one domain. The canvas, the device inventory, the configuration backups and the golden-config compliance engine are network products, and nothing on this list is a thing you would have to build. Windmill is wide across one runtime: the same engine runs network scripts, playbooks, data pipelines, AI agents and the internal apps on top, with shared credentials, one permission model and one run history.
| Primitive | Windmill | Itential |
|---|---|---|
Drag-and-drop steps with branches, loops, parallelism and approval gates | ||
A script with its own typed inputs, schedule, webhook and HTTP endpoint | Gateway services | |
Run a playbook with inventories, Galaxy collections, vault files and typed inputs | ||
Python execution Run Python against the devices, with its dependencies resolved per unit | ||
The same first-class treatment for languages beyond Python and Ansible | ||
OpenTofu / Terraform plans Plan and apply infrastructure as code from the orchestrator | Via script | |
A device list with connection state, point-in-time config snapshots and diffs | ||
Golden-config compliance plans A modelled baseline, scheduled drift checks and per-device compliance reports | Licensed add-on | |
Cron jobs with retries, error handling and alerting | ||
Kafka, NATS, SQS, MQTT, AMQP, Postgres, WebSocket and email as native trigger types | Kafka adapter | |
The form comes from the declared inputs rather than a form built next to them | Form builder | |
A run pauses for an approver and then continues from where it stopped | ||
ETL, syncs and scheduled data jobs with parallel branches | ||
Agents that call tools, branch on outputs and run as workflows | ||
Drag-and-drop dashboards and admin tools with built-in components | ||
Custom dashboards and admin tools built in React or Svelte | ||
Run the engine and the editors without a contract |
Three caveats on the rows above. On Windmill, basic approval steps are in the open-source core, while approval forms and approver restrictions are Cloud and Enterprise features. On Itential, golden configurations and compliance plans live in Configuration Manager Enterprise, which the documentation describes as a separately licensed add-on, and Workflow Studio and the Workflow Engine start at the Scale tier of the published cloud pricing.
"Gateway services" in the code row means a packaged Python script, Ansible playbook or OpenTofu plan that Gateway pulls from your Git repository at runtime and registers as a named service a workflow can call. It is a real unit of execution, but the schedule, the trigger and the form live on the Operations Manager automation that wraps it rather than on the script itself.
Who is each platform built for?
Itential is built for network operations teams and meets them in their own vocabulary, with the canvas as the default authoring surface. Windmill is built for engineers who want the automation to be code they can review, and who are automating more than the network.
WindmillItentialPrimary audience
WindmillDeveloper-led platform and infrastructure teams, including the network engineers among them. Engineers own the platform end-to-end: code, Git, local dev, code review, CI/CD, AI coding tools. The network is one of the estates they drive, next to cloud, SaaS and internal services.
ItentialNetwork and infrastructure operations teams. The product vocabulary is theirs: devices, inventories, golden configurations, compliance plans, northbound integration with Cisco NSO, a certified ServiceNow app. Itential describes its pricing as scaling with automation adoption rather than with the size of the network, with users always unlimited.
Who writes the automation
WindmillPeople comfortable with code, and the AI tools they drive. Scripts are written in Python, TypeScript, Go, Bash, PowerShell, SQL or Ansible, and the script editor infers the inputs from the signature, so the form is a side effect of writing the script.
ItentialPeople who build on a canvas. Itential describes Workflow Studio as a drag-and-drop builder with versioning and testing and no scripting required, and the task reference is a library of around a hundred task types that covers control flow, REST calls and string and array manipulation. Python drops in through a runCode task or a Gateway service when the canvas is not the right shape for the logic.
Who runs it
WindmillItentialOperators, through Operations Manager and its triggers, with a JSON form attached to the manual or schedule trigger that collects the inputs. Work Center is the queue for the tasks that need a person mid-run. The ServiceNow app publishes governed automations into the ServiceNow catalog and generates the forms there, which is a strong answer for shops where the request already starts in ServiceNow.
How do you build on each platform?
This is the biggest difference between the two. Itential puts the logic on a canvas and brings in Python when the canvas runs out, which is a short path for an operations team and a long one for data handling. Windmill puts the logic in the code and brings in the canvas for the glue, so the unit a reviewer reads in a pull request is the same unit the engine runs.
WindmillThe function signature is the contract. The inventory argument is a typed resource, site and dry_run become a validated form, and import httpx is resolved and pinned in a per-script lockfile with no environment to prepare. The same script runs standalone, on a schedule, behind a webhook, or as a step in the flow on the second tab.
- audit_primary_ips.py
- flow.yaml
import httpx
def main(inventory: dict, site: str, dry_run: bool = True) -> dict:
"""Return the devices at a site that have no primary IP."""
r = httpx.get(
f"{inventory['url']}/api/devices/",
params={"site": site, "has_primary_ip": "false"},
headers={"Authorization": f"Bearer {inventory['token']}"},
)
r.raise_for_status()
offenders = [d["name"] for d in r.json()["results"]]
return {"site": site, "dry_run": dry_run, "devices": offenders}
summary: Flag devices with no primary IP
value:
modules:
- id: audit
value:
type: script
path: f/network/audit_primary_ips
input_transforms:
inventory:
type: static
value: $res:f/network/inventory
site:
type: javascript
expr: flow_input.site
- id: approve
summary: Approve the remediation
value:
type: script
path: f/network/request_approval
suspend:
required_events: 1
schema:
$schema: 'https://json-schema.org/draft/2020-12/schema'
type: object
properties:
site:
type: string
required: [site]
Python runs on a Gateway cluster, in one of two shapes. A Gateway service keeps the script in your own Git repository, reads its requirements.txt at runtime and receives arguments as command-line flags that argparse parses. A runCode task holds the script inline on the canvas instead, with its pip packages, its input mapping and a timeout between 1 and 1000 seconds configured on the task.
- Gateway service
- runCode task
# The script is a Gateway service, created with iagctl from a Git repo.
# Gateway passes each --set value to the script as --key=value, and
# validates them against the service's decorator if one is defined.
iagctl run service python-script audit-primary-ips \
--set site=lon-dc1 \
--set dry_run
// A runCode task runs Python inline on the canvas, on a Gateway cluster.
{
"clusterId": "gw-prod-eu",
"language": "python",
"packages": ["httpx>=0.27.0"],
"safety": { "timeout": 300 },
"data": {
"site": { "source": "job", "variable": "site" }
},
"code": "import sys, json, httpx\n..."
}
Shapes documented in iagctl run service python-script and the runCode task reference.
WindmillItentialAuthoring
WindmillA step is a script. Write a function, and its arguments become the typed inputs, the generated form and the API contract. Imports are detected, resolved and pinned in a per-script lockfile, so a new dependency is a new import line with no image to rebuild. Flows add branches, for and while loops, parallelism, approval steps and per-step retries around those steps.
ItentialA step is a task on the canvas. The task reference covers control flow (forEach, evaluation, childjob, delay), REST calls (restCall), JSON transformations, and a long tail of string and array operations such as toUpperCase, padStart and charCodeAt as task types of their own. The runCode task was added in Platform 6.4 specifically to collapse chains of transformation, query and merge tasks into one readable Python script.
Where the code lives
WindmillItentialSplit by type, which is a reasonable design. Scripts, playbooks and plans stay in your own Git repositories and Gateway fetches them at execution time, so they never sit on a server. Workflows and the assets around them live in Platform, with Projects connected to GitHub or GitLab for push and pull. Itential documents that a pull overwrites the local project and a push overwrites the remote branch, so the Git side is a sync rather than a merge.
Dependencies and runtime
WindmillPer-script, resolved automatically and pinned in a lockfile. Galaxy collections and pip packages for a playbook go in the playbook header; npm, PyPI, Go and Maven packages are plain imports. Nothing restarts and no container is built when a dependency changes.
ItentialPer-execution virtual environments on the Gateway runner. Gateway reads requirements.txt, pyproject.toml or requirements.yml from the repository, builds a clean environment with exactly those dependencies, caches it for the next run with the same set, and rebuilds it when the requirements change. For a runCode task the package list is a field on the task and installs come from the public PyPI index by default.
Local dev & IDE
WindmillRun and deploy from the Windmill CLI, with a VS Code extension, native language tooling and AI coding tools working on real source files. wmill script preview and wmill flow preview run a local file against the backend without deploying it.
ItentialTwo CLIs, iagctl for Gateway and ipctl for Platform, both with machine-readable JSON output for pipelines. iagctl run service python-script runs a service and prints its stdout, stderr, return code and timing. Workflows are edited on the canvas, with a Debug Mode that simulates execution and validates task behaviour.
Credentials and secrets
WindmillResources (typed JSON for device connections, inventories and configs) and variables (individual secrets) are reusable across scripts, flows and apps, encrypted at rest and scoped by folders and groups. External secret backends (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager) are Enterprise only.
ItentialFour options, all included: Platform database encryption with a key you manage, HashiCorp Vault, OpenBao and CyberArk CCP, referenced from adapters and integrations as $SECRET_<path> and resolved at runtime. Gateway has its own secret store, and a runCode script reads an alias as $GATEWAYSECRET_(name) whose value is never returned to Platform. The documented constraints are KV v2 only, no Vault namespaces, and a restart of the affected adapter or service after a rotation.
Git & CI
WindmillFull infrastructure as code: everything in the workspace is a file in Git, deployed with the CLI and Git sync, so internal tooling ships like application code with PRs, reviews and rollbacks. Git sync is free for up to 2 users; beyond that is Enterprise only.
ItentialA documented promotion pipeline, and a good one. Itential publishes a reference repository with pipeline templates: merging to main computes the next semantic version from Conventional Commits and tags a release candidate, which deploys to staging, and a manual v* tag promotes the same version to production. The documented limit is that the pipeline cannot resolve cross-bundle dependencies, so every asset a workflow references has to be in the same promotion.
How does the platform integrate with your existing stack?
Itential wins the catalog comparison outright. Around 300 maintained, Apache-2.0 adapters with documented calls and auth per vendor is a real asset, and a model-driven integration from an OpenAPI file covers most of the rest. Windmill trades the catalog for the language ecosystems: any npm, PyPI, Go or Maven package is an import away, and the network vendors a NetOps team touches most are on the Hub as scripts.
WindmillItentialConnecting out
WindmillAny package is an integration. npm, PyPI, Go and Maven libraries are plain imports, and 200+ resource types describe the connection shape for databases, SaaS and infrastructure. For the network specifically, the Windmill Hub publishes ready-made scripts for sources of truth and IPAM, switches and routers, firewall managers, load balancers and monitoring, among others. These are recent additions, not a decade of catalog.
ItentialThe adapter library is the deepest part of the product. Around 300 open-source adapters sit in a public GitLab group under Apache 2.0, each one a Node.js connector with its own documented calls, authentication methods, properties and health checks, covering sources of truth, IPAM, firewall managers, network controllers, monitoring and the usual cloud and ITSM systems. Lighter integrations are generated from an OpenAPI or Swagger file with no code at all. The library is also actively curated, with a published deprecation and archive policy.
Receiving events
WindmillNative triggers for HTTP routes and webhooks, cron, Kafka, NATS, SQS, MQTT, AMQP, Postgres, WebSocket, email, and Google Cloud and Azure queues. Each is a typed primitive configured in the UI, attached to a script or flow, with server-side filters and per-trigger error handlers that override the workspace handler.
ItentialOperations Manager has four trigger types: manual, API endpoint (POST only, with a JSON schema validating the body), schedule, and event, which fires on Itential's internal event system. Message buses reach that event system through an adapter: the Kafka adapter subscribes to topics and partitions with per-topic filters and publishes an event an event trigger then matches. It works, and the configuration lives in the adapter properties rather than in a trigger of its own.
Extending
WindmillA new integration is a script with a new import: save and run, with no image rebuild and no restart. Custom shapes can be published as a typed resource type or shared on the workspace Hub for the team.
ItentialTwo documented routes. Adapter Builder generates a custom adapter from an API specification, which you then install and configure like any other. Or skip the adapter and point a model-driven integration at the OpenAPI file. Contributing back to the open-source library is also documented, which is more than most vendors offer.
Connecting AI tools
WindmillWindmill works in both MCP directions. Windmill MCP lets an external client such as Claude or Cursor trigger your scripts and flows and reach the API for jobs, resources, variables, schedules and workers. In the other direction, an AI session can call the tools of external MCP servers connected in its assistant settings.
ItentialAlso both directions, as two separate components. FlowMCP Gateway registers an external MCP server over stdio, streamable HTTP or SSE, discovers its tools and surfaces them in Gateway Manager as native gateway services. The Itential MCP Server is a separate open-source Python package that exposes Platform outward to an AI assistant, with over 56 tools across workflow execution, device management and platform health.
How hard to get in, and how hard to get out?
Neither platform holds your scripts hostage, and Itential is better than most here, because the automation content stays in your own repositories by design and the adapters are open source. Windmill extends that to the layer above: the forms come from the code, and the flows, permissions and schedules are files in Git rather than records in a control plane.
WindmillItentialGetting in
WindmillPlaybooks keep their body and gain a header that declares inputs, inventories, files and Galaxy dependencies. Python scripts run as-is once the arguments become a typed signature. Inventories and device credentials become resources and secrets, surveys become the generated form, and the job wrapper is the script itself. Teams usually start with the workflows that already need a step outside the network.
ItentialShort, if the estate is one Itential already models. The adapter or integration exists for most vendors, device discovery and configuration backup are product features rather than scripts you write, and the canvas is quick for someone who thinks in boxes and arrows. The up-front work is the deployment itself: Platform, MongoDB, Redis and one or more Gateway clusters, placed in the network segments they need to reach.
Getting out
WindmillScripts are standard Python, TypeScript, Go, Bash, PowerShell, SQL or Ansible, runnable outside Windmill once the wrapper is dropped. The CLI exports the whole workspace as plain files, so what you lose on the way out is the runtime, not the automation.
ItentialMixed, and the split is clean. Scripts, playbooks and plans never left your Git repositories, so they walk out unchanged, and the adapters are Apache 2.0 Node.js packages you can read and keep. The platform-specific parts are the workflow definitions, the JSON forms, the JSTs, the golden configurations and the compliance plans. Those are exportable JSON, which makes them readable, but there is no equivalent engine to run them on.
Running both at once
WindmillEvery script and flow has a webhook and an HTTP endpoint, so an Itential workflow can call Windmill for the step it cannot express, and a Windmill flow can call Itential's REST API while a migration is in progress.
ItentialItential Platform exposes a documented REST API with an OpenAPI specification, and Operations Manager API triggers start an automation from a POST with a token. Running the two side by side is straightforward in both directions.
Audit logs, observability, security, performance
Both cover the enterprise basics, and they draw the line in different places. Itential includes SSO, RBAC and its audit log in the subscription, and Gateway clusters are a strong answer for segmented estates, but the audit log does not cover who ran what and engine throughput is a priced dimension. Windmill ships RBAC, capped SSO, encrypted secrets and full run history in the open-source core, gates uncapped SSO, external secret backends, unlimited workspaces and dedicated workers behind Enterprise, and puts no throughput cap in the licence.
WindmillItentialObservability
WindmillReal-time streaming logs, per-run inputs, outputs and duration, worker queue metrics and a Prometheus exporter, with a trace ID on every job. A flow run page shows the per-step status and result, and a failed step can be restarted from where it failed.
ItentialOperations Manager keeps job history and metrics, Job Viewer tracks an individual job in the cloud, and Insights adds activity dashboards and SLA metrics from the Scale tier. On the infrastructure side Itential documents Prometheus metrics for Platform, Gateway, MongoDB and Redis, OpenTelemetry web server metrics, SNMP MIB notifications, and centralizing logs with Loki and Alloy.
Audit logs
WindmillA full trail of who ran, edited and deployed what, including job executions. Audit logs are included on Cloud and Enterprise only on self-hosted, where Enterprise retention is unlimited.
ItentialA JSON audit log, one object per line, added in Platform 6.6. It records create, update and delete on workflows, accounts, groups, roles, SSO configs, OAuth clients and integration models, with the user, the timestamp and the resource name. Itential documents what it leaves out: full resource bodies, which fields changed, and workflow execution, since running a workflow or completing a manual task is an operator action tracked in Operations Manager rather than in the audit log.
Authentication
WindmillSSO for up to 10 users in the open-source core; uncapped SSO, SAML and SCIM are Enterprise only. Scripts and flows also authenticate machine callers through tokens scoped to a path.
ItentialSAML SSO with Okta, Azure Entra ID, AD FS and PingID, plus LDAP, RADIUS and a local AAA store, with no user cap and no separate tier to buy. Two constraints are documented: only one authentication method can be active at a time, and end-user SSO is SAML, with OAuth2 and OpenID Connect appearing for API service accounts and for integration authentication rather than for signing people in.
Isolation & segmentation
WindmillMultiple isolated workspaces on one instance, each with its own users, resources, secrets and access controls, and worker groups placed inside the network segment that owns the devices. Self-hosted Community Edition is capped at 3 workspaces; unlimited is Enterprise only.
ItentialGateway clusters are the segmentation unit, and this is one of the platform's strongest pieces. A cluster runs close to the infrastructure it touches, in a specific segment, region or behind a firewall, with RBAC and group-based access control enforced through Gateway Manager's service groups and secrets decrypted only at execution time. Virtual clusters group independent clusters under one name for failover and load distribution. Outbound integration traffic can be routed through a runner node so it leaves from the right place.
Execution limits
WindmillA default job timeout is set per instance and a custom timeout per flow step, with retries, early stop, concurrency limits and a configurable flow lifetime alongside it. Roughly 20 ms of overhead between flow steps, and dedicated-worker mode Enterprise only keeps runtimes and dependencies warm.
ItentialThe runCode task takes a timeout between 1 and 1000 seconds, defaulting to 1, and caps inline code at 2 MB; longer work belongs in a Gateway service. Retry on a fatal error is an explicit design choice: the ErrorHandling task is a manual task assigned to a group, so a person is prompted to retry or abort and the retry edge points back to an earlier task. Workflow Engine throughput is a licensed dimension, published as 10 tasks per second started at the Scale tier and 50 at Enterprise.
Open source, pricing, and self-hosting?
Windmill leaves the engine free to self-host and publishes its Enterprise pricing. Itential is bought rather than downloaded, and in exchange publishes something most vendors do not: a tier table that says what each tier includes, a pricing model with no per-device or per-seat multiplier, and end-of-support dates you can plan an upgrade around.
WindmillItentialOpen source
WindmillAGPLv3 core, free and unlimited to self-host, with the engine, the 20+ languages, triggers, RBAC and the flow and app editors in it. Enterprise features (uncapped SSO, dedicated workers, external secret backends, unlimited workspaces) ship in a separate proprietary codebase. Managed cloud available.
ItentialThe platform is a commercial product. What is open source is the periphery, and it is a substantial periphery: the adapter library under Apache 2.0, the Itential MCP Server under GPLv3, and the deployer and CLI tooling on GitHub. There is no free tier of the engine itself.
Pricing
WindmillPublic Enterprise pricing on the pricing page, based on seats and compute units, and the open-source core costs nothing to run.
ItentialThe structure is public, the numbers are quoted. The pricing page lists five cloud tiers (Essentials, Compliance, Scale, Enterprise, Custom) and states what moves between them: monthly agent runs, Workflow Engine throughput, Configuration Manager at Compliance, Workflow Studio and the Workflow Engine at Scale, Lifecycle Manager and high availability at Enterprise. There is no per-device, per-node or per-seat charge and users are always unlimited, which is a genuinely friendly model for a large estate. On-premises deployments licence FlowAI per production server. Figures come from sales, except on AWS Marketplace, where the Itential Platform Core Bundle is listed at 200,000 US dollars for 12 months.
Self-hosting and support
WindmillDocker Compose or a Helm chart, with Postgres as the only dependency. A proof of concept needs no contract, because the engine and the editors are in the free core. Windmill is SOC 2 Type II certified.
ItentialOn-premises on RHEL or Rocky 8 or 9, as bare metal, VMs, containers or Kubernetes, with MongoDB and Redis (or Valkey) required and Gateway installed on its own hosts. Itential publishes a version lifecycle with dates: Platform 6 is an Extended Support release from 27 February 2025, with end of maintenance on 27 August 2027 and end of support on 27 February 2028. Support is 8x5 on the lower tiers and 24x7x365 for P1 from Scale upward, and the platform is SOC 2 Type II.
The verdict
These are two honest answers to the same question, separated by where the logic lives. Itential puts it on a canvas: a hundred task types, a form builder, a device inventory, a golden configuration, with Python available through a runCode task or a Gateway service when the canvas runs out. Windmill puts it in the code: a function whose signature is the form and the API, with a canvas around those functions for branches, loops, approvals and retries.
Itential can be the right call if your automation is the network and will stay the network, you want config backup and golden-config compliance as products rather than as projects, the breadth of the adapter library maps onto your vendor list, your operators build on a canvas rather than in an editor, or a published tier table with no per-device multiplier is how your organization wants to buy. The Gateway model is also genuinely good: content stays in your Git repositories, execution happens in the segment that owns the devices, and the adapters are open source.
Windmill is the better fit when the network is one estate among several. The same platform runs the source-of-truth audit, the Ansible playbook, the Python that talks to the devices, the approval, the ServiceNow ticket, the database write, the dashboard the NOC watches and the AI agent that drafts the change. One set of credentials, one permission model, one run history, and one place to answer who changed a device and who approved it.
One thing is changing the weighting. As AI coding tools write more of the automation, the bottleneck moves from writing it to reviewing it. Automation that is files in a repository can be read in a pull request, diffed, tested and rolled back by commit. Automation that is task state on a canvas cannot, however good the canvas is. That is an argument for keeping the orchestration layer in code, and it is independent of which vendor you pick.
If you are deciding between the two, the fastest way to judge is to spend an afternoon in each: take one change you already run against your devices, wire it up on both sides, and see what the work around it looks like.
Frequently asked questions
Build your internal platform on Windmill
Scripts, flows, apps, and infrastructure in one place.