Kestra vs Microsoft Power Automate

Kestra

Kestra's open-source edition has a 216-operation OpenAPI spec, Markdown docs for agents and weekly patch releases on two long-term support lines. Its only credential is one basic-auth username and password with full access, and five critical advisories were published between March and September 2026, all fixed.

Microsoft Power Automate

Cloud flows in a solution are rows an agent can read and write through the Dataverse Web API under Entra ID OAuth and security roles, with published limits and a 99.9 per cent SLA. Flows under My flows can't be managed in code, a flow's body is one hand-built JSON string, and setup needs a tenant administrator.

Kestra

1. Run 2.0.5 or 1.3.42 or later. Earlier builds carry unauthenticated remote code execution advisories fixed in 1.3.38 and 2.0.3
2. Set kestra.server.basic-auth in the config file before first start. Without it the setup page is open to anyone who reaches the port
3. Put the tenant in the path. Open-source instances use main, as in /api/v1/main/executions/{namespace}/{id}
4. Send flow inputs as multipart form fields, and add wait=true to get the finished execution in the same call
5. Keep port 8081 off any shared network. The management endpoints there skip the API's basic auth

Microsoft Power Automate

1. Filter workflows on category eq 5 for cloud flows, and add $select, because clientdata holds the whole definition
2. Flows created through the API start with statecode 0 (off). The docs say to turn the flow on before use
3. Put the flow in a solution first. Flows that sit only under My flows are outside the supported API
4. On 429 wait the Retry-After seconds. Reads of flowruns count against the daily Power Platform request allowance
5. Treat an HTTP trigger URL with sig= as a secret, and prefer the tenant or named-user trigger modes with a bearer token for https://service.flow.microsoft.com/