Is Windmill a drop-in replacement for Workato?

No. Both run event-driven automations against SaaS APIs and databases, so the mental model of trigger plus steps transfers. But Workato recipes are built out of connector actions and datapill mappings inside Workato, while Windmill steps are scripts you write in Python, TypeScript, Go, Bash or SQL. Porting means rewriting each recipe as a script or flow, calling the vendor SDK or REST API directly instead of a connector action. Where Workato has an official connector for a system you use and you have no appetite for code, Workato gets you there faster.

Can I migrate Workato recipes to Windmill automatically?

No, there is no converter. Workato recipe lifecycle management exports packages containing recipes and their dependencies, which is enough to read what a recipe does, but the export is a Workato artifact rather than portable source. Workato's own source-control guide says it is not recommended to change recipe files while they reside outside of Workato, and that changes made that way will not show in the version history visible in Workato. In practice the migration is a manual rewrite, one recipe at a time.

Does Windmill have a connector catalog comparable to Workato's?

No. Workato documents over 1,000 connectors across pre-built, universal and community categories, and its pricing page advertises 1,200+ pre-built connectors included for every user. Windmill has 50+ pre-built resource types for credentials and connection info plus a community Hub of reusable scripts and flows, which is smaller. The trade-off is that in Windmill any npm, PyPI, Go or Maven package is a first-class import, so the effective integration surface is the package ecosystems themselves, and a missing integration is a new import rather than a feature request.

Can non-technical users build automations on Windmill?

Only partially. Windmill has a visual flow editor, auto-generated input forms and run-only workspace roles, so non-developers can run, monitor and approve. Authoring a step still means writing code. Workato's recipe editor, datapill mapping and AIRO assistant are built for people who are not going to write Ruby or Python, and that is a real advantage when the people who own the process are not engineers.

Can I self-host Workato?

No. Workato runs as a vendor-hosted service and publishes no open-source edition or self-hosted deployment of the platform. The on-prem agent runs on your own server to reach databases and applications inside your network, but it works by establishing a TLS WebSocket tunnel out to Workato: per Workato's docs, the agent only makes outbound connections to Workato. Windmill's core is AGPLv3 and free to self-host without limits, which also means you can run it fully air-gapped.

How does pricing compare?

Windmill publishes per-seat and per-worker Enterprise pricing on its pricing page, with no metering of executions. Workato lists four plans (Standard, Business MCP, Enterprise MCP and Workato ONE) without printing prices, and directs buyers to get a quote. Workato usage is metered per capability: Tasks for each action step executed in a recipe job, API Calls, API Proxy Calls, Rows for data pipelines, Genie actions, Pages, Events and Seats for Workato GO and Workflow apps.

Can Windmill run AI agents the way Workato Agent Studio does?

Both offer agents, built differently. Workato Agent Studio is a no-code way to build agents it calls genies, each combining an AI model and job description, a chat interface in Slack, Teams or Workato GO, a knowledge base and skills built from Workato recipes. Its pricing page lists Agent Studio under the Workato ONE plan. Windmill AI agents are flow steps: tools are your own scripts, so an agent can call anything you can write, and sandboxes with persistent volumes let an agent run generated code in isolation.

Windmill

Windmill cloud

OSS

Windmill vs Workato

Eight questions teams ask during a bake-off, with an honest answer on each one for where Windmill or Workato is the better pick.

Try Windmill cloud Self-host in 3 mins

The 8 questions

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 sentence

An open-source workflow engine and developer platform to build and orchestrate all your internal software: scripts, workflows, data pipelines, AI agents and internal apps. Made for engineers who want full code flexibility and local dev experience, both to build internal software and to manage the underlying infrastructure.

Workato in one sentence

An enterprise integration and automation platform, today positioned as "The Platform to Govern & Scale Enterprise AI" across a control plane, an agentic layer and an execution plane. Automations are recipes assembled in a browser editor over a catalog of more than a thousand connectors. Vendor-hosted, quoted by sales and metered per capability.

01 · What you can build

Which internal software can you build and orchestrate?

Windmill is built to centralize and orchestrate all your internal software in one place. Scripts, workflows, data pipelines, full-code apps, AI agents and operator UIs run on a single runtime, with shared resources, auth and observability, and the whole thing self-hosts. Workato covers a comparable surface (integration recipes, an API platform, data pipelines, no-code workflow apps and an agent studio), but the pieces are distributed across plan tiers and the platform only runs as a hosted service.

Primitive	Windmill	Workato
Workflows Chain steps with branching, retries, loops and approval steps
Scheduled tasks Cron jobs with retries, error handling and alerting
Scripts Standalone functions exposed as APIs, webhooks or cron jobs without a wrapping workflow
HTTP endpoints for your logic Publish your own logic as a callable, authenticated HTTP API		Higher plans only
Data pipelines ETL, syncs and scheduled data jobs with parallel branches		Higher plans only
AI agent workflows Agents that call tools, branch on outputs and run as workflows		Higher plans only
AI sandboxes & volumes Isolated environments with persistent volumes for running agents
Low-code internal apps Drag-and-drop forms, dashboards and admin tools with built-in components		Higher plans only
Full-code internal apps Custom dashboards and admin tools built in React or Svelte
Self-hosted on your own infrastructure Run the whole platform inside your own network or VPC

Workato's rows marked "higher plans only" follow its pricing page and its docs: the API platform and workflow apps are described as available on specific plans, data pipelines are listed from Enterprise MCP, and Agent Studio is listed under Workato ONE. Windmill's own paid gates are flagged section by section below.

02 · Target

Who is each platform built for?

Windmill is built for developer-led teams where engineers own both the automations and the infrastructure they run on. Workato is built for enterprise integration teams and the business owners of a process, with a browser-based recipe editor and a vendor-operated runtime.

Windmill

Workato

Primary audience

Windmill

Developer-led teams. Engineers own the platform end-to-end: code, Git, local dev, workspace forks, code review, CI/CD, AI coding tools, infrastructure as code.

Workato

Integration and automation teams in large organizations, including the people who own a process but are not going to write code. Recipes are assembled in the recipe editor by picking a trigger, adding connector actions and mapping fields, and the AIRO assistant can configure a recipe's steps, connections and field mappings.

Reviewing and editing automations

Windmill

Non-developers consume through auto-generated UIs, custom apps and run-only workspace roles. Reading or editing the step logic itself still requires comfort with code.

Workato

Anyone with access can open a recipe and read the step list and field mappings, which makes handover across a business team easier than reading a repository. Workato's three system roles are Admin, Analyst and Operator, with Operator read-only; finer custom collaborator roles are included in specific pricing plans.

Who operates the runtime

Windmill

You do, if you want to. The same team that writes the scripts can run the instance on Kubernetes or Docker inside its own VPC, size the worker pools and keep every job's data on its own infrastructure. Managed cloud is there for teams that would rather not.

Workato

Workato does. Capacity shows up as plan-level quantities (concurrency and on-prem agents per edition) rather than machines you size, and reaching systems inside your network is the job of the on-prem agent, which opens an outbound tunnel to Workato.

03 · Build experience

How do you build on each platform?

Windmill gives you full code flexibility with a local dev loop and whole-workspace Git sync. Scripts, flows, apps, resources, permissions and infrastructure all live in Git like application code. Workato puts the recipe in a browser editor with datapill mapping, and keeps code at the edges: bounded Python and JavaScript actions, and Ruby custom connectors with their own CLI.

Windmill

The script is a normal Python file with a typed main. Windmill reads the signature to generate the input form, the JSON schema and the webhook payload type, and resolves httpx into a per-script lockfile. The flow YAML only wires steps together: it passes the previous step's return value straight into the next one.

overdue_invoices.py
flow.yaml

import httpx
from typing import TypedDict

class billing_api(TypedDict):
    base_url: str
    api_key: str

def main(since: str, billing: billing_api) -> list[dict]:
    r = httpx.get(
        f"{billing['base_url']}/invoices",
        params={"since": since},
        headers={"Authorization": f"Bearer {billing['api_key']}"},
    )
    r.raise_for_status()
    return [i for i in r.json()["items"] if i["status"] == "overdue"]

summary: Chase overdue invoices
value:
  modules:
    - id: a
      value:
        type: script
        path: f/billing/overdue_invoices
        input_transforms:
          since:
            type: javascript
            expr: flow_input.since
          billing:
            type: static
            value: $res:f/billing/prod
    - id: b
      value:
        type: forloopflow
        iterator:
          type: javascript
          expr: results.a
        modules:
          - id: c
            value:
              type: script
              path: f/billing/send_reminder

Workato

Code lives in two places. A custom connector is, in Workato's words, "a big hash that contains the root keys", written in Ruby with lambda do blocks for authentication, input fields, output fields and execute. Inline logic goes in a Python or JavaScript action whose body is a main function over a dict, with its input and output fields declared separately in the recipe editor. The recipe itself is not a file: it is assembled in the browser.

connector.rb
Python action

{
  title: 'Billing API',

  connection: {
    fields: [
      {
        name: 'api_key',
        label: 'API key',
        control_type: 'password',
        optional: false
      }
    ],

    authorization: {
      type: 'api_key',

      apply: lambda do |connection|
        headers(api_key: connection['api_key'])
      end
    },

    base_uri: lambda do |connection|
      'https://api.example.com'
    end
  },

  test: lambda do |connection|
    get('/v1/ping')
  end,

  actions: {
    list_invoices: {
      title: 'List invoices',

      input_fields: lambda do |object_definitions|
        [{ name: 'since', label: 'Since', optional: false }]
      end,

      execute: lambda do |connection, input|
        { items: get('/v1/invoices', input)['items'] }
      end,

      output_fields: lambda do |object_definitions|
        [{ name: 'items', type: 'array', of: 'object' }]
      end
    }
  }
}

def main(input):
    overdue = [
        i for i in input["items"]
        if i["status"] == "overdue"
    ]
    return {"overdue": overdue, "count": len(overdue)}

Shapes follow the SDK reference, API-key auth guide and Python connector docs.

Windmill

Workato

Authoring

Windmill

Write scripts in 20+ languages in a dedicated script editor. Windmill parses the function signature to auto-generate the input UI, JSON schema and argument types. Dependencies resolve automatically with a per-script lockfile, and relative imports work across Python and TypeScript scripts in the same workspace. Arguments pass between flow steps as direct return values, with no templating layer. Any public or private package is a first-class import.

Workato

A recipe is "an automated workflow that executes a series of steps to integrate and process data across multiple applications". Every recipe starts from a trigger, then runs connector actions whose inputs you fill by dragging datapills from the datatree of earlier steps, with formula mode for expressions. There is no standalone script primitive: code runs as an action inside a recipe.

Local dev & IDE

Windmill

Run scripts locally with the Windmill CLI. VS Code extension, native language tooling (LSP, type-checking, linting) and AI coding tools (Claude Code, Codex) work against real source files on disk.

Workato

Recipes are built in the browser. Custom connectors do have a local loop: the workato-connector-sdk gem gives you workato new, workato exec and workato push, with RSpec tests, against Ruby 2.7.x (3.0.x and 3.1.x also supported). In the web editor, connector code runs in CodeMirror that only allows a specific list of Ruby methods.

Language runtimes

Windmill

TypeScript (Deno, Bun, Node.js), Python, Go, Bash, SQL, PowerShell, PHP, Rust and more (20+ languages total). Any npm, PyPI, Go, Maven or Cargo package is a first-class import with automatic dependency resolution. Memory and timeouts are properties of the worker you run, not of a plan.

Workato

Three code surfaces, each bounded. The Python connector runs a main function over a dict, with a 90-second timeout, 256 MB of memory, a 1 MB code field and no user-provided libraries. The JavaScript connector runs on Node.js 20.11.0 with node-fetch, lodash, gRPC and Protobuf bundled, a 30-second timeout, 256 MB and again no user-provided libraries. Anything larger belongs in a Ruby custom connector.

Data handling

Windmill

First-class data tables with SQL queries, versioning and a browse / edit UI, plus native S3 integration for large payloads, files and persistent storage across scripts, flows and apps. Step payloads are not capped by the platform.

Workato

Built-in data tables and lookup tables cover reference data, and connectors stream files to object storage. Job payloads are bounded: Workato documents a 1 MB limit on job input and output data across all steps (beyond which job details are truncated), a 50 MB trigger event payload and 1,000 steps per recipe.

Resources & secrets

Windmill

Resources (typed JSON for credentials, connection info, configs) and Variables (individual secrets) are first-class and reusable across scripts, flows and apps. They are encrypted at rest, scoped via folders and groups for access control, and versioned in Git. External secret backends (Vault, AWS Secrets Manager, Azure Key Vault) are Enterprise only.

Workato

Connections authorize a recipe against an app and are reused across recipes, with OAuth handled by the connector. External secrets managers (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager) are wired up through the on-prem agent, so using them means running that agent.

Git & CI

Windmill

Full IaC: scripts, flows, apps, resources, variables, secrets, schedules, folders, groups and permissions are all files in Git, deployed via the CLI and Git sync. Internal tooling runs like application code: PRs, reviews, rollbacks, CI/CD. Git sync is free for up to 2 users; beyond that is Enterprise only.

Workato

Recipe lifecycle management exports and imports packages containing recipes and their dependencies, and both steps can be automated through its APIs. Git holds those packages rather than editable source: Workato's own guide says it "isn't recommended that you make changes to the recipe files while they reside outside of Workato", and that "changes made in this way will not show in the version history visible in Workato". Custom connectors are the exception, with real files and workato push.

04 · Integrations

How does the platform integrate with your existing stack?

Workato wins the catalog comparison outright: more than a thousand maintained connectors, including deep coverage of enterprise systems where an API binding is weeks of work. Windmill trades the catalog for direct access to package ecosystems, so a missing integration is an import rather than a request, and the connection logic stays readable code you own.

Windmill

Workato

Connecting out

Windmill

Any npm, PyPI, Go or Maven package is a first-class import with automatic per-script dependency resolution and lockfiles, and no plugin layer in between: you call the vendor's real SDK with full type inference and auto-completion in the editor. 50+ pre-built resource types cover common databases (Postgres, Snowflake, BigQuery), SaaS (Slack, Stripe, GitHub, Notion, OpenAI) and infrastructure (S3, Redis, Kafka): paste an API key into a typed form and the resource is shared across scripts, flows and apps, encrypted at rest. A community Hub has reusable scripts and flows for common tasks.

Workato

This is Workato's strongest axis. Its docs describe over 1,000 connectors in three categories (pre-built, universal and community), and its pricing page advertises 1,200+ pre-built connectors included for every user. A pre-built connector ships typed triggers and actions, permission requirements and troubleshooting guides for the target app, so connecting Workday, NetSuite, Salesforce or ServiceNow is configuration rather than code.

Receiving events

Windmill

Native triggers for HTTP, cron, Kafka, NATS, Postgres CDC, SQS, MQTT, SMTP and WebSocket. Each trigger is a typed primitive in the UI: configure topic, subject or path, attach it to a script or flow, and Windmill handles the connection, replay and consumer-group state. Every script also gets an HTTP endpoint and a webhook URL for free, so most receive paths need zero glue code.

Workato

Every recipe starts from a trigger, and connectors supply app-specific ones: new or updated records, webhooks, schedules, and polling triggers. Polling cadence is a plan property, with a 10-minute default on Community and Base plans and 5 minutes on Professional and above. Exposing your own HTTP endpoint goes through the API platform, where a call to the endpoint URL starts a recipe with a New API Request trigger; that platform is available to customers on specific pricing plans.

Extending

Windmill

A new integration is a script with a new import: save and run, no restart, no image rebuild. The loop is hot-reload all the way through, in the web editor, the CLI and Git sync. Custom logic can be exposed as a typed script, packaged as a resource type for shared use, or published to the private workspace Hub for the team.

Workato

Three routes. Universal connectors cover an API with no pre-built connector over HTTP, OpenAPI, GraphQL or SOAP. The connector SDK builds a first-class connector: a Ruby hash with root keys for connection, actions, triggers, object_definitions, pick_lists, methods and streams, which is a real engineering surface with its own CLI and tests. For one-off logic, the Python and JavaScript actions stay inside the recipe.

05 · Migration & lock-in

How hard to get in, and how hard to get out?

Workato is the faster on-ramp when your systems are in its catalog, because the integration work is configuration. Windmill keeps switching cost low at the other end: step code is standard code that runs anywhere, the workspace exports as plain files, and the engine itself is open source and yours to keep running.

Windmill

Workato

Getting in

Windmill

Paste a function body into the script editor, Windmill infers args, generates a UI and handles dependencies. Scripts you already have in Python or TypeScript usually run with no change beyond a main. Triggers, schedules, variables and apps migrate one by one.

Workato

Fast for the systems it already covers. Pick a pre-built connector, authorize a connection, map fields in the editor, and an integration a developer would have spent a week on is running. Community accelerator recipes give you a starting point for common patterns.

Getting out

Windmill

Step logic is already standard code (TypeScript, Python, Go, Bash, SQL) that runs anywhere. The CLI exports the full workspace as plain files, and because the engine is AGPLv3 you can keep running it yourself indefinitely. What you lose leaving Windmill is the runtime, not the step code.

Workato

A move off Workato is a rebuild. A recipe's substance is its connector actions, datapill mappings and formula-mode expressions, none of which exist outside Workato. Recipe lifecycle management exports packages of recipes and dependencies, but Workato's own source-control guide treats those as artifacts, not editable source. Inline Python and JavaScript action bodies do port, and they are small by construction: 1 MB of code, 90 and 30 second timeouts, no third-party libraries.

Where your data sits

Windmill

Wherever you put it. Self-hosting the whole platform, including the Postgres database that holds job arguments and results, is the default open-source path, and air-gapped installs work.

Workato

In Workato's cloud, in the data center region you choose. The on-prem agent lets recipes reach private systems without opening inbound ports, since it "only makes outbound connections to Workato", but the platform and its job history remain vendor-hosted.

06 · Enterprise requirements

Audit logs, observability, security, performance

Both cover the enterprise basics: SSO, role-based access, audit logging and encryption at rest. Windmill makes capacity and retention properties of the infrastructure you run, so short, high-volume workloads (webhooks, alerts, small scripts) scale by adding workers. Workato makes them properties of the plan, which is simpler to buy and harder to tune.

Windmill

Workato

Observability

Windmill

Real-time streaming logs, per-run inputs / outputs / duration, built-in worker queue metrics and a Prometheus exporter. Trace ID on every job. Job run details are retained up to 30 days on the free self-hosted tier and without limit on Enterprise.

Workato

Per-recipe job history shows each trigger event's path through the steps, with job debug tracing and error notifications. Log retention is a plan property: Workato's pricing page lists 30 days on Standard and 90 days on Enterprise MCP. Insights dashboards are listed from Enterprise MCP.

Audit logs

Windmill

Full trail of who ran / edited / deployed what. Extended retention is Enterprise only.

Workato

The activity audit log covers logins, invitations and recipe edits, and is kept for one year. Workato states it is "included in specific pricing plans"; streaming it to your own destination keeps it longer.

Security

Windmill

SOC 2 Type II compliant. RBAC, SSO (up to 10 users), encrypted secrets at rest and sandboxed script execution in open source. Uncapped SSO, audit logs and advanced access controls (SCIM, SAML) are Enterprise only.

Workato

Enterprise single sign-on with MFA and role-based access, encryption at rest and in transit, are listed from the Standard plan, and job history data is described as double-encrypted with a tenant-specific key. Custom collaborator roles beyond Admin / Analyst / Operator, and the enhanced security features listed from Enterprise MCP, are plan-gated.

Multi-tenancy & isolation

Windmill

Multiple isolated workspaces on the same instance, each with their own users, resources, secrets and access controls, and separate instances if you want hard isolation. The free self-hosted tier is capped at 3 workspaces; unlimited is Enterprise only.

Workato

The pricing page advertises "unlimited workspaces and users". Projects and environments separate development from production, and recipe lifecycle management moves packages between workspaces. Isolation is logical, inside Workato's multi-tenant service.

Performance & capacity

Windmill

~10ms cold starts. Dedicated-worker mode Enterprise only keeps runtimes and dependencies pre-warmed. Throughput is a function of how many workers you run, and worker count is something you buy once rather than per execution.

Workato

Capacity arrives as plan-level quantities. Workato's pricing page lists 1 concurrency on Standard and Business MCP, 15 on Enterprise MCP and 30 on Workato ONE, and its docs note recipe concurrency "varies by contract and plan". Documented ceilings include a 90-minute standard job timeout, 1,000 steps per recipe and 1 MB of job input and output data across all steps, with higher quotas available on request from Enterprise plans up.

We publish reproducible execution benchmarks against Airflow, Prefect, Temporal, Kestra and Hatchet. Workato is not in that dataset: it only runs as a hosted service, so there is no equivalent-hardware comparison to make, and we would rather omit the chart than publish a number we cannot reproduce.

07 · Licensing & pricing

Open source, pricing, and self-hosting?

Windmill is AGPLv3, free and unlimited to self-host, and publishes flat per-seat and per-worker Enterprise pricing with no execution metering. Workato is a vendor-hosted service with published plan contents, unpublished prices and per-capability metering where each executed step counts.

Windmill

Workato

Open source & self-hosting

Windmill

AGPLv3 core, OSI-approved open source, free and unlimited to self-host, including air-gapped. Enterprise features (uncapped SSO, dedicated workers, audit log retention, external secret backends) ship in a separate proprietary codebase. Managed cloud available.

Workato

No open-source edition, and Workato's docs describe no self-hosted deployment of the platform. The on-prem agent runs in your network to reach private systems and "establishes a TLS WebSocket tunnel to connect out to Workato"; the number of agents you get is a plan quantity (3 on Business MCP, 10 on Enterprise MCP, 30 on Workato ONE).

Pricing transparency

Windmill

Public per-seat and per-worker pricing on the pricing page, with no metering of executions. You can size a deployment and estimate the bill without talking to anyone.

Workato

Four plans (Standard, Business MCP, Enterprise MCP, Workato ONE) with the feature breakdown published but no prices: the page offers "Get a quote" and notes that for the most accurate information you should consult your agreement or reach out to the team.

How usage is metered

Windmill

Seats and workers. Running a script a million times costs the same as running it once, so high-frequency automation does not change the invoice.

Workato

Per capability, documented in usage metrics: Tasks (one per action step executed in a recipe job, and skills invoked over MCP), API Calls, API Proxy Calls, Rows for data pipelines, Genie actions per prompt, Pages for document processing, Events for event streams, and Seats for Workato GO and workflow apps. Step count and run frequency therefore both show up in the bill.

08 · Verdict

The verdict

Windmill and Workato automate the same kinds of work with two different units of composition. A Workato recipe is a sequence of connector actions whose inputs you map from a datatree, assembled in a browser and executed by Workato. A Windmill flow is a graph of real scripts, where each script is also a standalone primitive with its own input UI, HTTP endpoint and scheduler, executed by workers you run.

Workato can be a good fit if your integration surface is mostly large SaaS and ERP systems its catalog already covers, the people who own those processes are not engineers, and a vendor-operated runtime with per-capability metering suits how you buy software. More than a thousand maintained connectors is real work you do not have to do, and no code-first platform matches it.

Windmill is the better pick when the automation is software. Steps are ordinary Python, TypeScript, Go, Bash or SQL with any package available, so there is no 90-second action timeout or 1 MB payload ceiling to design around, and no point where the logic outgrows the tool. The whole workspace (scripts, flows, apps, resources, permissions) lives in Git, which means code review, CI and rollbacks, and it means AI coding tools work against real source files instead of a hosted editor. The same runtime also carries data pipelines, AI agents with sandboxes, and both low-code and full-code internal apps, with shared auth, secrets and observability. It is open source and self-hostable, so your job data stays on your infrastructure, and Enterprise pricing is published instead of quoted.

That gap widens as AI agents write more of the automation. Generated code you can read, review, version and run on your own infrastructure behaves like the rest of your codebase: diffs, tests, rollbacks. Generated recipes inside a hosted editor do not, and Workato's own guidance is that recipe files should not be edited outside Workato.

The switching cost is also asymmetric: Windmill step logic is standard code that runs anywhere after you leave, while Workato recipes built on connector actions and datapill mappings have to be rebuilt on any other platform. If you're deciding between the two, the fastest way to judge is to spend an afternoon in each.

Frequently asked questions

: No. Both run event-driven automations against SaaS APIs and databases, so the mental model of trigger plus steps transfers. But Workato recipes are built out of connector actions and datapill mappings inside Workato, while Windmill steps are scripts you write in Python, TypeScript, Go, Bash or SQL. Porting means rewriting each recipe as a script or flow, calling the vendor SDK or REST API directly instead of a connector action. Where Workato has an official connector for a system you use and you have no appetite for code, Workato gets you there faster.
: No, there is no converter. Workato recipe lifecycle management exports packages containing recipes and their dependencies, which is enough to read what a recipe does, but the export is a Workato artifact rather than portable source. Workato's own source-control guide says it is not recommended to change recipe files while they reside outside of Workato, and that changes made that way will not show in the version history visible in Workato. In practice the migration is a manual rewrite, one recipe at a time.
: No. Workato documents over 1,000 connectors across pre-built, universal and community categories, and its pricing page advertises 1,200+ pre-built connectors included for every user. Windmill has 50+ pre-built resource types for credentials and connection info plus a community Hub of reusable scripts and flows, which is smaller. The trade-off is that in Windmill any npm, PyPI, Go or Maven package is a first-class import, so the effective integration surface is the package ecosystems themselves, and a missing integration is a new import rather than a feature request.
: Only partially. Windmill has a visual flow editor, auto-generated input forms and run-only workspace roles, so non-developers can run, monitor and approve. Authoring a step still means writing code. Workato's recipe editor, datapill mapping and AIRO assistant are built for people who are not going to write Ruby or Python, and that is a real advantage when the people who own the process are not engineers.
: No. Workato runs as a vendor-hosted service and publishes no open-source edition or self-hosted deployment of the platform. The on-prem agent runs on your own server to reach databases and applications inside your network, but it works by establishing a TLS WebSocket tunnel out to Workato: per Workato's docs, the agent only makes outbound connections to Workato. Windmill's core is AGPLv3 and free to self-host without limits, which also means you can run it fully air-gapped.
: Windmill publishes per-seat and per-worker Enterprise pricing on its pricing page, with no metering of executions. Workato lists four plans (Standard, Business MCP, Enterprise MCP and Workato ONE) without printing prices, and directs buyers to get a quote. Workato usage is metered per capability: Tasks for each action step executed in a recipe job, API Calls, API Proxy Calls, Rows for data pipelines, Genie actions, Pages, Events and Seats for Workato GO and Workflow apps.
: Both offer agents, built differently. Workato Agent Studio is a no-code way to build agents it calls genies, each combining an AI model and job description, a chat interface in Slack, Teams or Workato GO, a knowledge base and skills built from Workato recipes. Its pricing page lists Agent Studio under the Workato ONE plan. Windmill AI agents are flow steps: tools are your own scripts, so an agent can call anything you can write, and sandboxes with persistent volumes let an agent run generated code in isolation.

Build your internal platform on Windmill

Scripts, flows, apps, and infrastructure in one place.

Get started for free