​Server components

Detailed breakdown of the server components behind Kestra.

Kestra consists of multiple server components that can be scaled independently.

Each server component interacts with internal components (Internal Storage, Queue, and Repository).

Executor

The Executor is a lightweight server component responsible for processing all executions and orchestrating the next tasks to run. It does not perform heavy computations itself, instead deferring actual task execution to Workers.

The Executor plays a central role in coordinating workflows based on the information it receives from the Scheduler and the Queue. It handles specific types of tasks, such as:

• Flowable Tasks
• Flow Triggers
• Templates (deprecated)
• Listeners (deprecated)

Although the Executor oversees all executions, it generally never interacts directly with your data.

Because of its low resource usage, the Executor rarely needs to be scaled. However, in deployments with a very large number of executions, you can scale Executors horizontally to meet demand.

Worker

The Worker is a server component responsible for executing all runnable tasks and Polling Triggers. These are received from the Executor and the Scheduler, respectively.

Workers are highly configurable and designed to handle a wide range of workloads — from simple API calls to heavy computational tasks. Internally, each Worker functions as a configurable thread pool, allowing you to define the number of threads per instance based on your workload requirements.

You can deploy multiple Worker instances across different servers to scale horizontally. This flexibility enables efficient handling of parallel executions, especially in high-throughput environments.

Because Workers directly execute tasks and triggers, they are the only server components that require access to external systems — such as databases, REST APIs, message brokers, and any other services your flows interact with.

Worker Group (EE)

In the Enterprise Edition, Worker Groups allow tasks and Polling Triggers to be executed on specific worker sets. They can be beneficial in various scenarios, such as using compute instances with GPUs, executing tasks on a specific OS, restricting backend access, and region-specific execution. A default worker group is recommended per tenant or namespace.

To specify a worker group for a task, use the workerGroup.key property in the task definition to point the task to a specific worker group key. If no worker group is specified, the task will be executed on the default worker group.

Scheduler

The Scheduler is a server component responsible for managing all triggers — except for Flow Triggers, which are handled by the Executor.

The Scheduler continuously evaluates trigger conditions and determines when a flow should start. When a trigger is satisfied, the Scheduler submits the flow to the Executor for execution.

For Polling Triggers, the Scheduler checks them at their configured evaluation interval. If the polling conditions are met, it sends the execution — along with trigger metadata — to the Worker for execution.

Polling Triggers have specific constraints:

• They cannot be evaluated concurrently.
• They cannot be reevaluated while a previous execution from the same trigger is still running.

Internally, the Scheduler checks every second to determine whether any trigger needs evaluation.

Indexer

The Indexer is responsible for reading content from Kafka topics — such as flows and executions — and indexing it into Elasticsearch. This component enables low-latency querying when using Kafka and Elasticsearch together.

By default, the Indexer runs as part of the Web Server. However, you can choose to run the Web Server independently without the Indexer by using the server webserver --no-indexer CLI option.

The Indexer is required for deployments that rely on Kafka and Elasticsearch, particularly in Kestra Enterprise Edition and Kestra Cloud.

Webserver

The Webserver is the entry point for all external communications with Kestra. It is responsible for serving both the User Interface (UI) and the REST API, consolidating them into a single component.

It consists of two main modules:

• API: Exposes all REST endpoints for interacting with Kestra — including triggering executions, retrieving flow data, managing tasks, and more.
• UI: Serves the Kestra web interface, enabling users to design, monitor, and manage workflows visually.

The Webserver primarily interacts with the Repository to serve content through the API and UI. It also connects to the Queue to submit new executions and stream real-time updates on flow progress.