Kestra 2.0 Summary Kestra 2.0 overhauls the platform's core architecture by splitting it into a control plane and data plane. Workers no longer need direct database access—they connect to the control plane through a single outbound gRPC stream, which means they can run in different regions, clouds, or networks that only allow outbound connections. This is a big deal for security and deployment flexibility. The queue and database are now decoupled too. Previously, you had to choose between Postgres/MySQL or Kafka/Elasticsearch for both, and every feature needed separate implementations for each. Now they're independent, so there's one codebase underneath regardless of whether you use Postgres, Kafka, Redis, or AMQP for the queue. The gRPC connection can be encrypted with TLS or mTLS, and workers present certificates or JWTs before receiving jobs—no inbound ports required. The feature set expands significantly across the three editions (OSS, Enterprise, Cloud). AI integration gets real teeth: flows can be exposed as tools that AI agents call directly through the MCP Tool Trigger, and the AI Copilot now runs as a persistent sidebar with three modes—Edit for generating YAML, Plan for step-by-step task execution, and Ask for questions. The no-code editor syncs with YAML and the Copilot. Enterprise users get incident management through Cases, environment promotion with drift detection, namespace-scoped governance policies, and action-based RBAC instead of CRUD permissions. Worker Groups 2.0 adds tag-based routing and capacity reservation. New task runners support AWS EC2, Azure VMs, Google Compute Engine, and Huawei CCI. Upgrading from 1.x requires being on 1.3.x first. Several constructs disappear—ForEach, trigger conditions, workerGroup.key, and pluginDefaults—but the kestra-migrate tool handles most rewrites automatically. Breaking changes get dedicated migration guides. For fresh deployments, Kestra recommends starting with a single Postgres instance handling both queue and repository, then moving the queue to Kafka or Redis later if you need lower latency or higher throughput. The architecture docs and backend configuration guide cover which combinations work best for different scenarios.