Kestra 2.0 takes the database credential out of the worker

In 1.x every worker needed a connection to the central database, and that single design decision dictated where you were allowed to run tasks ^[10]. When a security team would not open a route from one network to the Postgres in another, the options were a full Kestra deployment per site or scripts left on a local box under cron with no orchestration at all; the author of the dev.to post writes that he watched teams pick the second more than once ^[11].

Because the worker now initiates, it holds no database credentials and nothing has to connect inbound to it, so it can sit in another cloud, another region, or a network that only permits outbound traffic ^[15]. Each worker can be required to present a client certificate or a JWT before any job is dispatched to it, over a channel that can carry TLS ^[14]. The trust boundary moves from a database ACL to a per-worker identity check, which is the version a security review can approve without a network exception. The post leaves failure behaviour largely undocumented: what happens to in-flight jobs when the stream drops, whether 1.x ForEach syntax still parses, and which queue implementations ship in 2.0 ^[25].

The deployment saving is older than this release. The 2022 architecture used Kafka as both queue and database with Elasticsearch as the repository behind the UI ^[1], and it ran 350,000 executions a month at Leroy Merlin ^[2]. Divide by 30 days and then by 1,440 minutes and that is about 8 executions a minute ^[3], for two clusters. The post says the most common reply was that requiring both to schedule a job was absurd, and calls that fair ^[4]. A JDBC backend followed four months later, with a single Postgres or MySQL holding queue and state ^[5], which dates the cheap deployment story to roughly June 2022 ^[6], about three years and three months before the September 2025 1.0 long-term-support release ^[7][9].

The engine work in 2.0 settles a maintenance bill run up since that 2022 split, rather than delivering a first cheapening. In 1.x the queue and the repository came as a fixed pair, JDBC for both or Kafka plus Elasticsearch, which meant two engine implementations and every bug fixed twice ^[16]. That is the debt being paid. The licence stays where it was, with the post's headline still saying Apache 2.0 ^[23]. All of it is the vendor's own account, published on dev.to, and it carries no throughput figures for 2.0 ^[26]. It does retire the word "infinitely" from the 2022 title ^[24], which is more than most release copy gives back.

The quota and Copilot defaults matter more for day-to-day operations than the new canvas does. Quotas cap executions per flow or namespace, so one team's runaway stops being everyone's incident ^[19]. Setting kestra.ai.enabled: false switches the Copilot off, after which no AI endpoint exists on the server, and the AI Agent task can point at Ollama on your own hardware ^[22]. Any flow can be exposed as a tool through MCP, and the resulting execution carries the same permissions as a person clicking Run, labelled system.from: mcp, with steps you cannot undo able to wait for a human ^[21]. Underneath, the post says it is still YAML in your Git repo with no code that imports Kestra ^[28], which keeps the exit cost roughly where it was.

For the topology change to be worth an upgrade in your shop, the blocked direction has to have been inbound. A network that also refuses outbound gRPC to your control plane gains nothing from the split, and neither does a single-region install whose workers already sit next to the database.