Is Windmill a drop-in replacement for Camunda?

No. Camunda executes BPMN 2.0 and DMN 1.3 models, and Windmill has no BPMN engine. If your organization standardizes on BPMN diagrams as the artifact that business and IT agree on, or if you need DMN decision tables, Camunda is the right tool. Windmill covers the orchestration itself: long-running flows with branches, loops, retries, timers, suspend and approval steps, written as code instead of as a diagram.

Can I convert BPMN models to Windmill flows automatically?

No, there is no BPMN importer. A migration is a manual rewrite: each service task becomes a Windmill script referenced from a flow, each user task becomes a suspend or approval step with a form, and FEEL expressions become JavaScript input transforms. The business logic inside your job workers usually ports as-is, since it is already ordinary code in your own repository.

What happened to Camunda 7?

Camunda 7 Community Edition, whose components were open source under mainly Apache 2.0 and MIT licenses, reached end of life in October 2025 with a final release, v7.24, on 14 October 2025. Camunda 7 Enterprise support runs until April 2030, with extended support to April 2032. Camunda states that Camunda 8 "is not a direct drop-in replacement for Camunda 7", so teams on Camunda 7 Community face a migration either way.

Can non-developers author processes on Windmill?

Only partially. Windmill has a visual flow editor and auto-generates input forms, but authoring a step still means writing code. This is where Camunda genuinely wins: BPMN and DMN are standards a business analyst can read and edit in a modeler, decision tables are editable without code, and reviews happen on visual diagrams rather than on XML. If a non-technical audience has to own the process model, Camunda is built for that and Windmill is not.

Windmill

Windmill cloud

OSS

Windmill vs Camunda

Eight questions teams ask during a bake-off, with an honest answer on each one for where Windmill or Camunda 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.

Camunda in one sentence

A process orchestrator built on the BPMN and DMN standards. Camunda 8 pairs the Zeebe engine with a modeler, Operate, Tasklist, Optimize and a library of connectors, so business analysts and developers work on the same executable diagram. Built for long-running business processes that mix systems, decisions and human approvals.

01 · What you can build

Which internal software can you build and orchestrate?

Camunda is a process orchestrator in the BPMN and DMN standards, with a ready-made task inbox for the human steps and dedicated operations and analytics apps around the engine. Windmill is built to centralize and orchestrate all your internal software in one place: scripts, workflows, data pipelines, AI agents and both low-code and full-code apps run on a single runtime with shared resources, auth and observability.

Primitive	Windmill	Camunda
Workflows Chain steps with branching, retries, timers and approval steps
BPMN & DMN models Executable diagrams and decision tables in the OMG BPMN 2.0 and DMN 1.3 standards
Human task inbox A ready-made UI where assignees pick up and complete tasks routed by the engine	Partial
Scripts Standalone functions exposed as APIs, webhooks or cron jobs without a wrapping workflow
Data pipelines ETL, syncs and scheduled data jobs with parallel branches		Partial
AI agent workflows Agents that call tools, branch on outputs and run as part of a workflow
AI sandboxes & volumes Isolated environments with persistent volumes for running agents
Low-code internal apps Drag-and-drop dashboards and admin tools with built-in components
Full-code internal apps Custom dashboards and admin tools built in React or Svelte
Scheduled tasks Cron jobs with retries, error handling and alerting

One caveat that applies to every Camunda row above: running Camunda 8 Self-Managed in production requires a paid license, whatever the feature. See licensing below.

02 · Target

Who is each platform built for?

Camunda is built for organizations where the process model itself is the contract between business and IT, and where a non-developer has to be able to read and change it. Windmill is built for developer-led teams where engineers own the automation end-to-end and non-developers consume it through forms, apps and approval pages.

Windmill

Camunda

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.

Camunda

Mixed business and IT teams. The diagram is the shared artifact: a business analyst models the process in BPMN and the rules in DMN, where decisions are, in Camunda's words, "modeled and executed using a language both business analysts and developers can understand", and a developer implements the automated steps as job workers behind the task types in that diagram.

Reviewing and editing

Windmill

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

Camunda

This is Camunda's strongest card. Processes are reviewed as diagrams, not as source: its own CI/CD guide notes that "process reviews differ from code reviews, occurring on visual diagrams rather than XML". Decision tables are edited cell by cell in the modeler, with no code involved.

Operating a running process

Windmill

Runs, logs, inputs and outputs are in the job view, with per-folder permissions deciding who can run or edit what. Human steps use suspend and approval pages, Slack or Microsoft Teams, and any operator UI you need is built as an app.

Camunda

Operate for incidents and instance state, Tasklist as a ready-made inbox for user tasks, Optimize for process analytics. Tasklist is, in Camunda's description, an "out-of-the-box interface" for manual work, and you can replace it with your own application through the Orchestration Cluster API.

03 · Build experience

How do you build on each platform?

Windmill puts the whole workflow in one artifact you can read, diff and review as code, with a local dev loop and whole-workspace Git sync. Camunda splits it deliberately: a diagram that business and IT share, and worker code in your own repositories, connected by a job type.

Windmill

The step is a normal Python function. Windmill reads its signature to generate the input form and the JSON schema, resolves stripe into a per-script lockfile, and gives the script its own API endpoint. The flow YAML wires arguments between steps and marks the second step as a suspend step, so the run pauses until finance approves.

collect_money.py
flow.yaml

# f/payments/collect_money.py
import wmill
import stripe

def main(order_id: str, amount: int, method: str = "VISA") -> dict:
    stripe.api_key = wmill.get_variable("f/payments/stripe_key")
    charge = stripe.PaymentIntent.create(
        amount=amount,
        currency="eur",
        metadata={"order_id": order_id, "method": method},
    )
    return {"charge_id": charge.id, "status": charge.status}

summary: Collect money, then ask finance to approve
value:
  modules:
    - id: collect_money
      summary: Collect Money
      value:
        type: script
        path: f/payments/collect_money
        input_transforms:
          order_id:
            type: javascript
            expr: flow_input.order_id
          amount:
            type: javascript
            expr: flow_input.amount
          method:
            type: static
            value: VISA
      retry:
        constant:
          attempts: 5
          seconds: 10
    - id: approve
      summary: Finance approval
      value:
        type: rawscript
        language: python3
        content: |-
          import wmill

          def main(charge_id: str):
              return wmill.get_resume_urls("finance")
        input_transforms:
          charge_id:
            type: javascript
            expr: results.collect_money.charge_id
      suspend:
        required_events: 1
        timeout: 1800

Camunda

The diagram is the program. A service task carries a taskDefinition whose type is the contract between the model and your code. The code lives in a separate job worker process that polls for jobs of that type and completes them. The two halves are deployed and versioned independently. Example from Camunda's docs.

process.bpmn
Worker.java

<bpmn:serviceTask id="collect-money" name="Collect Money">
  <bpmn:extensionElements>
    <zeebe:taskDefinition type="payment-service" retries="5" />
    <zeebe:taskHeaders>
      <zeebe:header key="method" value="VISA" />
    </zeebe:taskHeaders>
    <zeebe:jobPriorityDefinition priority="90" />
  </bpmn:extensionElements>
</bpmn:serviceTask>

try (final JobWorker workerRegistration = client.newWorker()
        .jobType(jobType)
        .handler(new EmailJobHandler())
        .open()) {

    System.out.println("Job worker opened and receiving jobs of type: " + jobType);

    // Keep the worker running
    Thread.sleep(Duration.ofMinutes(10));
} catch (InterruptedException e) {
    throw new RuntimeException(e);
}

private static class EmailJobHandler implements JobHandler {
    @Override
    public void handle(final JobClient client, final ActivatedJob job) {
        // Perform your business logic here

        // Complete the job (or use client.newFailCommand() if something goes wrong)
        client.newCompleteCommand(job.getKey())
                .variables(Map.of("emailSent", true))
                .send()
                .join();
    }
}

Windmill

Camunda

Authoring

Windmill

Build scripts in 20+ languages in a dedicated script editor, then compose them in the flow editor. Windmill parses the function signature to generate the input UI, the JSON schema and the argument types. Dependencies resolve automatically into a per-script lockfile. Arguments pass between steps as direct return values, and every script is also a standalone unit with its own UI, API endpoint and scheduler.

Camunda

The executable artifact is a BPMN 2.0 diagram (plus DMN 1.3 for decisions and a form schema for user tasks), authored in the browser-based modeler or in Desktop Modeler, which also exposes the raw XML. Automated steps are not written in the diagram: a service task declares a job type, and your code lives in a job worker process that subscribes to that type.

Local dev & IDE

Windmill

Run and iterate on scripts and flows locally with the Windmill CLI and wmill dev live preview, a VS Code extension, native language tooling (LSP, type-checking, linting) and AI coding tools such as Claude Code working on the real source files.

Camunda

Desktop Modeler runs offline and integrates with your development environment. Camunda 8 Run is a local distribution that bundles the runtime, connectors and an H2 database, and c8ctl is a CLI that can start a local cluster and deploy BPMN, DMN and form resources. Camunda states that Camunda 8 Run "is not intended for production use". The worker half is ordinary code in your own IDE.

Language runtimes

Windmill

TypeScript (Deno, Bun, Node.js), Python, Go, Bash, SQL, PowerShell, PHP, Rust and more (20+ languages total), executed by Windmill's own workers. Any npm, PyPI, Go, Maven or Cargo package is a first-class import with automatic dependency resolution.

Camunda

Camunda runs the process; your workers run your code, in whatever runtime you already operate. Official clients cover Java, Spring Boot, C#, Go, PHP, Python, Rust and TypeScript, alongside community clients, and you can build your own against the API. Deployment, packaging and dependency management of those workers stay your responsibility.

Human steps

Windmill

A step can suspend until approval: per-approver secret resume URLs, a required number of events, a timeout, an optional schema form rendered on the approval page, approvals from Slack or Microsoft Teams, and an option preventing the person who triggered the flow from approving it.

Camunda

User tasks are first-class BPMN elements. Camunda Forms, powered by the open-source bpmn-io form-js library, attach to a user task or start event, and Tasklist renders and routes them. Assignment, claiming and an inbox come with the product rather than being something you build.

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, encrypted at rest, scoped via folders and groups, and versioned in Git. External secret backends (Vault, AWS Secrets Manager) are Enterprise only.

Camunda

Connector configuration references secrets managed per cluster, and Camunda 8 Run documents a local secrets file for development. Because the whole Self-Managed distribution needs a production license anyway, the practical gate here is the deployment, not the feature.

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.

Camunda

Modeling projects can be connected to a remote repository on GitHub, GitLab, Azure or Bitbucket with Git Sync, and the modeler API supports deploying releases from CI/CD pipelines. The scope is the modeling artifacts: diagrams, decisions, forms and connector templates. Users, roles and cluster configuration are managed outside that sync, and your job workers live in their own repositories.

04 · Integrations

How does the platform integrate with your existing stack?

Camunda gives you configured connectors that drop straight into the diagram, and a documented SDK for building your own. Windmill skips the connector layer: any public or private package is an import, and the vendor's own SDK is the integration.

Windmill

Camunda

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 in the editor. 50+ pre-built resource types cover databases (Postgres, Snowflake, BigQuery), SaaS (Slack, Stripe, GitHub, Notion, OpenAI) and infrastructure (S3, Redis, Kafka). A community Hub has reusable scripts and flows.

Camunda

A library of built-in connectors covering Slack, Microsoft Teams, Kafka, Salesforce, SQL, AWS and Azure services, Google Workspace, OpenAI and more, plus a Marketplace of connectors from Camunda, partners and the community. A connector is configured as a task in the diagram with its parameters already laid out, which Camunda positions as removing "the need for you to write custom integration programming code".

Receiving events

Windmill

Native triggers for HTTP, cron, Kafka, NATS, Postgres CDC, SQS, MQTT, AMQP, SMTP, WebSocket and cloud queues. Each one is a typed primitive in the UI: configure it, 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.

Camunda

Events are modeled, not configured on the side: timer, message and signal start events, intermediate catch events and boundary events are BPMN elements in the diagram. Inbound connectors extend the same model to webhooks, Kafka, email and polling, so an incoming event correlates to a waiting process instance by a key you define.

Extending

Windmill

A new integration is a script with a new import: save and run, no restart and no image rebuild, in the web editor, the CLI and Git sync alike. Custom logic can be exposed as a typed script, packaged as a resource type, or published to the private workspace Hub.

Camunda

Two routes. Build a custom connector with element templates and the Connector SDK, which Camunda licenses under Apache 2.0 along with the REST connector and the connector runtime Docker images. Or skip connectors and write a job worker in any language with a client, which is the general-purpose escape hatch and the way most bespoke logic ends up running.

05 · Migration & lock-in

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

Windmill keeps switching cost low. Step code is standard code that runs anywhere, including after you leave. Camunda also keeps your worker code portable, but the executable part of the model, the Zeebe extensions, FEEL expressions and connector templates, is written for Camunda's engine.

Windmill

Camunda

Getting in

Windmill

Paste a function body into the script editor, Windmill infers the arguments, generates a UI and handles dependencies. No diagram and no XML to learn. Triggers, schedules, variables and apps migrate one by one.

Camunda

If your organization already models in BPMN, the notation transfers and the modeler is the familiar part. The work is implementing a worker per task type and wiring deployment for two artifacts that version separately. Teams coming from Camunda 7 have a migration of their own: Camunda states that Camunda 8 "is not a direct drop-in replacement for Camunda 7".

Getting out

Windmill

Step logic is already standard code (TypeScript, Python, Go, Bash, SQL) that runs anywhere, and the CLI exports the full workspace as plain files. What you lose leaving Windmill is the runtime, not the step code.

Camunda

The split cuts both ways. Worker code is yours, in your repositories, and ports cleanly. BPMN and DMN are OMG standards, so the shape of a model is portable in principle. What is Camunda-specific is everything that makes the model executable: the zeebe: extension elements, FEEL expressions, connector element templates, form schemas and the engine's own semantics for retries, incidents and correlation.

06 · Enterprise requirements

Audit logs, observability, security, performance

Camunda has the better view of a stuck business process: Operate shows instance state on the diagram, Optimize reports on it, and the audit log is on by default. Windmill runs on a single Postgres with no separate scheduler or search cluster, and ships more of the enterprise foundation (RBAC, SSO up to 10 users, multiple workspaces) in a core you can run in production for free.

Windmill

Camunda

Observability

Windmill

Real-time streaming logs, per-run inputs, outputs and duration, built-in worker queue metrics and a Prometheus exporter. Trace ID on every job.

Camunda

Operate gives visibility into active and completed process instances and lets you resolve incidents and update variables, which is the clearest view of a stuck long-running process either platform offers. Optimize adds business intelligence on the execution data, with reports, dashboards and bottleneck analysis.

Audit logs

Windmill

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

Camunda

An audit log records who performed an operation, when, and on which entities, across process, identity and user task domains. It is enabled by default and Camunda warns that it writes to secondary storage, with roughly a 3.5% increase in disk usage under default settings.

Security & access control

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.

Camunda

The Orchestration Cluster ships a fine-grained authorization system for its web components and APIs, with mapping rules onto an external identity provider. Every one of those components sits inside the Self-Managed distribution, so there is no free-versus-paid line between features here: the line is around production use of the distribution as a whole. Enterprise only

Architecture & operations

Windmill

A Postgres database holds the entire state, including the job queue; the rest is stateless. Self-hosting a single node is docker compose up, and scaling is adding workers against the same database.

Camunda

Camunda 8 separates the Zeebe engine from secondary storage, which backs Operate, Tasklist, Optimize and the audit log, plus connector runtimes and Identity. That is more moving parts to operate than a single database, and it is also what gives the engine its horizontal partitioning and the web apps their query surface.

Performance

Windmill

~10ms cold starts. Dedicated-worker mode Enterprise only keeps runtimes and dependencies pre-warmed. Our published benchmarks cover Airflow, Prefect, Temporal, Kestra, Hatchet and Windmill. Camunda is not in that dataset, so we make no claim about the two engines' relative throughput.

Camunda

Zeebe is designed to scale horizontally through partitioning, with job workers polling or streaming jobs and backpressure when a cluster is loaded. Per-process overhead is dominated by state persistence and the hop to an external worker rather than by the step code itself.

07 · Licensing & pricing

Open source, pricing, and self-hosting?

Windmill's AGPLv3 core is free to run in production, and Enterprise pricing is published upfront. Camunda 8 Self-Managed is source-available under the Camunda License v1 and free for development only: production needs a paid license, and Camunda publishes no figures for it.

Windmill

Camunda

Open-source license

Windmill

AGPLv3 core, free and unlimited self-hosted, in production, with no seat or instance cap. Enterprise features (SSO beyond 10 users, dedicated workers, audit log retention, external secret backends) ship in a separate proprietary codebase. Managed cloud available.

Camunda

Source-available, not open source. Zeebe, Operate, Tasklist, Identity and Optimize are published under the Camunda License v1, and Camunda's docs state the compiled software is "distributed under a proprietary license". Apache 2.0 still covers the Connector SDK, the REST connector and the connector runtime images, and Desktop Modeler is MIT.

Production use

Windmill

Running the AGPLv3 core in production is free. AGPLv3 is a reciprocal license: if you modify Windmill itself and expose it over a network, you have to make those modifications available. Using it unmodified, however heavily, carries no such obligation.

Camunda

Production requires a paid license. Camunda's October 2024 announcement states that "Camunda 8.6 Self-Managed now requires a production license for use in production environments", and the docs say "To use the software in production, purchase the Camunda Self-Managed Enterprise Edition". The Self-Managed Non-Production Terms limit free use to "non-production environments or for testing and evaluation purposes". Enterprise only

The Camunda 7 path

Windmill

Not applicable: there is one Windmill codebase, and the open-source core has not been relicensed or discontinued.

Camunda

Camunda 7's Community Edition was genuinely open source, under mainly Apache 2.0 and MIT, and free to run in production. It reached end of life in October 2025 with a final release, v7.24, on 14 October 2025. Camunda 7 Enterprise is supported until April 2030, with extended support to April 2032. So the free-in-production option exists in Camunda's history, but it is no longer a path you can start down.

Pricing visibility

Windmill

Public per-seat and per-worker pricing on the pricing page, with the self-hosted Community Edition free.

Camunda

No figures published. The pricing page lists "Talk to sales" for Self-Managed production and for Camunda SaaS. SaaS offers a 30-day free trial, after which an account is limited to BPMN and DMN modeling unless you move to a paid plan.

08 · Verdict

The verdict

Windmill and Camunda disagree about what a workflow is. For Camunda, it is a diagram in a standard notation that business and IT both own, with the code pushed out to job workers behind it. For Windmill, it is code: scripts in real languages composed into a flow, where each script is also a standalone unit with its own UI, API endpoint and scheduler.

Camunda is the right call if the process model is a deliverable in its own right. If a compliance officer, an analyst or an auditor has to read and change it, BPMN and DMN are standards built for exactly that, decision tables are editable without code, and Tasklist and Operate give you a human task inbox and an instance view that no code-first tool matches out of the box. Long-running, human-heavy business processes are what Camunda was designed for, and it does them well.

Windmill is the right call if engineers own the automation. The whole workflow is one artifact you can diff, review and roll back, with a local dev loop, AI coding tools working on the real source files, and whole-workspace Git sync covering scripts, flows, apps, resources, schedules and permissions. The runtime scope is wider: the same platform runs data pipelines, AI agents and both low-code and full-code internal apps, with shared auth, secrets and observability. Human steps are covered by suspend and approval pages with forms, Slack and Microsoft Teams, which handles most approval workflows without a separate task application.

Two differences are worth weighing separately from features. The first is licensing: Windmill's AGPLv3 core is free to run in production and Enterprise pricing is published, while Camunda 8 Self-Managed is source-available and free for development only, with production requiring a paid license at a price you have to ask for. The second is that as AI agents write more of our automation, the artifact they produce matters. Code is something a model can write, a reviewer can read in a diff and a test can exercise. A diagram is better for a human audience and worse for that loop. Which of those you optimize for is a real decision, not a tiebreaker.

If you're deciding between the two, the fastest way to judge is to spend an afternoon in each.

Frequently asked questions

: No. Camunda executes BPMN 2.0 and DMN 1.3 models, and Windmill has no BPMN engine. If your organization standardizes on BPMN diagrams as the artifact that business and IT agree on, or if you need DMN decision tables, Camunda is the right tool. Windmill covers the orchestration itself: long-running flows with branches, loops, retries, timers, suspend and approval steps, written as code instead of as a diagram.
: No, there is no BPMN importer. A migration is a manual rewrite: each service task becomes a Windmill script referenced from a flow, each user task becomes a suspend or approval step with a form, and FEEL expressions become JavaScript input transforms. The business logic inside your job workers usually ports as-is, since it is already ordinary code in your own repository.
: No. Camunda's October 2024 announcement states that "Camunda 8.6 Self-Managed now requires a production license for use in production environments", and its docs say "To use the software in production, purchase the Camunda Self-Managed Enterprise Edition." The Self-Managed Non-Production Terms allow use "solely in non-production environments or for testing and evaluation purposes". Windmill's AGPLv3 core is free to self-host in production with no seat or instance cap, and Enterprise features live in a separate proprietary build.
: Camunda 7 Community Edition, whose components were open source under mainly Apache 2.0 and MIT licenses, reached end of life in October 2025 with a final release, v7.24, on 14 October 2025. Camunda 7 Enterprise support runs until April 2030, with extended support to April 2032. Camunda states that Camunda 8 "is not a direct drop-in replacement for Camunda 7", so teams on Camunda 7 Community face a migration either way.
: Yes, through suspend and approval steps. A step can be set to suspend until a number of approval or cancel events arrive at per-approver secret resume URLs, with a timeout, an optional schema form rendered on the approval page, approvals from Slack or Microsoft Teams, and an option that prevents the person who triggered the flow from approving it. What Windmill does not ship is a task inbox like Camunda Tasklist, where assignees browse and claim tasks; you would build that as a Windmill app.
: Only partially. Windmill has a visual flow editor and auto-generates input forms, but authoring a step still means writing code. This is where Camunda genuinely wins: BPMN and DMN are standards a business analyst can read and edit in a modeler, decision tables are editable without code, and reviews happen on visual diagrams rather than on XML. If a non-technical audience has to own the process model, Camunda is built for that and Windmill is not.
: Windmill publishes per-seat and per-worker Enterprise pricing on its pricing page. Camunda does not publish figures: its pricing page lists "Talk to sales" for Self-Managed production and for Camunda SaaS, with a 30-day free trial of SaaS, after which an account is limited to BPMN and DMN modeling unless you move to a paid plan.

Build your internal platform on Windmill

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

Get started for free