Related Pages

Related topics: Flows, Tasks, Triggers & Execution Model, Concurrency Limits, Replay & Execution Lifecycle

System Architecture & Multi-Server Topology

Overview

Kestra is built as a distributed orchestration platform in which a single binary can be started in several roles depending on operator needs. The CLI is partitioned into a server command (production / scaled deployments) and a sys command (maintenance operations), and each role is implemented as a subcommand registered on the parent dispatcher.

The dispatcher itself lists every long-running role that the binary may take on. In ServerCommand.java the subcommands array enumerates the full set of server types: Executor, Indexer, Scheduler, StandAlone, WebServer, Worker, Controller, and Local. A marker interface, ServerCommandInterface.java, lets framework code distinguish these server commands from ordinary CLI utilities.

This design enables three principal deployment topologies:

• Standalone / Local — a single process running every role for development or small workloads.
• Split roles — separate processes for Web, Executor, Scheduler, Worker, Controller, and Indexer (typically containerized; see the charts/kestra README).
• Maintenance-only invocations — ad-hoc sys tasks such as reindexing or queue draining.

Server Roles

Each role binds to a configurable HTTP port (the --port option exposed by AbstractServerCommand.java) and shares the same Micronaut context, so configuration is loaded uniformly across nodes.

A graceful shutdown hook is registered by AbstractServerCommand#call, which delegates to KestraContext.getContext().shutdown() (AbstractServerCommand.java:21-26).

Cluster Architecture

flowchart LR
    Client[UI / API Client]
    subgraph Cluster["Kestra Cluster"]
      WS[WebServer]
      EX[Executor]
      SCH[Scheduler]
      IDX[Indexer]
      CT[Controller]
      W1[Worker 1]
      W2[Worker N]
    end
    JDBC[(JDBC Storage\nH2 / MySQL / Postgres)]
    Queue[(JDBC Queue)]
    Client <--> WS
    WS --> JDBC
    EX --> JDBC
    EX --> Queue
    SCH --> JDBC
    IDX --> JDBC
    CT --> JDBC
    W1 --> Queue
    W2 --> Queue
    Queue --> EX

The Executors place work on the JDBC queue; the Workers consume it. Both the queue and the state records live in the relational database selected at build time. This architecture is what makes the recent *“keep JDBC queue consumer alive on transient DB errors”* fixes (v1.3.23, v1.2.22, v1.0.47) so critical — a single transient DB hiccup can otherwise strand in-flight tasks across every Worker.

Storage Abstraction (Multi-Database)

Kestra ships per-database modules that share a JDBC base. The dashboard repository, for instance, is implemented separately for each engine:

• H2DashboardRepository — @H2RepositoryEnabled for embedded / dev.
• MysqlDashboardRepository — @MysqlRepositoryEnabled for production clusters.

Both extend AbstractJdbcDashboardRepository and inject a @Named("dashboards") MysqlRepository<Dashboard> (or H2 equivalent) plus an ApplicationEventPublisher<CrudEvent<Dashboard>> and a list of QueryBuilderInterface instances. The dialect-specific piece is isolated to findCondition(query), returning a jOOQ Condition for that engine.

A second example, MysqlFlowTopologyRepository, overrides buildMergeStatement to emit a dialect-correct INSERT ... ON DUPLICATE KEY UPDATE upsert — Postgres would use ON CONFLICT (...) DO UPDATE in its sibling module. This pattern keeps engine-specific SQL confined to thin overrides while sharing schema and lifecycle code.

Startup, Configuration, and Maintenance

A DefaultStartupHook (DefaultStartupHook.java) runs only for full server commands (any ServerCommandInterface *except* WorkerCommand), and is responsible for:

• Saving the running Kestra version via VersionService::maybeSaveOrUpdateInstanceVersion.
• Creating a default MCP server entry per tenant (McpServerService).
• Recording the active edition (OSS / EE) through EditionProvider.

The base AbstractCommand.java loads a YAML configuration file when one is supplied via --config, contributing additional Map<String, Object> properties into the Micronaut context. Recent CLI work (v1.3.23) explicitly restored this behavior so --config works correctly when placed before the subcommand.

System-level maintenance is exposed through SysCommand.java, whose two subcommands are:

• ReindexCommand — rebuilds search indexes (used after major data migrations).
• SubmitQueuedCommand — re-submits executions left stuck in the queue, addressing the cluster failure mode described in the JDBC queue consumer fixes above.

Helm / Kubernetes Deployment

Production clusters typically deploy each role as its own Deployment or StatefulSet. The Helm chart (see charts/kestra/README.md) exposes knobs including common.replicas, common.kind (Deployment vs StatefulSet), liveness/readiness probes pointing at /health/liveness, /health/readiness, and /health, and resource/affinity overrides so that heavier roles (Executor, Worker) can be scaled independently of the WebServer.

See Also

• CLI Commands & Server Roles
• JDBC Storage Backends
• Scheduler & Triggers
• Helm Chart Reference

Related Pages

Related topics: System Architecture & Multi-Server Topology, Concurrency Limits, Replay & Execution Lifecycle

Flows, Tasks, Triggers & Execution Model

Overview

Kestra is an open-source, event-driven orchestration platform that unifies scheduled and event-driven automation behind a declarative YAML interface. According to the project README, the four foundational concepts are:

• Flows — the core unit in Kestra, representing a workflow composed of tasks.
• Tasks — individual units of work, such as running a script, moving data, or calling an API.
• Triggers — schedules or events that initiate the execution of flows.
• Executions — the runtime instance of a flow, persisted with its task states, logs, and outputs.

Source: README.md

The platform treats workflow orchestration as code, so the YAML definition of a Flow is the canonical source of truth — even when the workflow is built or modified from the UI, via the API, or through CI/CD, the source-of-truth YAML stays in sync.

Core Domain Model

The persistence layer reveals the typed domain entities that make up the execution model. Each entity has a dedicated JDBC repository implementation, following the same pattern across H2, MySQL, and Postgres backends:

Source: jdbc-h2/src/main/java/io/kestra/repository/h2/H2ExecutionRepository.java, jdbc-h2/src/main/java/io/kestra/repository/h2/H2TriggerRepository.java, jdbc-h2/src/main/java/io/kestra/repository/h2/H2LogRepository.java, jdbc-h2/src/main/java/io/kestra/repository/h2/H2DashboardRepository.java

The JDBC repositories all extend shared abstract bases (e.g., AbstractJdbcExecutionRepository) injected with the appropriate JdbcFilterService, jOOQ DSLContext, and a CrudEvent publisher — confirming the model is fully event-driven.

Flow → Execution Lifecycle

flowchart LR
    A[YAML Flow Source] --> B[FlowRepositoryInterface.find]
    B --> C[Flow loaded into runtime]
    C --> D{Trigger fires?}
    D -- Schedule --> E[Execution created]
    D -- Event --> E
    D -- Manual/API --> E
    E --> F[TaskRunner executes tasks]
    F --> G[Execution state persisted]
    G --> H[LogEntry recorded]
    G --> I[FlowTopology updated]

The CLI's ReindexCommand illustrates the write side of the Flow lifecycle. It loads every flow across all tenants via FlowRepositoryInterface.findAllForAllTenants(), then calls FlowService.update(...) with the latest source so the index and topology stay consistent with the YAML.

Source: cli/src/main/java/io/kestra/cli/commands/sys/ReindexCommand.java

FlowTopology is maintained as a derived view of the flow graph. Both MySQL and Postgres implementations extend AbstractJdbcFlowTopologyRepository, overriding the merge-statement syntax for their respective dialect (MySQL's onDuplicateKeyUpdate vs. Postgres's onConflict().doUpdate()).

Source: jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlFlowTopologyRepository.java, jdbc-postgres/src/main/java/io/kestra/repository/postgres/PostgresFlowTopologyRepository.java

Triggers, Scheduling & State Recovery

Triggers are modeled as TriggerState rows, written and read by H2TriggerRepository (and its MySQL/Postgres counterparts). The AbstractJdbcTriggerRepository base class encapsulates the scheduling and recovery logic. Recent changelogs confirm the scheduler's behavior under re-enable scenarios:

• v1.2.22 (scheduler): "prevent recovering missed schedules when re-enabling a trigger via API (#16721)". This means that when an admin re-enables a trigger that had been disabled, the scheduler does not retroactively replay the schedules it would have produced while it was paused — by design.

Source: jdbc-h2/src/main/java/io/kestra/repository/h2/H2TriggerRepository.java

Community Discussion & Known Gaps

Several open community issues map directly to this execution model:

• Concurrency limits (#1400) — A long-standing feature request (8 comments) asking for the ability to cap concurrent executions per flow with two policies: *queue excess* or *cancel excess*. The io.kestra.core.models.flows.Concurrency class is part of the same package as Flow, indicating where such a policy would live.
• Bulk replay on Flow's Executions tab (#16906) — The backend endpoint already exists, but a UI button for selecting multiple executions and replaying them in bulk is missing. This is a UI gap over an already-shipped API capability.
• Dashboard quick-filter "All" tab empty (#16812) — On the dashboard executions widget, the All filter sometimes shows "no results" while state-specific tabs (e.g., Success, Failed) return rows. Points to a filter aggregation bug in H2DashboardRepository-style queries.
• Filters EPIC (#15952) — Collecting all backend changes needed to support richer conditional filters; the JdbcFilterService injected into each repository is the consolidation point.
• Outdated revision warning (v1.0.46, #16570) — When the UI restored this warning, it implicitly requires that each Flow row carry a revision/version that can be compared before save — confirming versioning is part of the Flow model.

Putting It Together

The execution model in Kestra can be summarized as four tightly-coupled layers:

1. Authoring layer — Flow YAML stored via FlowRepositoryInterface, validated and indexed.
2. Triggering layer — TriggerState rows observed by the scheduler; each fire creates an Execution.
3. Runtime layer — Execution rows progress through task states; LogEntry rows stream events; FlowTopology is recomputed from the current flow source.
4. Observation layer — Dashboard widgets query the JDBC repositories using JdbcFilterService-built conditions and CrudEvent-published changes.

Because every layer is a normal JDBC repository with explicit CrudEvent publication, downstream consumers (notifications, audit, plugins) can subscribe to changes uniformly across H2, MySQL, and Postgres — which is why the same AbstractJdbc* base is reused in each backend module.

Source: README.md, jdbc-h2/src/main/java/io/kestra/repository/h2/H2ExecutionRepository.java, jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlExecutionRepository.java, jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlDashboardRepository.java

See Also

• Plugin Ecosystem — Hundreds of task and trigger plugins built on the same execution model.
• Plugin Developer Guide — How to add a new Task or Trigger type that plugs into Execution.
• Terraform Provider — Manage Flow resources as Infrastructure-as-Code.
• Issue #15952 — Filters EPIC — Ongoing work that will refine how Execution queries are filtered across the JDBC repositories.

Related Pages

Related topics: Flows, Tasks, Triggers & Execution Model, Concurrency Limits, Replay & Execution Lifecycle

Frontend UI, Filters, Dashboards & Topology

Overview

The Kestra frontend is a Vue 3 + Vite single-page application shipped from the ui/ workspace. It is the primary surface where users author flows as YAML, observe executions, build dashboards, and visualize workflow graphs. The frontend is composed of several internal packages that are published individually so that the design system and the topology graph can be reused by the EE distribution and third-party plugins.

The application bootstraps from ui/src/main.ts and is composed of routed views for flows, executions, dashboards, logs, and admin features. The UI communicates with the backend through REST endpoints exposed by the JDBC repositories. A release ships as a static bundle that can be served from the same JVM process as the orchestration engine or from a CDN.

The product positioning from README.md is "Everything as Code and from the UI": flows are stored as YAML in version control, but the editor, the drag-and-drop topology builder, and the live validation are the primary authoring tools. This dual model is what makes filters, dashboards, and topology tightly coupled in the user experience.

UI Architecture and Design System

The UI is split into a root app and reusable libraries. The root ui/package.json declares Vue 3.5, Vite 8, Vitest 4, Storybook 10, vue-echarts, vue-i18n, and vue-router as direct dependencies. The Storybook setup is used for component-level visual regression.

Two internal libraries are exposed via npm exports:

• @kestra-io/design-system — defined in ui/packages/design-system/package.json, this package wraps Element Plus primitives with Kestra styling and a11y tests via @storybook/addon-a11y.
• @kestra-io/topology — defined in ui/packages/topology/package.json, this package is "powered by Vue Flow" and exports both the default surface and a vue-flow-utils entrypoint for helper functions.

Source: ui/package.json and ui/packages/design-system/package.json.

Filters

The Executions view uses a composite filter model: a quick interval selector for the time window (15m / 1h / ...) and conditional groups for advanced predicates joined by AND / OR. Both pieces live in the same page, but the contract between them has been a recurring source of community reports.

Issue #16433 "Quick interval selector doesn't fit conditional groups" reports that the time selector does not interact correctly with conditional groups: when a user adds an OR group with two distinct predicates, the interval selector scopes the wrong subset of the result set. Issue #15952 is the umbrella epic "Filters, backend changes needed for filter" and tracks the broader rewrite that the frontend has been aligned against.

The complementary feature request #16906 — "Add bulk-replay on Flow's Executions tab" — depends on the same filter model: bulk actions are computed on whatever the active filter returned, and the UI button is what is currently missing on the main branch (already merged on develop).

Dashboards

Dashboards are a first-class persistence model in Kestra. The backend defines a Dashboard JOOQ-backed entity and a DashboardRepository abstraction that is implemented per database. The three concrete implementations are:

• jdbc-h2/src/main/java/io/kestra/repository/h2/H2DashboardRepository.java — embedded/test storage.
• jdbc-postgres/src/main/java/io/kestra/repository/postgres/PostgresDashboardRepository.java — production storage.
• jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlDashboardRepository.java — alternative production storage.

Each implementation extends AbstractJdbcDashboardRepository and overrides findCondition(String query) to translate a free-text query into a JOOQ Condition specific to the dialect (H2, Postgres, or MySQL). All three are annotated with @RepositoryBean and a per-dialect @MysqlRepositoryEnabled / @H2RepositoryEnabled / @PostgresRepositoryEnabled stereotype so that the right bean is wired at startup. The eventPublisher parameter publishes CrudEvent<Dashboard> for downstream cache invalidation, and a list of QueryBuilderInterface<?> beans is injected so that dashboard queries can be extended by plugins.

On the frontend, the Executions quick-filter rendered inside dashboard widgets is the bar All / Running / Paused / Success / Warning / Failed. Issue #16812 "Dashboard 'Executions' quick-filter: the 'All' tab is empty while state tabs show executions" reports that the All tab returns zero rows even when state-specific tabs return many, which is a sign that the default branch in the widget does not strip the implicit state predicate the way the state-specific tabs do.

A related community request is issue #16603 "Logs chart: drag-to-select time-range brush", which asks for a Grafana-style drag interaction on the timeseries chart above the global /logs page so users can filter the list to the brushed window — the same interaction model would naturally extend to dashboard timeseries panels.

Topology and Auto-Completion

The Topology view is described in README.md as a "Live Topology View" that "shows your workflow as a Directed Acyclic Graph (DAG) that updates in real-time" alongside a "Drag-and-Drop Interface" and "Real-Time Validation". The visual rendering is implemented by the @kestra-io/topology package, which wraps the Vue Flow library. Its package.json (sideEffects includes ./dist/style.css) confirms the graph ships with its own stylesheet so it can be embedded in other surfaces (e.g. a dashboard panel, or the EE namespace explorer).

The DAG is persisted in the flowtopologies table by AbstractJdbcFlowTopologyRepository. The MySQL implementation in jdbc-mysql/src/main/java/io/kestra/repository/mysql/MysqlFlowTopologyRepository.java overrides buildMergeStatement to issue an INSERT ... ON DUPLICATE KEY UPDATE (a MySQL-specific upsert) rather than the Postgres MERGE statement, so that the topology graph is regenerated as the YAML changes without a separate read-modify-write cycle.

Auto-completion is a long-standing community request tracked in issue #3331 "Add Inputs, Outputs, Trigger and Variables autocompletion", which calls for in-editor suggestions for {{ inputs.* }}, {{ outputs.* }}, {{ trigger.* }}, and {{ variables.* }}. The same feature is also relevant to the proposed flow-template customization in issue #4956, where a configuration-level template would feed the autocomplete dictionary.

Operational Notes and Common Failure Modes

• JDBC queue consumer resilience: a regression that caused the queue consumer to die on transient DB errors was fixed in v1.0.47, v1.2.22, and v1.3.23 (see release notes for #16794, #16814, #16816). Operators on older versions should monitor the worker logs for unhandled JDBC exceptions.
• Outdated revision warning: the UI used to silently overwrite edits made on stale revisions; the "outdated revision warning and save confirmation" was restored in v1.0.46 (release 318fa96).
• Helm chart migration: the chart in charts/kestra/README.md flags breaking changes between 0.x.x and 1.0.0 — notably image.image → image.repository and serviceAccountName → serviceAccount.{create,automount,annotations,name}. Read the chart README before upgrading production clusters.
• PostHog in dev mode: v1.0.47 disabled PostHog in dev mode to stop the survey request spam on redirects (#16745).

See Also

• Filters epic #15952
• Dashboard quick-filter bug #16812
• Quick interval selector + conditional groups #16433
• Bulk-replay on Executions tab #16906
• Logs chart time-range brush #16603
• Auto-completion for inputs/outputs/triggers/variables #3331
• Flow template customization #4956

Related Pages

Related topics: System Architecture & Multi-Server Topology, Flows, Tasks, Triggers & Execution Model, Frontend UI, Filters, Dashboards & Topology

Concurrency Limits, Replay & Execution Lifecycle

Kestra is a declarative, event-driven orchestration platform that models workflows as Flows composed of Tasks. Three concerns dominate the runtime behavior of those flows: how many executions of a given flow may run at once, how to reproduce or repair an existing execution after the fact, and the set of states an execution transitions through from creation to termination. This page documents those three concerns together because they share the same core types and operator-facing commands. Source: README.md

1. Concurrency Limits

A flow author can attach a concurrency block to a flow to cap how many of its executions are allowed to be in a non-terminal state at the same time. The model is defined in Concurrency.java and is referenced by the Execution aggregate in Execution.java. The community has long requested first-class concurrency controls — see issue #1400 "Concurrency limits: limit concurrent executions", which describes the two competing semantics operators want:

When a flow defines concurrency and the cap is reached, the new execution is represented as an ExecutionQueued event (ExecutionQueued.java) rather than entering the running state. Conversely, when an execution must be forcibly removed because of concurrency, a KILLED state is recorded via the ExecutionKilled event (ExecutionKilled.java).

2. Replay and Restart

Two related commands operate on past executions:

• Replay (Replay.java) creates a brand-new execution of the flow. The new execution is a sibling of the original, sharing inputs/parameters but with fresh timing, state, and identifiers. Replay is appropriate when an operator wants to re-run a flow with the same configuration after a code or data fix.
• Restart (Restart.java) re-enters an existing execution from a chosen task, preserving prior outputs of upstream tasks so they are not recomputed. Restart is appropriate for repairing a single failed task run.

Both are exposed via the Executor API and surfaced in the UI on a Flow's Executions tab. Community demand for a bulk replay action is tracked in issue #16906 "Add bulk-replay on Flow's Executions tab", which notes that the underlying endpoint already exists and only the UI affordance is missing.

A related maintenance command is the CLI's reindex (ReindexCommand.java), which "reindex all records of a type: read them from the database then update them." It currently supports only the flow type and iterates findAllForAllTenants() before re-saving each flow through FlowService. This is useful when the on-disk serialization of flows has changed and existing rows need to be re-written.

3. Execution Lifecycle

Every execution is a finite state machine keyed on the state field of Execution.java. The terminal states — SUCCESS, WARNING, FAILED, KILLED — are visible in the dashboard's quick-filter tabs (see issue #16812 about the All / Running / Paused / Success / Warning / Failed tab bar on dashboard executions widgets). The non-terminal states are CREATED, RUNNING, PAUSED, and QUEUED.

stateDiagram-v2
    [*] --> CREATED
    CREATED --> QUEUED: concurrency limit reached
    CREATED --> RUNNING: slot available
    QUEUED --> RUNNING: slot available
    RUNNING --> PAUSED: pause command
    PAUSED --> RUNNING: resume command
    RUNNING --> SUCCESS
    RUNNING --> WARNING
    RUNNING --> FAILED
    RUNNING --> KILLED: kill / concurrency cancel
    SUCCESS --> [*]
    WARNING --> [*]
    FAILED --> [*]: restart
    KILLED --> [*]
    FAILED --> [*]: replay

The QUEUED state is materialized by ExecutionQueued and the KILLED state by ExecutionKilled. JVM-level settings that influence how long executions are kept and how the JDBC queue is polled live in application.yml — for example kestra.jdbc.queue.max-poll-interval (default 500ms), kestra.jdbc.queue.poll-switch-interval (default 60s), and the cleaner retention rules for LogEntry and MetricEntry rows.

4. Common Failure Modes

• Stale "All" tab on dashboards: when the unified All quick-filter returns no rows but a state tab does, it is usually a filter/aggregation mismatch in the dashboard widget (#16812). Verify the findCondition and date-grouping helpers in the JDBC repository subclasses.
• Replay creates a duplicate instead of a restart: confirm whether the operator needs a sibling (Replay) or an in-place re-entry (Restart).
• Queue consumer dies on transient DB errors: addressed in 1.3.23 (42cb301), 1.2.22 (31dcef8) and 1.0.47 (4cccc93) — the JDBC queue consumer is now kept alive across transient errors. Operators on older versions should monitor for unexpected queue stalls.

See Also

• Triggers & Schedules
• JDBC Repositories & Queue Internals
• Dashboard Widgets & Filters

Doramagic Pitfall Log

Found 27 structured pitfall item(s), including 2 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

1. Installation risk: Installation risk requires verification

• Severity: high
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/kestra-io/kestra/issues/16896

2. Maintenance risk: Maintenance risk requires verification

• Severity: high
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/kestra-io/kestra/issues/16603

3. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: identity.distribution | https://github.com/kestra-io/kestra

4. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v0.22.44
• User impact: Upgrade or migration may change expected behavior: v0.22.44
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.22.44. Context: Observed during installation or first-run setup.
• Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v0.22.44

5. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/kestra-io/kestra/issues/16433

6. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: Allow adjusting the flow template based on configuration
• User impact: Developers may misconfigure credentials, environment, or host setup: Allow adjusting the flow template based on configuration
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Allow adjusting the flow template based on configuration. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_issue | https://github.com/kestra-io/kestra/issues/4956

7. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: v1.0.46
• User impact: Upgrade or migration may change expected behavior: v1.0.46
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v1.0.46. Context: Observed during version upgrade or migration.
• Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.0.46

8. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: v1.3.20
• User impact: Upgrade or migration may change expected behavior: v1.3.20
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v1.3.20. Context: Observed during version upgrade or migration.
• Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.3.20

9. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: v1.3.21
• User impact: Upgrade or migration may change expected behavior: v1.3.21
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v1.3.21. Context: Observed during version upgrade or migration.
• Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.3.21

10. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: v1.3.22
• User impact: Upgrade or migration may change expected behavior: v1.3.22
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v1.3.22. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.3.22

11. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: v1.3.23
• User impact: Upgrade or migration may change expected behavior: v1.3.23
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v1.3.23. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_release | https://github.com/kestra-io/kestra/releases/tag/v1.3.23

12. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/kestra-io/kestra/issues/16812

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using kestra with real data or production workflows.

• Add bulk-replay on Flow's Executions tab - github / github_issue
• Namespace files: filename with space collides with literal '+' → silent - github / github_issue
• Dashboard "Executions" quick-filter: the "All" tab is empty while state - github / github_issue
• Allow adjusting the flow template based on configuration - github / github_issue
• [[Filters] Quick interval selector doesn't fit conditional groups](https://github.com/kestra-io/kestra/issues/16433) - github / github_issue
• Logs chart: drag-to-select time-range brush (Grafana/GCP/PostHog style) - github / github_issue
• v1.3.23 - github / github_release
• v1.2.22 - github / github_release
• Installation risk requires verification - GitHub / issue
• Installation risk requires verification - GitHub / issue
• Configuration risk requires verification - GitHub / issue
• Configuration risk requires verification - GitHub / issue