Prefect or Kestra: when each one fits
A team shortlisting two self-hosted orchestrators for data and automation work usually asks which one matches the people who will build and maintain the flows. Prefect fits Python-first engineers who want code-native flows, where a Python function becomes a flow and the logic lives in the same repository as the rest of the application code. Kestra fits mixed teams who want declarative YAML workflows assembled from plugins, with scheduled and event-driven triggers, Git integration and an editor that analysts and operators can work in alongside engineers. Neither choice is wrong on capability alone. The question is which skill set will still be maintaining flows in two years.
Three factors should drive the decision. The first is who maintains flows day to day: if that group is mostly Python developers, Prefect's model keeps authoring close to the tools they already use, while a team with many non-developer flow authors may find Kestra's YAML and no-code editor easier to review. The second is how many servers you plan to run. The open-source Prefect server supports multi-server setups, but that requires PostgreSQL, Redis for event messaging and a load balancer, as described in the self-hosted Prefect documentation. Kestra's open-source edition defaults to a single server, and its high availability architecture is part of the Enterprise Edition.
The third factor is identity and audit. Before you commit, list which RBAC, SSO and audit controls must be in place from day one. Prefect documents RBAC, audit logs and SSO as features of Prefect Cloud rather than the self-hosted server, and Kestra's comparison places SSO, SCIM, RBAC and audit logs in its Enterprise Edition. If your controls must run inside your own network, confirm with each vendor which edition provides them, what the license cost is, and whether it changes your deployment design before you start a proof of concept.
Which platform fits which scenario
This table maps common team situations to the platform that usually fits better and the condition that makes it so. Read each row as a starting point: the condition column tells you what would need to be true for the recommendation to hold in your environment.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Python data team owning pipelines | Prefect | Engineers write and test pipelines as Python functions and want them in the same repository, review process and test suite as the rest of their code. |
| Operations team owning YAML workflows | Kestra | Operators or platform staff need to read, change and review workflows without writing Python, and the team is comfortable with declarative YAML and plugin tasks. |
| Mixed team with Python and non-developer editors | Either, after a pilot | Both platforms can serve mixed teams, but the split of who edits what should be tested on one real flow before committing, since authoring models differ. |
| Event-driven automation across systems | Kestra | Your main need is triggers from external events, file arrivals or API calls wired into many plugins, and you want those triggers defined declaratively in the workflow file. |
| Python-centric automation with event-based reactions | Prefect | Your flows are mainly Python code, and you want event-based automations layered on top of scheduled and retried Python runs. |
| Single-server pilot | Either, with a caveat | Kestra's open-source edition defaults to a single-server deployment, and Prefect server uses SQLite by default. Both are workable for a pilot, but confirm that either default matches the durability you need before production. |
| Multi-server production estate | Confirm before choosing | Prefect multi-server setups need PostgreSQL, Redis for event messaging and a load balancer. Kestra's high availability architecture with Kafka, Elasticsearch and Redis or similar queues is documented in its Enterprise Edition. Ask each vendor to confirm the full open-source topology for your scale. |
| Requirement for SSO, RBAC and audit logs | Depends on the edition you buy | Prefect Cloud provides these features, and the self-hosted server does not include them. Kestra Enterprise Edition adds SSO, RBAC and audit logs, while its open-source edition has basic authentication and no audit logging. Budget for the paid tier either way if these are mandatory. |
How Prefect and Kestra are built and deployed
Prefect and Kestra both run as a server that holds run state, schedules and logs, but they reach production in different shapes. The defaults, the database and queue requirements, and the features reserved for paid tiers decide how much platform work your team takes on before the first flow runs.
Prefect server bundle
The self-hosted Prefect server packages an API, a UI and a database that records flow and task run state, logs, deployments, concurrency limits, variables, artifacts, work pool status, events and automations. It uses SQLite by default, so a single-machine trial needs no extra services. Confirm early that your team will move to PostgreSQL before any production use, because the default is not meant for that load.
Multi-server Prefect requirements
Running more than one Prefect server means PostgreSQL 14.9 or later, Redis for event messaging and a load balancer in front of the API servers. Each of these is a component your team must provision, secure, back up and monitor. Ask whether your platform group already runs Redis and a load balancer under the same change control as the rest of the stack, since those dependencies are where multi-server setups usually stall.
Kestra single-server default
Kestra's open-source edition is fully functional for production but deploys on a single server by default. Scaling beyond that is part of the Enterprise Edition, which adds a high availability architecture built on Kafka plus Elasticsearch, Redis, AMQP or GCP Pub/Sub queue backends, along with worker groups. Confirm with Kestra whether your uptime and throughput needs can be met on one server before you plan a multi-node design around the open-source edition.
What the open-source edition leaves to you
Kestra's open-source edition uses basic authentication, manual secret and access management and no audit logging, so your team builds those controls around the server. For Prefect, the server documentation says RBAC, audit logs and SSO sit in Prefect Cloud rather than the self-hosted server. In both cases, write down which identity, secrets and logging controls you will supply yourself before choosing the deployment shape.
Upgrades and client compatibility
Prefect's server documentation states that old clients work with new servers, but new clients can break against old servers because new fields are added to the REST API. That means the server must be upgraded before the workers and clients that depend on it. Kestra 2.0 is a major release with breaking changes and a dedicated migration guide, and it replaces ForEach and ForEachItem with a single Loop task. Plan a staging upgrade for each platform and check flows against the migration notes.
Day-two operations and ownership
Day-two work includes database backups, Redis and load balancer health, server patching and monitoring of the run history. Prefect's Redis and PostgreSQL requirements add components that recur in your on-call scope, while Kestra's single-server model concentrates that work on one host with fewer moving parts. Ask your team who owns each component, how restores are tested and what the upgrade window looks like before committing to either.
Authoring, triggers, identity and audit compared
This table compares how Prefect and Kestra define work, trigger it, and handle identity, audit and secrets in open source versus paid tiers. Read the rows with your team's skills in mind: Prefect flows are written in Python, while Kestra flows are declarative YAML. The main takeaway is that both open-source editions run production work, but SSO, SCIM, RBAC and audit logging sit behind Prefect Cloud or Kestra Enterprise, so identity requirements should drive the choice.
| Capability | Prefect | Kestra |
|---|---|---|
| Authoring model | Python functions turned into flows and tasks, so engineers write logic directly in code | Declarative YAML workflows assembled from plugins, with a YAML editor, a no-code editor and an AI Copilot kept in sync |
| Who can maintain flows | Best suited to teams comfortable writing and testing Python; analysts depend on engineers for changes | Flows can be read and edited by people who know YAML or prefer the no-code editor; confirm how far non-engineers can go in your setup |
| Event-driven triggers | Event-based automations are part of the framework, with events and automations recorded by the self-hosted server | Scheduled and event-driven triggers are listed in the README; confirm which trigger types your sources need |
| Git integration | Confirm current Git-based deployment options against the self-hosted documentation for your workflow | Git version control integration is listed in the README; confirm how it fits your review process |
| Plugin ecosystem | Integrations are built as Python code within your flows rather than a catalog of declarative plugins | Hundreds of built-in plugins for databases, cloud storage and APIs are listed in the README |
| Script language support | Python 3.11 or later is required for Prefect itself; flow logic is written in Python | Scripts can run in any language, according to the README |
| AI and MCP features | Confirm current AI-related features against the Prefect documentation before relying on them | AI agents and RAG workflows are task types, and a built-in MCP server exposes flows to AI agents |
| Basic authentication in open source | Self-hosted server does not include RBAC, audit logs or SSO, per Prefect's server documentation | Open-source edition has basic authentication only, with manual secret and access management |
| RBAC, SSO, SCIM and audit logs | RBAC, audit logs and SSO are Prefect Cloud features; SSO starts at the Team plan and object-level RBAC is on Enterprise | SSO, SCIM, RBAC and audit logs are Kestra Enterprise Edition features; confirm exact tier coverage with Kestra |
| External secrets managers | Confirm secrets handling options for self-hosted Prefect with your security team | HashiCorp Vault and Azure Key Vault integration is listed for Kestra Enterprise Edition |
What is free and what is paid in each platform
Prefect is licensed under the Apache License 2.0, and the framework itself carries scheduling, caching, retries and event-based automations with no license fee. Self-hosting the Prefect server adds an API, a UI and a database that stores flow and task run state, logs, deployments, concurrency limits and events. Your team pays for the infrastructure and the people who run it, and the server carries no paid tier of its own.
- Framework license: Apache-2.0 covers the Python framework, so you can run flows on your own infrastructure without a subscription.
- Self-hosted server: The server runs with SQLite by default and PostgreSQL for production, so the database is a cost you operate.
- Multi-server setups: The documentation calls for PostgreSQL 14.9 or later, Redis for event messaging and a load balancer, all of which you provision and patch.
- Missing controls: The server documentation states that Prefect Cloud provides RBAC, audit logs and SSO, which the self-hosted server does not include.
Before you rely on the open-source server for regulated work, confirm in writing which access controls and audit evidence you must build yourself or source from elsewhere.
Prefect Cloud is the managed service that runs the same workflow model with the administration handled by the vendor. Its pricing page lists a free Hobby plan, a Starter plan at $100 per month, a Team plan at $100 per user per month and a custom-priced Enterprise plan. The price rises with users and the feature set rises with each tier, so the tier you need is set by your access model rather than by flow count.
- Hobby (free): Suited to evaluation and individual use, without the team controls listed below.
- Starter ($100 per month): A paid entry point, with the plan details to confirm on the pricing page.
- Team ($100 per user per month): Adds SSO, which matters once identity must come from your provider.
- Enterprise (custom pricing): Adds object-level RBAC and multiple workspaces, which separate duties across teams and environments.
Ask for a written quote that states the user count, the tier, and whether SSO and object-level RBAC are included in the plan you are buying.
Kestra's open-source edition is licensed under the Apache License 2.0 and is described in its comparison as fully functional for production. You get scheduled and event-driven triggers, Git integration and the built-in plugins, with no license fee. The trade-off is in the controls: the edition offers basic authentication only, a single-server default deployment, manual secret and access management and no audit logging.
- Production use: The edition is described as fully functional for production, so the core workflow engine is not the paid part.
- Authentication: Only basic authentication is included, so identity integration needs the paid edition or your own compensating controls.
- Secrets: Secret and access management is manual in the open-source edition, which you must document and govern yourself.
- Audit trail: Audit logging is absent, so you need an external record of who changed flows and when.
Confirm with Kestra which of these gaps your auditors will accept as compensating controls before choosing the open-source edition.
Kestra Enterprise Edition is the paid edition that adds the controls and scale features listed in Kestra's edition comparison. It is priced by quote, and Kestra's comparison does not give figures in the material supplied here, so the cost must come from a written proposal. Its additions fall into three groups: identity and access, operational isolation and high availability.
- Identity and access: SSO, SCIM and RBAC, plus service accounts and API tokens for automation.
- Secrets and audit: External secrets managers such as HashiCorp Vault and Azure Key Vault, and audit logs.
- Isolation: Multi-tenancy and worker isolation for separating teams and workloads.
- High availability: Kafka with Elasticsearch, Redis, AMQP or GCP Pub/Sub queue backends, worker groups and task runners for Kubernetes and cloud batch services. These backends are operated components with their own upkeep.
Request a quote that lists each enterprise feature by name, the number of users or nodes it covers, and the support terms that apply to the high availability backends.
Where SSO, RBAC and audit controls change the decision
The access controls are where the cost question most often changes the answer. The open-source Kestra edition ships with basic authentication only, a single-server default deployment, manual secret and access management, and no audit logging. Kestra Enterprise Edition adds SSO, SCIM, RBAC, service accounts and API tokens, external secrets managers such as HashiCorp Vault and Azure Key Vault, audit logs, multi-tenancy and worker isolation. If your security baseline requires named individual accountability for who changed a flow or read a secret, the open-source edition does not meet that requirement on its own, and you should budget for Enterprise or build compensating controls yourself.
Prefect separates the same kind of control in a different place. The Prefect server documentation states that RBAC, audit logs and SSO are features of Prefect Cloud that the self-hosted server does not include. Prefect's pricing page places SSO from the Team plan and object-level RBAC and multiple workspaces on Enterprise. A team that self-hosts Prefect for data sovereignty therefore has to decide whether it needs those controls at all, or whether network isolation, reverse-proxy authentication and infrastructure logging can meet its audit obligations. Those compensating controls are your engineering work, not a product feature, and they should be written down before the decision is made.
Before committing, confirm the current contents of each tier directly with the vendor, since plan names, user pricing and included features change. Ask Kestra which controls the Enterprise license covers in your deployment model, and whether secrets integrations and worker isolation are included or add-ons. Ask Prefect whether the Enterprise tier can run in a configuration your security team accepts, and what a self-hosted deployment would lack compared with Cloud. Get those answers in writing and map each one to a control your auditors will ask about. A quote from DeployOpen follows from that written scope, and the scope should name which controls are in and which are out.
What drives the running cost of each platform
Running either platform costs more than its license line. The cost comes from the infrastructure behind it, the skills needed to author and maintain flows, the paid tier that unlocks access control and audit features, and the work of keeping each version current. Read each card to see which costs are one-time and which recur, and what to request in a written quote.
Prefect multi-server infrastructure
A multi-server Prefect deployment needs PostgreSQL 14.9 or later, Redis for event messaging and a load balancer in front of the API. Each of these is a service your team patches, backs up, monitors and pays to host, and they recur every month whether or not flows run. Single-server SQLite is the default, but it is not a production database choice. Ask for the hosting, backup and failover model for each component in your quote.
Kestra single-server footprint
The open-source Kestra edition defaults to a single-server deployment, so its baseline infrastructure is smaller at the start. The cost shift comes when you need high availability, because Kestra Enterprise adds Kafka with Elasticsearch, Redis, AMQP or GCP Pub/Sub queue backends and worker groups. Confirm with Kestra which of these components your target load requires, and whether they are licensed, hosted or self-operated.
Secrets handling in Kestra
The open-source Kestra edition leaves secret and access management to you, so credentials are handled by your own process. Kestra Enterprise adds external secrets managers such as HashiCorp Vault and Azure Key Vault. If you adopt Vault or Key Vault for Kestra, the cost includes running that secrets service and the access reviews it needs. Ask the vendor whether these integrations are included in the subscription you quote.
Python skills versus YAML and plugins
Prefect flows are Python functions, so Python engineers can author and debug them with the tools they already use. Kestra workflows are declarative YAML built from plugins, which lets analysts and operators maintain flows, but plugin choice, plugin upgrades and custom scripts in other languages still need engineering time. Estimate the cost by counting who will own flows after launch, not only who builds the first ones.
Prefect Cloud Team subscription per user
Prefect Cloud Team is priced per user per month, and SSO is included from that tier. The recurring cost grows with every operator who needs a seat, so a larger on-call or analyst group raises the bill directly. Object-level RBAC and multiple workspaces sit on Enterprise at custom pricing. Ask for the per-user rate, the seat count you are assuming, and which features are included at each tier.
Kestra Enterprise licensing and upgrades
Kestra Enterprise is a separate commercial edition that adds SSO, SCIM, RBAC, audit logs and high availability, so its license is a recurring cost on top of the open-source base. The open-source 2.0 line also brings breaking changes, including replacing ForEach and ForEachItem with a single Loop task, which means flow rewrites and testing. Request the license terms, the upgrade support window and the migration effort in writing.
Upgrades and version currency on both sides
Prefect server upgrades must keep old clients working with new servers, and new clients can break against old servers when fields are added to the REST API. Plan a coordinated upgrade of workers, clients and server, and budget time for it each release cycle. Ask your implementer whether upgrades, rollback testing and the Prefect 3 and 2 version policy are included in a retainer or charged separately.
Moving flows from Prefect to Kestra, or back
This sequence turns a Python-first Prefect estate into a YAML-first Kestra one (or the reverse) without a hard cutover risk. Each step ends with a check you can verify before the next one begins.
Inventory flows, schedules and dependencies
Your data engineers list every Prefect flow, deployment, schedule, work pool and the external systems each flow touches, such as databases, object storage and APIs. Record which flows are triggered by events and which run on a clock, because triggers are the part most often missed. The step is done when you have a single inventory that a second engineer has reviewed against the live Prefect server and found complete.
Map Python tasks to Kestra plugins or scripts
For each Prefect task, decide whether a built-in Kestra plugin for databases, cloud storage or APIs covers it, or whether the logic should run as a script task in the language it already uses. Kestra's README describes running scripts in any language, but the fit of each plugin to your sources must be confirmed against the plugin documentation for your version. Flag any flow that relies on Python-only libraries or in-process state, since those need a deliberate redesign. The step closes with a mapping sheet that lists each flow, its target Kestra construct and the owner who signed off.
Rebuild triggers and automations
Recreate scheduled and event-driven triggers in Kestra's declarative YAML, then confirm each one fires on the same inputs as its Prefect counterpart. Prefect's event-based automations and Kestra's event triggers do not map one to one, so test each event path with a controlled input instead of assuming parity. The step is done when every trigger in the inventory has a recorded test run that fired at the expected time or on the expected event.
Move secrets, connections and access
Move credentials out of Prefect blocks and variables into the secrets store you will use in Kestra. In the open-source Kestra edition, secret and access management is manual, so decide who holds those values and how rotation works. If you need external secrets managers, SSO, SCIM, RBAC, audit logs or multi-tenancy, confirm with Kestra which edition provides them, because those features are listed under Kestra Enterprise Edition. The step closes when every connection resolves in a test flow and the access model has been reviewed by your security team.
Export or accept run history separately
Code and flow definitions transfer through your version control, and your data stores remain where they are. Run history does not move automatically between the two platforms, so decide whether to keep historical runs in a read-only Prefect server for audit purposes or export them to your own log store. Ask Prefect and Kestra what export paths their current versions support before you commit to a retention plan. The step is done when the retention decision is written down and your auditors have confirmed it meets their evidence needs.
Manage client and server versions during the move
Prefect's server documentation says older clients work with newer servers, but newer clients can break against older servers as fields are added to the REST API. Pin the Prefect client and server versions you run during the overlap, and upgrade the server before its clients whenever you change either side. Keep Kestra on its own pinned release line, since Kestra 2.0 carries breaking changes and a dedicated migration guide. The step closes with a version matrix that every worker and CI runner uses.
Run both platforms in parallel
Run each migrated flow on Kestra alongside its Prefect original, comparing outputs, timings and failure behavior against the same source data. Keep the Prefect schedule active for flows you have not yet cut over, and disable duplicate writes to shared targets so two platforms never load the same data twice. The step is done when each flow has matching outputs across an agreed number of runs, with the number set by your data owners rather than by this guide.
Cut over and decommission in order
Switch each flow's schedule and triggers to Kestra one group at a time, starting with the flows that have the fewest downstream dependencies. Disable the Prefect deployment rather than deleting it, so you can roll back quickly if an issue appears. Decommission the Prefect server only after every flow has run cleanly on Kestra and the retention decision from the export step is in effect. The sequence is complete when the Prefect inventory shows zero active deployments and the cutover record is signed off by the platform owner.
Where implementation projects run long
The longest implementations on this comparison usually stall in setup decisions made before the first flow runs. For a multi-server Prefect self-hosted deployment, the server needs PostgreSQL 14.9 or later, Redis for event messaging and a load balancer in front of the API, and each of those is a separate build, backup and patching item for your platform team. Confirm who owns the PostgreSQL instance, who approves the Redis topology and whether your standard load balancer can serve the Prefect API and UI. Work pools and workers are the other common delay: each work pool needs a worker that can reach your execution environment, and the team must decide which pools map to which network zones before deployments are written. Also confirm which Prefect server version and which client version each team will run, because the server documentation warns that new clients can be incompatible with old servers.
On the Kestra side, the largest schedule risk is version selection. Kestra 2.0 is a major release with breaking changes, and the migration guide replaces ForEach and ForEachItem with a single Loop task. Any team with flows written against the 1.3 line must inventory those tasks, rewrite them, and retest them before upgrading, so ask whether your existing flows are on 1.x and who will own the rewrite. Secrets and access are the other overrun point. The open-source edition has basic authentication only, manual secret and access management and no audit logging, so you must decide how credentials are stored and rotated and who can edit flows. If those controls are required, the scope must name SSO, RBAC and audit logging as Enterprise Edition items, with a written decision on whether they are in scope.
Across both platforms, the inputs you supply drive the schedule more than the software does. Name a single owner for each flow domain and an owner for each environment, including who approves production changes. Provide the identity provider details, such as the SAML or OIDC metadata and group mappings, before SSO work begins. Provide representative test data and a sandbox that matches production connectivity, because flows that pass against mock endpoints often fail at the first real database or API call. Ask DeployOpen to write these inputs into the fixed scope and to name the acceptance tests for each environment, so that open items are visible before work starts.
Questions buyers ask before choosing Prefect or Kestra
What drives the cost of running Prefect or Kestra yourself?
The software licenses are not the main cost for either platform, since Prefect and Kestra open-source editions are both Apache-2.0 licensed. The cost comes from the people and infrastructure around them: engineers who write and maintain flows, a PostgreSQL database for production state, and a team that runs upgrades, backups and monitoring. For Prefect, the self-hosted server needs PostgreSQL for production and Redis plus a load balancer for multi-server setups. For Kestra, the open-source edition runs as a single server by default, so the infrastructure footprint is smaller until you need high availability. Paid costs appear only if you need features reserved for Prefect Cloud or Kestra Enterprise. Ask any vendor or partner for a quote that separates one-time build work from recurring support, upgrades and infrastructure.
How long does a self-hosted Prefect or Kestra rollout take?
No supplied fact gives a duration for either rollout, so treat any number you hear as unverified until it is tied to a written scope. The main variables are the number of flows you need to migrate or write, the number of data sources and plugins involved, whether you run a single server or a multi-server setup, and how many approval and security reviews sit in your change process. A Prefect rollout that needs PostgreSQL, Redis and a load balancer will involve more infrastructure work than a single-server Kestra open-source deployment. Ask for a timeline that lists each milestone, the systems it touches and the people who must sign off. DeployOpen plans and implements these rollouts on fixed scopes agreed in writing before work starts.
Can an in-house team run Prefect or Kestra without outside help?
Yes, many teams run either platform in house, but the answer depends on skills you already have. A team comfortable with Python and PostgreSQL can usually operate a Prefect server, since flows are ordinary Python functions and the server state lives in a database your team already knows how to back up. A team that already writes infrastructure configuration can usually operate Kestra, since its workflows are declarative YAML. The harder questions are operational: who patches the server, who owns Redis and the load balancer in a multi-server Prefect setup, who manages secrets and access in the open-source Kestra edition, and who answers the audit questions that the open-source edition does not cover. Assign those owners before you choose a platform.
What skills do engineers need to build flows on each platform?
Prefect asks engineers to write Python. The README states Prefect requires Python 3.11 or later, and flows are Python functions with scheduling, caching, retries and event-based automations. Kestra asks engineers to write declarative YAML built from plugins, and its editor set includes a YAML editor, a no-code editor and an AI Copilot that stay in sync. That makes Kestra easier for people who are not developers to read and edit, but complex logic still needs someone who understands the plugins and the task types. Check which group of people will maintain flows after launch, then test one representative workflow with each authoring model before you decide.
Do I need Prefect Cloud or Kestra Enterprise for SSO and audit logs?
Yes, for both platforms the features you listed are paid. The Prefect server documentation says Prefect Cloud provides RBAC, audit logs and SSO that the self-hosted server does not include. Prefect's pricing page lists SSO from the Team plan and object-level RBAC with multiple workspaces on Enterprise. Kestra's edition comparison says the open-source edition has basic authentication only and no audit logging, and that Kestra Enterprise Edition adds SSO, SCIM, RBAC, audit logs and external secrets managers. The practical difference is where the feature runs: Prefect Cloud is a hosted service, while Kestra Enterprise is a self-hosted commercial edition. Confirm current plan contents with each vendor, since they change.
How hard is it to switch from Prefect to Kestra later, or back?
Switching is a rewrite, not a configuration change. Prefect flows are Python code, and Kestra workflows are YAML definitions that call plugins, so no flow file carries over directly. Plan the migration as a list of workflows, with each one mapped to a trigger, its inputs and outputs, its secrets and its downstream consumers. Run old and new in parallel for a period, then retire the old one. Prefect's server documentation notes that new clients can be incompatible with old servers as fields are added to the REST API, so keep client and server versions aligned during the move. Kestra 2.0 is a major release with breaking changes, and its migration guide replaces ForEach and ForEachItem with a single Loop task, so check version targets before you commit. Ask any implementation partner to price the migration from a written inventory of flows.
Which platform needs more upgrade work to stay supported?
Both platforms need regular upgrades, and the work differs in shape. Prefect 3.8.8 was released on October 6, 2026, after 3.8.7 on September 26, 2026, and the 2.x line still received 2.20.26 on September 2, 2026, so plan which line your flows run on and when you move. Kestra v2.0.6 was published on October 13, 2026, while the 1.3 line continued receiving patch releases, so a 1.3 installation needs a deliberate decision about moving to 2.0. The 2.0 breaking changes make that move a project in its own right. Ask each vendor for its support window for the line you intend to run, and budget upgrade testing against your own flows, not against release notes.
What does DeployOpen do for an implementation of either platform?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Prefect or Kestra, that can include standing up the server and database, connecting identity and secrets, building and migrating flows, documenting operating procedures and agreeing a support plan. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
How DeployOpen helps you choose and run either platform
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. We help teams choose between Prefect and Kestra, implement either one, or move flows from one to the other, and we do not favor either platform. The most useful first step is a written scope that states which features your controls require. That answer decides the design: if you need SSO, RBAC or audit logs, you must price Prefect Cloud or Kestra Enterprise Edition, and if you do not, the open-source server may cover the job.
Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. For this pair, a typical scope lists the metadata database, the server topology, authentication, secrets handling, backup and restore, and the upgrade path. For Prefect, multi-server setups need PostgreSQL 14.9 or later, Redis for event messaging and a load balancer, as described in the self-hosted Prefect documentation. Ongoing upgrades, patch review and continuous testing can run under a retainer. DeployOpen does not publish a price list. A quote follows from the written scope, so ask that it separate one-time build work from recurring support and name who operates the platform after handover.
Before you sign anything, confirm the facts that drive the design with the vendors and inside your own environment. Check which Prefect Cloud plan or Kestra Enterprise Edition features your controls need, how many engineers will write flows in Python compared with how many will maintain YAML, and whether your network allows the components each platform needs. Then run one representative flow end to end in your environment, including a failure and a retry, and record what your operators had to do. Those results give you a defensible basis for the choice, and they become the acceptance criteria for any implementation work that follows.
