Kestra is a YAML-based AI data processing workflow orchestration platform that adopts event-driven and infrastructure-as-code paradigms to support data pipelines and automated processes.

kestra

Core parameters and statistics

Kestra is positioned as an "open source orchestration platform for data AI and infrastructure workflows". The core difference lies in the introduction of the concept of infrastructure as code into workflow orchestration - all workflow definitions are YAML declarative configurations that can be incorporated into Git version control and released through CI/CD pipelines. This is a clear distinction from Prefect/Dagster’s Python native style and Airflow’s Python DAG.

Parameters	Public information
Product positioning	Open source, event-driven workflow orchestration platform (data/AI/infrastructure)
Core form	YAML declarative DSL + Web UI (visual topology editor) + API + Terraform Provider
Target Users	Data Engineer DevOps, Platform Engineer SRE
Core technology	Java engine + YAML DSL + pluggable plug-in architecture + event-driven scheduler
License Agreement	Apache 2.0 (Open Source), Enterprise Edition Proprietary License
Deployment methods	Docker / Docker Compose / Kubernetes / AWS CloudFormation / GCP Terraform
Code language	Java 65%, TypeScript 17%, Vue 16% (core engine + front end + UI)
GitHub Stars	27.4k
GitHub Forks	2.7k
Contributors	469
Total number of releases	473+ Releases
Plug-in ecology	1800+ plug-ins
Workflow Templates	480+ Blueprints
Latest version	v1.3.28 (2026-07-15)
Corporate Clients	JPMorgan Chase, Bloomberg, Xiaomi, Apple, Fila, etc.

Version Maintenance Strategy: Kestra maintains three release lines at the same time - mainline v1.3.x (latest features), stable line v1.0.x (LTS style), and compatibility line v0.22.x (legacy user transition). All three lines maintain high-frequency bug fixes in sync, reducing the pressure on production companies to follow the main line.

Significance of ecological scale: 1800+ plug-ins mean that Kestra has covered mainstream cloud services and data tools such as AWS, GCP, Azure, Snowflake, BigQuery, Kafka, dbt, Airbyte, Slack, PagerDuty, etc. Most data pipeline scenarios do not require writing connection code from scratch.

Kestra’s users and market recognition

Kestra's market validation mainly comes from two dimensions: the continued growth of the open source community and production-level adoption by leading companies.

Community Popularity: GitHub 27.4k Stars and 469 contributors indicate that the project has passed the early verification stage and formed a stable external contribution ecosystem. 473+ releases and daily active commit records (there are still code submissions on 2026-07-18) reflect that the project maintenance intensity is at a high level.

Enterprise-level adoption: Customer cases disclosed on the official website include leading cross-industry companies such as JPMorgan Chase, Bloomberg, Xiaomi, Amdocs, Fila, Apple, and T-System. Taking JPMorgan Chase as an example, the official case shows that it "processed billions of rows of data and thousands of weekly API calls in less than 3 months, so analysts no longer need to wait for the engineering team to build their own workflows." Although the number of such cases is limited, the industry influence of a single case is enough to prove that Kestra has passed the verification under strict compliance conditions.

Industry coverage: Judging from the customer logo displayed on the official website, Kestra covers multiple industries such as finance (JPMorgan), telecommunications (Amdocs, T-System), consumer goods (Fila, Xiaomi), technology (Apple, Bloomberg), etc., and is not limited to a single field of data engineering.

Prerequisites for implementation: The release of the value of platform-based workflow orchestration tools within an organization usually requires two prerequisites - the team has precipitated standardizable cross-system processes (data pipelines, infrastructure changes, business approvals), and the IT department has the willingness to manage multiple orchestration domains. If the team is small and the process is still manual, Kestra may not be as beneficial as starting with a simple script or SaaS automation tool.

Kestra’s Cost Advantage

Kestra's cost structure is not a "cheap" one-dimensional narrative, but leaves room for organizations of different sizes to "verify first and then upgrade" through three paths: open source free, enterprise version value-added, and cloud hosting.

C-side/open source version: zero license fee, self-hosting cost: Apache 2.0 license, core engine Web UI and basic plug-ins are completely free. It can be started with a single command through Docker (docker run kestra/kestra:latest server local), and individual developers or small teams can obtain complete orchestration capabilities in a few minutes. The actual cost mainly comes from infrastructure - running Kestra requires at least one Docker-enabled server (minimum 2C4G), plus the cost of back-end database (PostgreSQL or MySQL) and object storage (S3/GCS/MinIO). Based on the monthly fee of a lightweight cloud server of about 200-500 yuan, the annual infrastructure cost is about 2400-6000 yuan, which is far lower than the subscription fee of the same specifications of commercial orchestration tools.

Enterprise Edition: Advanced governance requires business confirmation: The Enterprise Edition includes SSO/LDAP, RBAC, audit logs, multi-tenancy, isolated worker nodes, dedicated Task Runner, SLA support and other capabilities. Pricing is not disclosed, please contact sales for a quote. The purchase entrance displayed on the official website is "Book a Demo" and there is no public price page.

Cloud hosting version: The fastest paid path to get started: Kestra Cloud is a hosted SaaS form, eliminating the burden of self-operation and maintenance infrastructure. Pricing has not been disclosed, and the entrance is the "Request Access" waiting list mode, indicating that the product has not yet been launched on a large scale.

Cost comparison with competing products:

Cost dimension	Kestra (open source self-hosted)	Airflow (open source self-hosted)	Prefect Cloud	Temporal Cloud
License fee	0 (Apache 2.0)	0 (Apache 2.0)	There is a free quota, and the payment is based on the execution volume	There is a free quota, and the payment is based on the workflow
Infrastructure baseline	2C4G server + DB	Requires multiple components (Scheduler, Worker, DB, Redis)	Hosting, no operation and maintenance	Hosting, no operation and maintenance
Learning Curve	YAML Declarative (Low)	Python DAG (Medium)	Python SDK (Medium)	Go/Java SDK (High)
Enterprise Edition SSO/RBAC	Requires Enterprise Edition (pricing not disclosed)	Requires Astronomer or build your own	Included in Premium Package	Included in Enterprise Edition
Operation and maintenance complexity	Medium (a single container can be started)	High (multi-component collaboration)	Low (managed)	Low (managed)

Hidden Cost: Kestra's reliance on databases and storage means that database connection pool pressure and storage charges increase linearly as the number of workflows and frequency of execution increases. Although the plug-in ecosystem is rich, the development and maintenance costs of self-developed plug-ins are not included. For in-depth customization requirements, the learning threshold of Java plug-in SDK is higher than that of Python.

Kestra’s main features

Kestra's functional design revolves around the four main lines of "declarative orchestration + event-driven + multi-language execution + AI native". Instead of hard-coding the process into a script, Kestra provides an orchestration layer that can be incorporated into the existing infrastructure governance system.

• YAML declarative workflow (Flow as Code): Each workflow (Flow) is defined by a YAML file, including top-level fields such as id, namespace, tasks, and triggers. YAML files can be directly stored in the Git repository, and changes will be automatically synchronized to the Kestra instance after they pass Pull Request review. This approach aligns naturally with DevOps teams’ GitOps workflows—there’s no need to maintain a separate set of orchestration configuration management tools. Implementation Tips: YAML declarative style is extremely clear in simple linear processes, but when the process contains a large number of conditional branches, dynamic task generation, or cross-Flow calls, the verbosity of YAML will increase significantly. In this case, it is recommended to use Subflows and template mechanisms to reuse common logic.

• 1800+ plug-in ecosystem: covering databases (JDBC, MongoDB, Elasticsearch), cloud services (S3, GCS, Blob), message queues (Kafka, RabbitMQ, Pulsar), data processing (dbt, Airbyte, Spark, Python Script), notifications (Slack, Email, PagerDuty), AI (Gemini, Anthropic), etc. The core value of plugins is "declarative invocation" - specifying the type field in YAML and using it without having to write glue code for each integration. Plug-ins can also be developed by yourself using the Java SDK and published as independent JAR packages to be mounted on the Kestra instance.

• Event-driven and scheduled triggering: Supports multiple trigger modes such as cron expressions (scheduled scheduling), Webhooks (triggered by external system callbacks), message queue monitoring (triggered by Kafka/RabbitMQ/Pulsar messages), and file events (triggered by S3/GCS new files). Being event-driven means that the pipeline does not need to poll and wait - when new data arrives or external state changes, Kestra automatically triggers the corresponding process.

• Visual topology editor and monitoring: The Web UI provides a DAG topology view, and the task dependencies of the workflow are graphically presented. Supports dragging and dropping directly from the UI to adjust task order, manually trigger processes, and view execution logs and running indicators (time consumption, status, input and output). UI modifications to YAML will be automatically synchronized back to the file definition, maintaining "two-way synchronization between code and UI".

• Task Runner and multi-language script execution: Through the Task Runner mechanism, tasks in the workflow can be executed in local Docker containers, remote servers (SSH), Kubernetes clusters, or Serverless containers. Supports Python, Node.js, Go, R, Shell, Bash and other language scripts, without refactoring business logic into Java. Implementation Tips: Task Runner configuration (network, storage mount, contextual variables) directly affects the script execution success rate. It is recommended to test the behavior in the isolated execution scenario in the pilot stage.

• AI Agent and Kestra AI Assistant: Kestra has a built-in AI Agent plug-in (io.kestra.plugin.ai.agent.AIAgent), which can embed LLM inference nodes in the workflow. The official website also provides the Kestra AI chat assistant. Users can describe their needs through natural language, and the AI ​​will generate the corresponding YAML workflow definition. The Blueprints library provides 480+ pre-made templates covering common scenarios such as AI data pipelines, infrastructure automation, business approvals, and more.

Functional synergy: YAML declarative + plug-in ecology + event triggering are related - the data engineer only needs to declare "When a new S3 file arrives, use dbt to convert the data and write it to Snowflake, and send a Slack notification when completed." Kestra is responsible for the full-link execution of scheduling, retrying, and monitoring. The addition of AI Agent nodes further lowers the threshold for "embedding LLM inference into the production process".

Kestra’s model and version evolution

Kestra's version iteration follows the strategy of "high-frequency release of the mainline + parallel maintenance of multiple stable lines". Judging from the public Release history, the project entered the intensive iteration stage of the v1.3.x cycle in 2026, and predicted a major architectural reconstruction of v2.0.

Main release line (v1.3.x)

Version	Release Date	Key Changes
v1.3.28	2026-07-15	Latest version; fix Windows drive letter case MySQL Flyway migration conflict DAG cycle detection optimization, security fix (SQL injection jq string escape)
v1.3.27	2026-07-04	Added CLI sys purge-queue command, document generation support; fixed Kanban CSV export, task runner 63 character limit BasicAuth constant time comparison
v1.3.26	2026-06-27	Dynamically generate log attachment and nested UI display for task running; fix exponential backoff retry delay exception, empty/null sorting exception
v1.3.25	2026-06-27	PluginDefault supports references; fixes the retry backoff algorithm, suspended task status processing, and storage authorization error codes
v1.3.0	~2026-Q2	Introducing AI Agent plug-in Blueprints library, namespace file management, and pluggable queue architecture foundation

Stable line and compatible line

• v1.0.x series: LTS style maintenance line, synchronous mainline bug fixes, suitable for production environments that are sensitive to the rhythm of feature updates. Latest v1.0.51 (2026-07-15).
• v0.22.x Series: Legacy compatibility line, critical fixes released only when necessary. The latest v0.22.46 (2026-07-15) mainly fixes the Docker VOLUME output download skipping problem.

v2.0 trailer

Kestra has officially launched the v2.0 Early Adopter Program, claiming that v2.0 will bring "re-architected core engine, pluggable queue/database/worker node". Judging from the current trend of feature accumulation and architectural component splitting in v1.3.x, v2.0 is likely to have a major improvement in scalability, multi-cluster support and governance capabilities. Enterprises should focus on backward compatibility strategies for v2.0 and current releases when evaluating.

Kestra’s technical advantages

Kestra's technical advantage lies not in the performance of a single model, but in the four-layer architecture integration of "declarative orchestration + event-driven + multi-language execution + enterprise governance".

Declarative Flow as Code engine: YAML is used as a first-class citizen of workflow definition, and all process changes (UI drag and drop API call CI/CD push) are ultimately reflected as modifications to YAML files. This design ensures that the orchestration logic is always version controllable, code reviewable, and rollable. The essential difference from the Python DAG (Airflow/Prefect) approach is that YAML is purely declarative and does not contain execution logic, so different teams can collaborate to review process changes through Pull Requests without having to worry about code injection or hidden side effects.

Event-driven scheduler: Kestra's scheduler handles both timing (cron) and event-driven (Webhook, message queue, file events) modes. In event-driven mode, Kestra triggers workflows by listening to status changes in external systems, avoiding delays and resource waste caused by polling. The scheduler uses JDBC persistent queues to support disconnection reconnection and idempotent triggering - which is directly reflected in less data loss and repeated execution in production environments.

Pluggable Task Runner Architecture: Each task in the workflow can choose a different execution context - local process, Docker container, SSH, remote server, Kubernetes Job or Serverless container. This "task-level execution isolation" design allows different tasks in the same workflow to run in heterogeneous contexts (for example: Python scripts are executed on dedicated GPU nodes, SQL queries are executed on the database side, notification calls are handled by lightweight containers) without the need to fix a single execution context for the entire workflow.

Enterprise governance capabilities: The enterprise version provides capabilities such as namespace isolation RBAC, audit logs, multi-tenancy, and dedicated working nodes. Namespace isolation means that the workflows of different teams are completely logically separated - configuration, permissions, and execution are bounded and do not interfere with each other. Audit logs record all API operations and process execution changes to meet compliance audit requirements such as SOC 2.

Architecture Link: A typical location for Kestra in a production deployment is as follows:

External trigger (cron/Webhook/Kafka/S3 events)
    ↓
Kestra Web UI/API/CLI
    ↓
Kestra orchestration engine (Flow analysis → task queue → scheduling execution)
    ↓
Plug-in layer (1800+ built-in plug-ins) ← → Task Runner (Docker/SSH/K8s/Serverless)
    ↓
External systems (DB/cloud services/SaaS/message queues/data tools)
    ↓
Output/Notification → Slack/Email/PagerDuty + Internal Storage

Guide to engineering pitfalls:

1. Database connection pool and queue backlog: Kestra relies on the backend database (default H2, recommended for production PostgreSQL) to store execution queue and status. When workflows are executed very frequently (hundreds of triggers per second), the JDBC queue can become a bottleneck. Solution: Use PostgreSQL and monitor the connection pool water level; for ultra-high throughput scenarios, pay attention to whether the v2.0 pluggable queue architecture introduces high-performance queue backends such as Kafka/Pulsar.
2. Plug-in version compatibility: The version dependencies between the Kestra core engine and the plug-in need to be strictly matched. Failure to upgrade the plug-in simultaneously when upgrading the core may result in runtime exceptions such as NoClassDefFoundError. Solution: Establish a process of "upgrade the staging context first, verify plug-in compatibility before pushing to production"; lock the plug-in version instead of using the latest tag.
3. Boundary case of DAG loop detection: Kestra uses the DAG (directed and graph) model to ensure that the workflow has no loop and dependencies. However, the repair record of v1.3.26 shows that when the task ID is repeated or Subflow is nested to form an implicit loop, the detection algorithm may fail. Solution: Avoid dynamically generating duplicate task IDs; add manual topology review in complex cross-Flow call scenarios.

How to use Kestra

Kestra provides both self-hosted and cloud-hosted entrances, and the path from zero startup to production deployment covers teams of different sizes.

How to use	Suitable for the crowd	Features	Cost
Docker single instance	Individual developer, quick verification	Start with one command, built-in H2 database	Infrastructure cost only
Docker Compose	Small team trial production	Comes with PostgreSQL + MinIO, suitable for local development and CI	Infrastructure + operation and maintenance
Kubernetes Helm	Large-scale production deployment	Horizontal expansion, high availability, multiple workers	Infrastructure + operation and maintenance
AWS CloudFormation	AWS users	One-click deployment to EC2 + RDS + S3	Per AWS resource billing
GCP Terraform	GCP User	Managed deployment, auto-configuration Cloud SQL + GCS	Per-GCP resource billing
Kestra Cloud (Hosted)	Free operation and maintenance team	Waiting list model, not yet available on a large scale	Pricing not disclosed

Get started quickly in 3 minutes (stand-alone Docker startup):

# Pull and start Kestra (embedded H2 database)
docker run --pull=always -it -p 8080:8080 --user=root \
  --name kestra --restart=always \
  -v kestra_data:/app/storage \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /tmp:/tmp \
  kestra/kestra:latest server local

After startup, visit http://localhost:8080 to enter the Web UI.

First Hello World Workflow: Create a new Flow in the UI, paste the following YAML and execute:

id: hello_world
namespace: dev
tasks:
  - id: say_hello

    type: io.kestra.plugin.core.log.Log
    message: "Hello, World!"

Production deployment considerations:

• Always switch backend database to PostgreSQL (H2 for development validation only)
• Configure external object storage (S3/MinIO/GCS) to persist workflow execution products
• Use shared database and storage backend when deploying multiple workers, each worker needs to access the same storage
• Incorporate YAML workflow files into Git repository and push changes to Kestra API via CI/CD

Kestra’s Product Pricing

Kestra's pricing system covers the three-tier path of "open source self-hosting → enterprise version → cloud hosting". Organizations of different sizes can choose the corresponding model based on governance needs and operation and maintenance capabilities.

Open Source Community Edition (Open Source): Apache 2.0 license, completely free. Contains the core orchestration engine Web UI, all basic plug-ins, and 480+ Blueprints templates. There are no limits on functionality—any number of workflows, tasks, and executions can be orchestrated. The cost is only from self-hosted infrastructure (servers, databases, storage).

Enterprise Edition: For organizations with clear requirements for security governance. Includes SSO/LDAP, RBAC, audit logs, multi-tenancy, isolated worker nodes, dedicated Task Runner, hybrid cloud/local/air-gapped support SLA guarantees and dedicated customer success services. Pricing has not been disclosed, and the official website only displays "Learn More" and "Book a Demo".

Cloud Hosting Edition (Cloud): Hosted SaaS form, with the infrastructure operated and maintained by the Kestra team. Currently on a waiting list, pricing is undisclosed.

Key acceptance concerns:

• In the enterprise version pricing model, whether billing is based on workflow execution volume or number of nodes/seats requires business confirmation.
• There is no official SLA for the self-hosted version, and production failures rely on the community and internal operation and maintenance capabilities.
• The data storage location and compliance certification (SOC 2/GDPR) terms of the cloud hosting version must be specified in the contract

Application scenarios of Kestra

Kestra's implementation scenarios cover three core areas: data pipelines, infrastructure automation and AI workflow. The official website has marked quantitative revenue indicators respectively.

• Cloud Data Pipeline (ETL/ELT): Read raw data from S3/GCS, load it to Snowflake/BigQuery after conversion by dbt/Airbyte/Spark, and trigger Slack notification or PagerDuty alarm after completion. The official website states that "pipeline delivery speed is increased by 10 times and manual backfilling is reduced by 90%." Implementation Tips: In the data pipeline scenario, it is recommended to first select a medium-complexity pipeline (3-5 tasks, including data reading, conversion, loading, and notification) as a pilot, focusing on verifying whether the event triggering reliability, retry strategy, and error handling logic meet operation and maintenance expectations.

• Infra as Code: Standardize Terraform/Ansible to perform CI/CD pipeline orchestration, hybrid cloud/air-gapped operation and maintenance processes. The official website states that "Infrastructure delivery speed is increased by 6 times, and legacy tool costs are reduced by 90%." Typical scenarios include: scheduled database backup, automatic start and stop of development/testing environments, automatic renewal of certificates upon expiration, and automatic generation of security audit reports. Implementation Tips: Infrastructure scenarios have extremely high requirements on the idempotence and rollback capabilities of operations. It is recommended that all change operations be verified in dry-run mode first, and the actual changes are allowed to be executed only after confirmation.

• AI workflow orchestration: Incorporate the LLM inference RAG pipeline and model evaluation AI Agent into formal orchestration governance. Kestra's AI Agent plug-in can directly call large models in the workflow and combine with Python Script nodes to complete data pre-processing and post-processing. The official website states that "Pipeline maintenance volume is reduced by 50 times, and AI delivery cycle is accelerated by 3 times." Implementation Tips: The output of the AI ​​node is uncertain. It is recommended to add a manual review node after the AI ​​task (such as sending an approval notice and waiting for confirmation), forming a cycle of "AI suggestion → manual confirmation → execution".

• Microservice orchestration and cross-system business processes: Arrange cross-service processes such as order processing, payment confirmation, and logistics tracking in the microservice architecture. Kestra's YAML declarative style is naturally suitable for docking with microservice infrastructure as code processes, but please note: for high-frequency, low-latency request-response orchestration (such as instant routing at the API gateway level), Kestra's event-driven model will generate additional scheduling delays and is more suitable for business processes above the minute level.

Applicable groups of Kestra

Kestra's multi-tier deployment model and declarative orchestration concept serve four types of roles, each with different entry points and value expressions:

• Data Engineer: Replace traditional Python glue scripts with YAML declarative ETL pipelines, reducing the writing and maintenance of connection code. 1800+ plug-ins cover mainstream data sources and targets, and common data pipeline scenarios do not need to be developed from scratch. Not suitable for boundaries: If the team mainly conducts exploratory data analysis in notebooks, Kestra's formal orchestration model will increase unnecessary process solidification costs.

• DevOps/Platform Engineer: Incorporate infrastructure automation (backup, scaling, compliance scanning) into Git version control and management, and push workflow changes through CI/CD pipelines. Enterprise Edition's RBAC and audit logs meet platform governance needs. Not suitable for boundaries: If the team only has one Kubernetes cluster and the automation requirements are simple (no more than 5 pipelines), directly using CronJob + Shell script may be more lightweight than introducing Kestra.

• SRE/Operation and Maintenance Engineer: Use event-driven triggers and alarm notification links to build automated fault response and recovery processes. Kestra's retry, timeout, and error handling mechanisms can reduce manual inspection workload. Prerequisites for implementation: It is necessary to sort out the existing fault response process (which alarm triggers which recovery action), and confirm the idempotence of each recovery action.

• Business Analyst/Data Operations: With Kestra’s Blueprints template library and AI assistant, non-R&D roles can be somewhat oriented towards the template creation process. Unfit Boundary: For processes that require complex conditional branching, custom logic processing, or deep system integration, developers still need to step in and write YAML or plug-in code.

Summary and Outlook of Kestra

Kestra has established a unique product positioning on the "YAML declarative orchestration" track - not the most flexible orchestration tool (compared to Prefect/Dagster's Python native), nor the lightest scheduling tool (compared to CronJob), but an industrialized solution for "medium- and large-scale organizations that need to incorporate orchestration into their infrastructure governance systems."

Core Advantages: The out-of-box integration capabilities brought by 1800+ plug-ins reduce glue code; the declarative process management of YAML + Git + CI/CD is naturally aligned with the DevOps culture; the event-driven + timed trigger dual mode covers most pipeline startup scenarios; 27.4k GitHub Stars and enterprise customers have verified community activity and production availability; the architecture reconstruction announced in v2.0 shows that the project is still actively evolving.

Current Limitations:

• YAML declarative is more verbose than the Python DAG solution in complex conditional branching and dynamic task generation scenarios, and maintenance costs increase super-linearly with the complexity of the process.
• The resource baseline of the Java core engine is higher than similar tools in Go/Rust, and the "cost-effectiveness" in lightweight scenarios is not as good as alternatives.
• Enterprise and cloud hosting pricing is not disclosed, and purchasing decisions lack price transparency
• Chinese documents and Chinese communities are relatively limited, and technical support for domestic users mainly relies on English GitHub Issues and Slack
• The backward compatibility strategy for v2.0 has not yet been clarified, and current large-scale deployments of v1.3.x may face upgrade risks

Follow-up observation points: Whether v2.0 can realize the architectural promise of "pluggable queue/database/worker" after its official release; whether the enterprise version will launch a public pricing page to improve procurement transparency; whether the AI Agent plug-in and Blueprints library can form a user-grown template ecosystem; whether the localized operation of the Chinese community will be strengthened.

Procurement and Adoption Risk Assessment: For organizations with existing DevOps and data engineering teams, it is recommended to conduct a 4-6 week small-scale pilot in non-critical processes (internal report generation, development context automation, low-risk data pipelines), focusing on verifying whether the maintenance efficiency of YAML declarative workflow meets the team's expectations. After the pilot is passed, it will be gradually expanded to the quasi-production process. Before purchasing the enterprise version, the actual delivery scope and SLA terms of SSO, RBAC, and audit logs must be clarified in the contract, as well as the upgrade path and compatibility guarantee when v2.0 is released. For domestic users, it is necessary to additionally evaluate the local adaptation requirements during privatized deployment - Kestra currently has limited official support for domestic databases and cloud platforms and needs to verify it by itself.

Version Info

• Kestra latest version ：There is no official precise date yet, and the workflow orchestration engine will continue to be iterated. （~2026）
• Kestra first edition ：There is no official precise date yet, Kestra will be launched as a YAML orchestration platform. （~2022）