Kestra vs Windmill: which to choose

Kestra vs Windmill: when to choose each

Choose Kestra if your team wants declarative YAML flows, scheduled and event-driven triggers and a plugin catalog for databases, cloud storage and APIs. Choose Windmill if developers who write scripts want to compose them into flows and internal apps. The deciding questions are who will maintain the workflows day to day, which languages they use, how much infrastructure your team can operate, and which paid features your production environment requires, such as SSO, SCIM, audit logs and external secrets. Kestra's model suits a platform or data team that wants workflows reviewed as version-controlled configuration, with Git integration and a no-code editor for others to read. Windmill suits a team where engineers are comfortable turning a Python, TypeScript or Go script into a shared tool.

Infrastructure is the next filter. The Kestra open-source edition is licensed under Apache-2.0 and is documented with a single-server default deployment, so a small team can start quickly, but high availability in Kestra Enterprise adds Kafka with Elasticsearch or a Redis, AMQP or GCP Pub/Sub queue backend. Windmill's workers pull jobs from a PostgreSQL queue, and its repository documents Docker Compose and Kubernetes Helm deployments with external PostgreSQL. Ask each vendor to confirm which components you must operate for your expected load, and check whether your team already runs PostgreSQL well enough to own that dependency.

Licensing and paid features decide the final shortlist. Kestra's edition comparison places SSO, SCIM, RBAC, audit logs, external secrets managers and multi-tenancy in Kestra Enterprise, while the open-source edition uses basic authentication and manual secret management. Windmill's Community Edition is free for self-hosting within limits of 3 workspaces, 50 users and 4 groups, and its Enterprise Edition adds SAML, SCIM, audit logs and Vault or AWS Secrets Manager integration. Confirm current prices and terms directly with each vendor, because both pricing pages can change, and remember that Windmill's source is AGPLv3 while its prebuilt Community images include proprietary code limited to internal use.

Which scenarios favor Kestra or Windmill

This table maps common team situations to the platform that fits them better and the condition under which the other one would win. Read each row against your own team's skills, data sources and compliance deadlines, since neither platform is the better choice across all of them.

Scenario	Better fit and reason	The other platform wins when
Data platform team running YAML pipelines with many plugins	Kestra. Flows are declarative YAML, the README lists hundreds of built-in plugins for databases, cloud storage and APIs, and Git integration fits pipeline review.	Engineers prefer writing the logic in Python or TypeScript and want reusable scripts as the main unit of work, where Windmill's script-first model fits better.
Developer team turning Python or TypeScript scripts into approval flows and internal tools	Windmill. Scripts in many languages can be composed into flows and low-code apps, which suits developers who want a UI on top of existing code.	The workflow is mainly a sequence of pre-built connectors with little custom code, where Kestra's plugin catalog and YAML editor are the closer match.
Platform team that must run the workflow engine in high availability	Kestra Enterprise, if HA is needed from the start. Its Enterprise Edition adds a high availability architecture with Kafka plus Elasticsearch, Redis, AMQP or GCP Pub/Sub queue backends. Confirm the exact backend your team would operate.	A single PostgreSQL-backed deployment with external database services is acceptable, where Windmill's documented Kubernetes Helm charts and external PostgreSQL support may cover the requirement. Confirm HA behavior in the Windmill docs.
Security team requiring SSO and audit logs on day one	Neither open-source edition provides these. Kestra's open-source edition has basic authentication and no audit logging. Windmill Community has no SAML or audit logs in the supplied pricing facts.	Windmill Enterprise lists SAML, SCIM and audit logs in its Enterprise tier, and Kestra Enterprise lists SSO, SCIM, RBAC and audit logs. Budget and compare both paid editions before choosing.
Team needing secrets from an external vault	Kestra Enterprise, which lists external secrets managers such as HashiCorp Vault and Azure Key Vault. The open-source edition relies on manual secret management.	Windmill Enterprise, which lists external secret backends such as Vault and AWS Secrets Manager, is the choice if Windmill is already shortlisted and the secret backend matches.
Organization with AGPLv3 or commercial licensing concerns	Kestra, whose open-source edition is Apache-2.0 licensed, which is typically simpler for legal review of embedded or internal use.	Your legal team has approved AGPLv3 use and Windmill's developer workflow is the priority. Confirm the license obligations for managed services or resale with counsel.
Team that wants AI agents and MCP exposure in workflows	Kestra, whose README lists AI agent and RAG task types and a built-in MCP server that exposes flows to AI agents. Confirm the features against your Kestra version.	The need is script-level automation of internal tools with AI assisting code writing, where Windmill's script-first approach may suit better. Verify current AI features before deciding.

How Kestra and Windmill are built and deployed

Both platforms can run on infrastructure you control, but they split work across different components and stores. The cards below cover what each deployment model asks your operations team to run, back up and scale, so you can match the architecture to your team and availability needs.

Kestra single-server default deployment

The open-source edition is fully functional for production but defaults to a single-server deployment. That keeps the footprint small, but one host becomes the availability boundary for scheduling, execution and the UI. Operations teams should plan their own backup and restore procedure for the state Kestra keeps, and confirm with Kestra which configuration covers their recovery targets. Ask whether a single-server setup meets the uptime your scheduled flows need before committing to it.

Kestra Enterprise high availability architecture

Enterprise Edition adds a high availability architecture that uses Kafka plus Elasticsearch, Redis, AMQP or GCP Pub/Sub as queue backends, along with worker groups and task runners for Kubernetes and cloud batch services. Each backend is another stateful system to size, patch, monitor and back up. Confirm with Kestra which queue backend fits your cloud and which components must be scaled independently before you estimate operating effort. This is the main reason an Enterprise license and a dedicated platform engineer are often considered together.

Windmill Rust backend and job queue

Windmill's backend is written in Rust. API servers are stateless, and workers pull jobs from a PostgreSQL queue, so PostgreSQL is the central stateful dependency. Scaling the API tier and the worker tier is a separate decision from scaling the database. Back up the PostgreSQL instance as the primary record of workflow state and job data, and confirm your restore time with your own tests. The sizing guidance in the README is one worker per vCPU with 1 to 2 GB of RAM, a rule of thumb to validate against your own load.

Nsjail sandboxing for job execution

Windmill sandboxes its jobs with nsjail, which matters when user-written scripts run inside your network and may touch internal systems. The sandbox limits what a job can reach on the host, but it does not replace network segmentation, credential scoping or review of which scripts are allowed to run. Security teams should ask the vendor how the sandbox is configured in the self-hosted build, which workers have access to which secrets, and how jobs are isolated across workspaces.

Windmill Docker Compose and Helm options

Windmill documents self-hosting with Docker Compose for smaller installs and Kubernetes Helm charts for larger ones. Both paths support an external PostgreSQL database, including AWS RDS, GCP Cloud SQL and Azure managed services. Using a managed database moves patching and some backup tasks to the cloud provider, but the team still owns the connection settings, database access controls and recovery testing. Choose the path based on whether your platform team already runs Kubernetes and managed databases.

Which stores and tiers to back up and scale

In Kestra, the operations team must confirm the state stores and queue backends used in each configuration, then back up and scale them as a set. In Windmill, the PostgreSQL database and the worker pool are the two components that most directly determine throughput and recovery. Build a short inventory before procurement: list each stateful service, its owner, its backup method, its restore test and the component that scales under load. Ask both vendors and your implementation partner to confirm this inventory against your own environment.

Kestra and Windmill feature by feature

This table compares Kestra and Windmill on authoring, languages, triggers, Git, identity, audit, secrets, AI features and observability, with the open-source and paid edition boundary shown for each. Read the Kestra and Windmill columns against your own requirements, and treat any cell marked to confirm as a question for the vendor before you decide.

Capability	Kestra	Windmill
Authoring model	Declarative YAML flows, edited in a YAML editor, a no-code editor or an AI Copilot that stay in sync	Scripts first, composed into flows or low-code internal apps
Supported languages	Running scripts in any language is listed in the README; check specific runtimes with the vendor	Python, TypeScript, Go, Bash, SQL, GraphQL, PowerShell, Rust and more
Triggers	Scheduled and event-driven triggers listed in the README	Confirm the full trigger catalog with Windmill before you commit
Git integration	Git version control integration listed in the README; confirm the depth of sync in your edition	Full Git sync is listed as an Enterprise feature on the pricing page
Identity and login	Basic authentication in open source; SSO, SCIM and RBAC in Enterprise	SAML and SCIM listed as Enterprise features; confirm SSO options in the open-source build
Audit logging	Not in open source; audit logs listed in Enterprise	Audit logs listed as an Enterprise feature
External secrets managers	Manual secret management in open source; Vault and Azure Key Vault in Enterprise	Vault and AWS Secrets Manager listed as Enterprise features
AI features	AI agents, RAG task types and a built-in MCP server listed in the README	Confirm AI features and any MCP support with Windmill
Observability	Confirm metrics and tracing options for your edition with Kestra	Prometheus and OpenTelemetry support listed as an Enterprise feature

What each license and paid edition covers

Kestra's open-source edition is licensed under the Apache License 2.0, which is a permissive open-source license. The project states that this edition is fully functional for production, so a team can run flows, triggers and plugins in its own infrastructure without a license fee. The trade-off is in the operational and security features. The edition is designed around a single-server default deployment, and the security and governance layer is thinner than a regulated team usually expects.

Licensing: Apache License 2.0, covering use, modification and redistribution of the source.
Production use: Described by the project as fully functional for production.
Authentication: Basic authentication only.
Secrets and access: Secret and access management is manual.
Audit logging: Not included in the open-source edition.

Before relying on the open-source edition for a regulated workload, confirm the current edition comparison on the vendor's site and map each gap to your own control requirements.

What the paid editions reserve for SSO, audit and secrets

On both platforms, identity, audit and secrets controls sit behind the paid tier, so the fair comparison starts with your own requirements rather than with list prices. Map each control to a specific obligation first: who must sign in through your corporate identity provider, which administrative actions must leave an audit trail, where credentials must be stored, and whether separate business units need isolated workspaces. Only then does the price of each edition mean anything. Kestra Enterprise Edition reserves SSO, SCIM and RBAC, service accounts and API tokens, external secrets managers such as HashiCorp Vault and Azure Key Vault, audit logs, multi-tenancy and worker isolation. The open-source edition provides basic authentication only, manual secret and access management and no audit logging, so any production use that needs federated sign-in or traceable changes must plan for the paid tier. Windmill Enterprise reserves SAML and SCIM, audit logs, external secret backends such as Vault and AWS Secrets Manager, and full Git sync, while its Community Edition is free to self-host within its workspace, user and group limits.

Confirm with each vendor how the identity provider is configured on your side: which SAML or OIDC settings, which SCIM attributes drive group and role assignment, and how role mapping behaves when a user leaves the directory. Ask how audit events are exported, in what format, and how long they are retained inside the product, because your SIEM or evidence store will depend on that answer. Ask how secret backend credentials are rotated and which account the platform uses to read them. Several controls remain yours to operate on either platform. Your team still owns the Vault or Key Vault policies, the rotation schedule, the review of role assignments, the retention of exported logs and the decision about who may create service accounts or API tokens. Treat the vendor's feature list as the start of your control design, and write these responsibilities into your runbook before you sign a paid contract.

What drives the running cost of each platform

Running Kestra or Windmill costs more than the license line on a quote. Infrastructure, paid edition seats, the skills to write and maintain flows, upgrade work and external services each carry their own cost, and each one grows or shrinks with a different decision.

Infrastructure footprint

Kestra's open-source edition defaults to a single server, so the baseline is one host plus its storage. An HA deployment with Kafka plus Elasticsearch, a Redis, AMQP or GCP Pub/Sub queue, and worker groups is a much larger stack to run and patch. Windmill sizes workers at one per vCPU with 1 to 2 GB of RAM, plus PostgreSQL. Ask the vendor or your architect to model worker counts and queue load for your expected run volume before comparing hosting bills.

Paid edition fees

Kestra Enterprise adds SSO, SCIM and RBAC, audit logs, external secrets managers, multi-tenancy and the HA architecture, and it is priced by quote. Windmill publishes a self-hosted Enterprise price that starts at $120 per month, with per-seat charges for developers and operators plus compute units. Recurring fees are the main ongoing cost for either vendor. Ask for the seat counts, compute unit assumptions and renewal terms in writing, and confirm which controls you need before you assume the paid tier.

Skills to maintain flows

Kestra flows are declarative YAML that a platform team can review in Git, and the no-code editor and AI Copilot stay in sync with that YAML. Windmill scripts are written in languages such as Python, TypeScript, Go and SQL, so the work leans toward developers. The cost is staff time: who writes, reviews and debugs flows, and how long a new maintainer needs to become productive. Estimate this from your own team's skill mix rather than from the vendor's examples.

Upgrade effort and release cadence

Kestra 2.0 is a major release with breaking changes, including replacing ForEach and ForEachItem with a single Loop task, and it ships with a dedicated migration guide. Windmill ships very frequently, with v1.840.0 released on October 17, 2026. Upgrade work recurs for both, but the shape differs: a planned major migration for Kestra, and smaller, more frequent updates for Windmill. Budget test time for flow regressions after each change, and ask who owns that testing.

Support and retainer options

Both platforms can run without a vendor support contract, but unplanned incidents, upgrades and security patching then fall to your team. Retainers from an implementation partner cover ongoing support, upgrades and continuous testing, usually on a schedule agreed in writing. Compare the response expectations, the upgrade scope and what is included in each retainer against your internal on-call capacity. Confirm whether a vendor subscription and a partner retainer overlap before you sign either.

External services and managed PostgreSQL

Windmill depends on PostgreSQL for its job queue and state, and it supports external databases such as AWS RDS, GCP Cloud SQL and Azure. Managed PostgreSQL bills for instance size, storage, backups and high availability options, and those charges recur monthly. Kestra's HA design adds its own managed or self-run services for Kafka, Elasticsearch and the queue backend. Ask for a line-by-line cost of each service, the backup retention you need, and who is responsible for failover tests.

Moving workflows from Kestra to Windmill or back

This sequence moves workflows between Kestra and Windmill without losing track of triggers, credentials or behavior, and ends with a documented cutover where only one system runs each flow.

Inventory flows, triggers, plugins and secrets
Start by listing every Kestra flow in scope, its namespace, its schedule and event triggers, the plugin tasks it calls, and the secrets and external connections it reads. Record who owns each flow and which downstream systems depend on its outputs. The team that runs Kestra today should do this with the platform owner, because undocumented triggers are the most common source of gaps. The output is a single inventory sheet that marks each item as keep, rebuild or retire, and it is done when the owners have signed off on it.
Decide which flows become YAML or scripts
For each inventoried flow, decide whether it stays as a declarative Kestra-style YAML definition or becomes a Windmill script or flow. Flows that are mostly configuration, with plugin calls and simple branching, often suit the YAML model, while flows that need custom logic, unit tests or reusable internal functions often suit scripts. Involve the people who will maintain each flow after cutover, since the decision changes who can edit it. The output is a decision column in the inventory, and the step is complete when every flow has one target format and a named maintainer.
Map Kestra plugin tasks to Windmill scripts
Take each plugin task the inventory lists and find its equivalent in Windmill, either as a script in a supported language, an existing library, or a direct API call. Note where no equivalent exists so the team can write a replacement or drop the task. Confirm each mapping against the current documentation of both products, because plugin catalogs and language support change between releases. The output is a mapping table with one row per plugin task, showing the replacement and any gap, and the step is done when every gap has an owner and a decision.
Move credentials into the target secrets backend
Move secret values only through a controlled process: the security team approves the list of secrets, a named administrator loads them into the target system's secrets backend, and the transfer is logged. Kestra's open-source edition manages secrets manually, so the source values often sit in environment variables or files that must be located first. Enterprise features such as external secret managers depend on which edition each side runs, so confirm the current feature set with each vendor before relying on it. The output is a secrets register showing where each value now lives, and the step is complete when the source copies have been rotated or removed under the approved process.
Rebuild and transfer definitions through Git
Store the rebuilt flows and scripts in version control so that definitions move as reviewable code rather than as copied screens. Flow logic that is written down in the Kestra definition can be carried over as documented, but the Windmill version still needs its own testing because the runtime, language and plugin behavior differ. Check that each rebuilt definition matches the inventory entry, including inputs, outputs and error handling. The output is a repository with one commit per flow and a review record, and the step is done when a second engineer has reviewed each rebuilt flow.
Run old and new flows in parallel
Run each rebuilt flow alongside its Kestra original against the same inputs, with the new copy writing to a separate destination or a dry-run target. Compare outputs, run times and error paths, and record every difference with a decision on whether it is a defect or an accepted change. Parallel running is what shows whether the rebuild matches the original, so keep it running long enough to cover the normal schedule and at least one failure case. The output is a comparison log for each flow, and the step is complete when the owners accept the differences in writing.
Cut over triggers and retire old schedules
Switch each trigger from the Kestra flow to the Windmill equivalent in a planned window, and disable the Kestra schedule at the same time so that no job runs twice. Keep the Kestra flow definitions in version control for a documented period so the team can restore them if a problem appears. Confirm with downstream owners that they receive the expected outputs from the new trigger. The output is a cutover record listing each trigger, its new owner and the time it moved, and the step is done when the old schedules are disabled and the rollback path has been tested.
Document the outcome and retire the source
Update the runbook, the on-call notes and the access lists so they describe the target system only. Remove the old credentials, revoke service accounts that no longer have work, and archive the Kestra environment according to the retention policy agreed in the inventory. Ask whoever runs the target platform to confirm the supported versions and upgrade path before the old system is removed. The output is an updated runbook and a closure record, and the step is complete when the access review confirms that the retired system no longer holds live credentials.

Where Kestra and Windmill implementation projects run long

Implementation time on Kestra usually goes to plugin configuration, flow migration and, if the client needs it, the Enterprise high availability design. The plugin catalog is broad, and each database, cloud storage target or API a flow touches needs its own credentials, network path and error handling. Inventory every external system the first flows call, then decide which plugins the team will standardize on and which custom scripts it will maintain. Kestra 2.0 adds a second delay point: the README states that the single Loop task replaces ForEach and ForEachItem, and the 2.0 migration guide applies. Any flows written for 1.x need a review pass against that guide before they run on 2.x. Ask your implementation partner to scope that migration as a named deliverable with a test plan, and confirm the 2.0 breaking changes against the migration guide in your own environment before estimating.

The Enterprise high availability design is the longest single item on a Kestra HA project. The Enterprise edition comparison describes a design built on Kafka plus Elasticsearch, Redis, AMQP or GCP Pub/Sub queue backends, worker groups and task runners for Kubernetes and cloud batch services. Each backend choice brings its own operations, sizing, monitoring and failover tests, and the choice of queue and search backend should be settled before infrastructure work starts. Confirm with Kestra which combinations it supports in your target cloud or data center, and which of them your team can operate. Ask for the HA reference architecture in writing before any estimate is accepted.

On Windmill, the first delay is script standardization. Scripts can be written in Python, TypeScript, Go, Bash, SQL, GraphQL, PowerShell, Rust and more, and each language brings its own dependency, secret and testing conventions. Decide which languages are permitted for production, who reviews them, and how shared code is versioned before teams start building flows. Sandboxing and worker sizing are the second delay point. Jobs are sandboxed with nsjail, and the README's rule of thumb is one worker per vCPU with 1 to 2 GB of RAM, which you must validate against your own job mix. Finally, external PostgreSQL setup (for example AWS RDS, GCP Cloud SQL or Azure) takes time because the job queue lives in that database. Workspace and group design also matters under the Community limits on the Windmill pricing page: 3 workspaces, 50 users and 4 groups. Map those limits against your teams before build-out, and confirm current limits with the vendor. DeployOpen scopes these implementations in writing before work starts, so ask for the delay risks to be listed in that scope.

Questions buyers ask before choosing Kestra or Windmill

What does each platform cost to run and what drives it up?

Both open-source editions have no license fee for the software itself, so the recurring cost is the infrastructure, the staff time to operate it, and any paid edition you add. For Windmill, the Community Edition is free for self-hosting with limits of 3 workspaces, 50 users and 4 groups, while its self-hosted Enterprise Edition starts at $120 per month, priced at $20 per month per developer and $10 per month per operator plus compute units, according to its pricing page as of October 2026. For Kestra, the open-source edition is free under Apache-2.0, and Enterprise adds SSO, audit logs, external secrets and a high availability architecture, but no price is in our supplied sources, so ask Kestra for a written quote. Costs rise with user count, the number of workers, and whether you need high availability backends such as Kafka and Elasticsearch. Ask each vendor for a quote that separates license, compute, support and the internal hours your team will spend.

Can our team maintain workflows without a developer?

It depends on how your team works. Kestra defines flows in declarative YAML, and its README describes a YAML editor, a no-code editor and an AI Copilot that stay in sync, so operators who read configuration can maintain flows without writing general-purpose code. Windmill centers on scripts in languages such as Python, TypeScript, Go, Bash and SQL, composed into flows and low-code apps, so it suits teams where developers write the logic and others run the apps. Both platforms need someone who can handle Git-based change control, secrets and failure handling. In a pilot, have your least technical intended maintainer build and change one flow in each tool, then compare how much they had to ask for help.

How long does a first implementation usually take and what does it depend on?

No duration figure for either platform is in our supplied sources, so treat any number you hear as unverified until it is tied to a written scope. The main drivers are the number of systems each flow touches, how many plugins or custom scripts you must build and test, identity integration (SSO and SCIM are Enterprise features in Kestra and Windmill), and whether you need high availability from the start. Windmill's self-hosting paths use Docker Compose or Kubernetes Helm charts with external PostgreSQL, while a Kestra single-server default is simpler to stand up but may not meet your availability requirements. Most engagements at DeployOpen are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so ask for a scope that lists integrations, environments and acceptance tests.

What does the work need from our staff?

The work needs infrastructure operators, a platform owner and people who understand the workflows being automated. Kestra's open-source edition offers basic authentication only, a single-server default, manual secret and access management and no audit logging, so your team must supply those controls or buy Enterprise. Windmill's Community Edition is also self-hosted, and its Enterprise features include SAML, SCIM, audit logs, external secret backends and autoscaling. Windmill's README gives a sizing rule of one worker per vCPU with 1 to 2 GB of RAM, which helps capacity planning. Confirm with each vendor which controls the open-source tier leaves to you, and ask DeployOpen for a scope that states which of them it will set up and document.

Can we start on open source and buy Enterprise later?

Yes, both vendors offer a path from a free self-hosted edition to a paid one, but the move is not automatic. Kestra's open-source edition is fully functional for production, and Enterprise adds SSO, SCIM and RBAC, service accounts, external secrets managers, audit logs, multi-tenancy and the high availability architecture. Windmill's Community Edition is free for self-hosting within its workspace, user and group limits, and its Enterprise Edition adds SAML, SCIM, audit logs and external secret backends. Before you start, confirm with each vendor whether the upgrade keeps your existing deployment, what downtime and configuration changes it requires, and how the license is applied to your environments.

Is a migration between Kestra and Windmill worth the effort?

Migration is worth the effort only when the current tool blocks a requirement that matters to you, such as the Enterprise controls you need, a licensing constraint, or a team shift from YAML to scripts or the reverse. The two tools use different models: Kestra flows are declarative YAML, while Windmill scripts and flows are code, so flows must be rewritten rather than copied. Start by inventorying flows, triggers, secrets and downstream systems, then estimate the rewrite and test effort for each. Ask DeployOpen for a fixed-scope migration assessment that lists the flows in scope, the testing approach and the cutover plan before you commit.

Which licensing terms should our legal team check first?

Start with the license that applies to the exact build you deploy. Kestra's open-source edition is licensed under Apache-2.0, per the LICENSE file in its repository. Windmill's source compiled without the enterprise feature flag is under AGPLv3 and Apache-2.0, but its prebuilt Community Edition images include proprietary code that is free for internal use, while managed services or reselling require a commercial license. Ask both vendors to confirm in writing how their terms apply to your internal use, any hosted or customer-facing use, and any modifications you plan to make. Your counsel should review these points against your own deployment model.

How DeployOpen helps choose and implement either platform

DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Kestra vs Windmill, we start with the workflow portfolio, the people who will maintain it and the edition features your controls require, then build and hand over a platform that fits that answer.

How we scope

We map which workflows suit YAML flows and which suit code-first scripts and internal apps.
We confirm which SSO, audit, secrets and high availability requirements need a paid edition.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We deploy the chosen platform in your infrastructure, using your identity, network and storage conventions.
We configure the database, queue and worker layout that your job volume and recovery targets require.
We test authentication, secrets handling, job isolation and backup restores against the written scope.

How we hand over

We document architecture, runbooks, upgrade steps and access model so your team can operate the platform.
We deliver evidence for internal reviews and compliance assessments, without issuing audit reports or certifications.
We walk your maintainers through authoring standards for flows, scripts and apps before handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We track release changes for the version you run and plan upgrades with your change control process.
Ask us to confirm edition features, license terms and version support windows against current vendor sources before you buy.

Kestra vs Windmill