Should I upgrade to Kestra 1.0 API and Config Breaking Changes Before Self-Host now?
Decide whether to upgrade self-hosted Kestra now or defer until plugin, config, and orchestration API changes are absorbed safely in production.
Blockers
- package/kestra-1-0 — EOL 2026-09
- package/kestra-1-3 — EOL 2027-03
- requires_version: package/kestra-1-3 → runtime/java-25
- breaking_change_in: capability/webhook-execution-api → package/kestra-1-1
- breaking_change_in: capability/input-prefill-defaults → package/kestra-1-1
- breaking_change_in: capability/helm-chart-configuration → package/kestra-1-0
- breaking_change_in: protocol/api-v1-main → package/kestra-1-0
Who this is for
- enterprise
Candidates
Upgrade now to pinned Kestra 1.0.x LTS after explicit 1.0 remediation
As of 2026-04-03, Kestra 1.0 is an active LTS release line published on 2025-09-09 and supported until 2026-09. Kestra recommends LTS releases for production and recommends pinning exact image versions rather than using latest tags. The official 1.0 migration guides flag blocker-level changes: Helm chart restructuring, removal of PostgreSQL/MinIO/Kafka/Elasticsearch from the production chart dependencies, dynamic input defaults, removal of Singer Tap support, and custom plugin package changes. Kestra Enterprise self-hosting is sold as an annual per-instance subscription with unlimited flows, tasks, and executions, but the official pricing page does not publish a numeric price.
When to choose
Use this when you need a supported production line now and can schedule a short remediation sprint for API consumers, Helm values, and plugin or flow definitions. The decisive factor is whether you can pre-validate the known 1.0 breaking changes in staging and pin a specific 1.0 patch before rollout.
Tradeoffs
You get onto an LTS line without taking on the extra 1.1 to 1.3 migration work immediately, but you still must absorb real breaking changes in deployment configuration and some flow behavior.
Cautions
The production Helm chart no longer bundles PostgreSQL, MinIO, Kafka, or Elasticsearch, so upgrades that relied on old chart dependencies can break infrastructure assumptions. Input defaults changed behavior, which can break flows using Pebble expressions in defaults. Singer pipelines must be migrated to alternatives such as Airbyte, dlt, or CloudQuery. Custom plugin test code may need package and Gradle module updates.
Defer production upgrade until API, Helm, and plugin consumers are refactored
As of 2026-04-03, Kestra's own upgrade guide says to test new versions in non-production first, review breaking changes in release notes, and avoid downgrades where possible. The documented breakpoints relevant to older self-hosted installs include OSS API tenant-path changes to /api/v1/main, Helm chart restructuring in 1.0, and later 1.1 API and orchestration behavior changes such as Webhook Execution API return type changes and input prefill/default semantics. Deferral reduces immediate production risk if external callers, CI, or internal tooling still assume older routes and config shapes. The cost is staying off the cleaner LTS path while support freshness shifts toward newer releases.
When to choose
Use this when production stability matters more than support recency and your current automations still depend on older API paths, old Helm values, or removed plugins. The decisive factor is whether you lack a staged environment and automated regression coverage for workflow submission, webhook execution, and rollout behavior.
Tradeoffs
You avoid a rushed break-fix cycle in production, but you continue carrying migration debt and may face a larger eventual jump.
Cautions
Kestra's current releases page, as of 2026-04-03, lists active lines starting at 1.0 and newer. If you defer from a pre-1.0 deployment, document exactly which deprecated API paths and chart conventions you still depend on so the later migration does not become opaque.
Skip 1.0 operationally and target Kestra 1.3 LTS only after a full rehearsal
As of 2026-04-03, Kestra 1.3 is the newest LTS, released on 2026-03-03 and supported until 2027-03, while 1.0 remains supported until 2026-09. Kestra documents that a direct 1.0 to 1.3 jump requires the 1.1 and 1.2 metadata migrations for KV metadata, secrets metadata in Enterprise, and namespace files metadata. Kestra also states that 1.3 requires Java 25 or later, and Enterprise nodes on 1.3+ will refuse to start with licenses issued before 1.3. This option makes sense only if you are willing to wait for a deeper rehearsal and want the longer support window instead of landing on 1.0 first.
When to choose
Use this when you already expect to miss the useful part of the 1.0 LTS window or want to avoid doing two production upgrades in close succession. The decisive factor is whether you can absorb Java runtime, metadata migration, and Enterprise license changes in one controlled program.
Tradeoffs
You get the longest support runway, but the change set is broader than a 1.0-only move and the prerequisite work is heavier.
Cautions
This is not a low-friction deferral path. If you are on Enterprise, you must regenerate licenses before 1.3 rollout. If you are on 1.0 today, Kestra says all three metadata migrations are required for a complete 1.0 to 1.3 upgrade.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Should I upgrade to Kestra 1.0 API and Config Breaking Changes Before Self-Host now?"