Kestra 1.3: LTS Release with Kill Switch, Credentials, and Native Infrastructure Automation

Kestra 1.3 brings production-grade controls to enterprise teams, native CI/CD tooling to developers, and new infrastructure plugins to teams managing bare-metal, VM, and cloud networking environments.

Here’s what’s in 1.3:

Check the video below for a quick overview of all enhancements.

Kill Switch

When production incidents happen, relying on CLI-only skip commands is slow, confusing, and limited to server admins.

Kill Switch introduces a UI-based mechanism to stop or contain problematic executions, designed for administrators. It provides a comprehensive administration interface and ensures every action is visible and auditable. Any admin can respond immediately, and every action lands in the audit log.

You can access it under Instance > Kill Switch, where you can create new Kill Switches and review active or archived ones. Three types are available:

Kill Switches can target a tenant, namespace, flow, or execution. They support scheduling with a mandatory start date and optional end date, and include an optional reason to document why the switch was applied. All actions are recorded in Audit Logs, and deletions are soft-deleted to preserve history.

An announcement banner is displayed based on scope: namespace-level switches are shown only to users working in that namespace, while tenant-level switches appear for all users in the tenant.

The CLI remains available for power users and administrators who prefer terminal workflows, with the commands renamed to align with behavior:

--ignore-executions
--ignore-flows

Credentials

Teams struggle to connect workflows to modern APIs because credentials are scattered, brittle, and hard to rotate across environments. Managing authentication separately in each integration slows delivery and makes incidents harder to fix. Fewer 2 AM incidents from expired tokens, and less time hunting down which flow broke when a credential rotated.

Credentials provide reusable server-to-server (machine-to-machine) authentication for flows. You configure authentication once and reference it in workflows with a simple expression, while Kestra handles token retrieval and refresh centrally.

Use the credential() function to retrieve an access token at runtime:

id: api_call
namespace: company.team

tasks:
  - id: request
    type: io.kestra.plugin.core.http.Request
    uri: https://api.example.com/v1/ping
    method: GET
    options:
      auth:
        type: BEARER
        token: "{{ credential('my_oauth') }}"

Supported credential types include OAuth2 client_credentials, OAuth2 JWT Bearer (jwt_bearer), OAuth2 private_key_jwt, and GitHub App.

Assets

Kestra 1.3 brings the second iteration of Assets, building on the foundation introduced in Kestra 1.2.

In Kestra 1.2, Assets introduced a stateful inventory and lineage model directly in workflows. In 1.3, Assets becomes more operational: teams can now manage assets imperatively, react to lifecycle events in real time, monitor freshness, and automate remediation and governance workflows with richer filters and trigger outputs. Stale assets trigger remediation automatically, without waiting for a broken report to surface the problem.

What this means in practice:

• Imperative lifecycle tasks to create/update, list, and delete assets directly from flows (Set, List, Delete).
• Event-based trigger automation with EventTrigger to react on asset lifecycle events (CREATED, UPDATED, DELETED, USED).
• Freshness monitoring trigger to detect stale assets and launch workflows automatically (FreshnessTrigger).
• Actionable trigger context with event, eventTime, lastUpdated, staleDuration, and checkTime to drive alerts, routing, and recovery actions.

id: asset_event_driven_pipeline
namespace: company.data

tasks:
  - id: transform_to_mart
    type: io.kestra.plugin.core.flow.Subflow
    namespace: company.data
    flowId: create_mart_tables
    inputs:
      source_asset_id: "{{ trigger.asset.id }}"
      source_event: "{{ trigger.asset.event }}"
      event_time: "{{ trigger.asset.eventTime }}"

triggers:
  - id: staging_table_event
    type: io.kestra.plugin.ee.assets.EventTrigger
    namespace: company.data
    assetType: io.kestra.plugin.ee.assets.Table
    events:
      - CREATED
      - UPDATED
    metadataQuery:
      - field: model_layer
        type: EQUAL_TO
        value: staging

id: audit_asset_deletions
namespace: company.security

tasks:
  - id: log_deletion
    type: io.kestra.plugin.jdbc.postgresql.Query
    sql: |
      INSERT INTO audit_log (asset_id, asset_type, namespace, event, event_time)
      VALUES (
        '{{ trigger.asset.id }}',
        '{{ trigger.asset.type }}',
        '{{ trigger.asset.namespace }}',
        '{{ trigger.asset.event }}',
        '{{ trigger.asset.eventTime }}'
      )

triggers:
  - id: asset_deletion_event
    type: io.kestra.plugin.ee.assets.EventTrigger
    events:
      - DELETED

id: stale_assets_monitor
namespace: company.monitoring

tasks:
  - id: log_stale
    type: io.kestra.plugin.core.log.Log
    message: >
      Found {{ trigger.assets | length }} stale assets.
      First asset: {{ trigger.assets[0].id ?? 'n/a' }}.
      Stale for: {{ trigger.assets[0].staleDuration ?? 'n/a' }}.

triggers:
  - id: stale_assets
    type: io.kestra.plugin.kestra.ee.assets.FreshnessTrigger
    maxStaleness: PT24H
    interval: PT1H

id: prod_assets_freshness
namespace: company.monitoring

tasks:
  - id: trigger_remediation
    type: io.kestra.plugin.core.flow.Subflow
    namespace: company.data
    flowId: refresh_marts
    inputs:
      asset_id: "{{ trigger.assets[0].id }}"
      last_updated: "{{ trigger.assets[0].lastUpdated }}"
      stale_duration: "{{ trigger.assets[0].staleDuration }}"

triggers:
  - id: stale_prod_marts
    type: io.kestra.plugin.kestra.ee.assets.FreshnessTrigger
    namespace: company.data
    assetType: TABLE
    maxStaleness: PT6H
    interval: PT30M
    metadataQuery:
      - field: environment
        type: EQUAL_TO
        value: prod
      - field: model_layer
        type: EQUAL_TO
        value: mart

id: asset_lifecycle_ops
namespace: company.data

tasks:
  - id: upsert_asset
    type: io.kestra.plugin.kestra.ee.assets.Set
    namespace: assets.data
    assetId: customers_by_country
    assetType: TABLE
    displayName: Customers by Country
    assetDescription: Customer distribution by country
    metadata:
      owner: data-team
      environment: prod

  - id: list_assets
    type: io.kestra.plugin.kestra.ee.assets.List
    namespace: assets.data
    types:
      - TABLE
    metadataQuery:
      - field: owner
        type: EQUAL_TO
        value: data-team
    fetchType: FETCH

  - id: delete_asset
    type: io.kestra.plugin.kestra.ee.assets.Delete
    assetId: customers_by_country

Auto-Generated Assets

Some plugins now support automatic asset generation when you set assets.enableAuto: true on a task. This removes the need to manually declare assets.inputs and assets.outputs — the plugin inspects its execution context and emits assets automatically:

• JDBC Query — detects CREATE TABLE statements and emits a Table output; the JDBC URL populates system and database.
• Ansible CLI — parses inventory hosts as inputs of type io.kestra.core.models.assets.External, marking the infrastructure targets the playbook runs against.
• dbt CLI — parses manifest.json to emit each model as a Table output with database, schema, name, and lineage edges based on depends_on.

id: jdbc_create_trips
namespace: company.team

tasks:
  - id: create_trips_table
    type: io.kestra.plugin.jdbc.sqlite.Query
    url: jdbc:sqlite:myfile.db
    outputDbFile: true
    sql: |
      CREATE TABLE IF NOT EXISTS trips (
          VendorID INTEGER,
          passenger_count INTEGER,
          trip_distance REAL
      );
    assets:
      enableAuto: true

id: ansible_playbook
namespace: company.team

tasks:
  - id: ansible_task
    type: io.kestra.plugin.ansible.cli.AnsibleCLI
    inputFiles:
      inventory.ini: |
        localhost ansible_connection=local
      myplaybook.yml: |
        ---
        - hosts: localhost
          tasks:
            - name: Print Hello World
              debug:
                msg: "Hello, World!"
    assets:
      enableAuto: true
    commands:
      - ansible-playbook -i inventory.ini myplaybook.yml

id: dbt_build_duckdb
namespace: company.team

tasks:
  - id: dbt
    type: io.kestra.plugin.core.flow.WorkingDirectory
    tasks:
      - id: clone_repository
        type: io.kestra.plugin.git.Clone
        url: https://github.com/kestra-io/dbt-example
        branch: main

      - id: dbt_build
        type: io.kestra.plugin.dbt.cli.DbtCLI
        taskRunner:
          type: io.kestra.plugin.scripts.runner.docker.Docker
        containerImage: ghcr.io/kestra-io/dbt-duckdb:latest
        commands:
          - dbt deps
          - dbt build
          - dbt run
        profiles: |
          my_dbt_project:
            outputs:
              dev:
                type: duckdb
                path: ":memory:"
                fixed_retries: 1
                threads: 16
                timeout_seconds: 300
            target: dev
        assets:
          enableAuto: true

AI Copilot Enhancements

AI assistants are most useful when teams can control where and how they are used. In many organizations, administrators need permission boundaries, predictable model behavior, and simple input options before enabling copilots broadly. Enterprise admins who previously blocked broad rollout for lack of governance controls now have what they need to enable it.

Kestra 1.3 expands AI Copilot capabilities for enterprise teams with better governance and day-to-day usability:

• RBAC control - A new permission lets enterprise administrators allow or disallow AI Copilot usage by role.
• Wider product coverage - AI Copilot is now available in apps, unit tests, and dashboards.
• Speech-to-text input - A new button lets users dictate prompts directly in the UI.
• Model selection in UI - You can configure multiple models and let users choose the right one from a dropdown.
• Custom model configuration improvements - Custom model setup now supports request headers and timeout configuration.

kestractl

Teams often need to automate flow deployment and operations across multiple environments, but relying only on the UI or custom API scripts is error-prone and inconsistent. A dedicated CLI makes those workflows repeatable in local and CI environments. The same commands work locally and in CI, which closes the gap between how developers deploy locally and how CI deploys to production.

Kestra 1.3 introduces kestractl, a command-line interface focused on API-driven workflow operations.

Use kestractl to interact with the Kestra host API for flows, executions, namespaces, and namespace files.

For server components, plugins, and system maintenance commands, see the Kestra Server CLI.

The Kestra Server CLI is the original CLI many teams already know and trust, and it remains the right choice for server administration. Kestractl is the new companion focused on direct host operation.

Installation

curl -fsSL https://raw.githubusercontent.com/kestra-io/kestractl/main/install-scripts/install.sh | bash

Quick Setup

Configure your Kestra instance and credentials:

# Enterprise (API token)
kestractl config add default https://kestra.example.com production --token YOUR_TOKEN --default

# Open Source (basic auth)
kestractl config add default http://localhost:8080 main --username YOUR_USERNAME --password YOUR_PASSWORD --default

You can manage multiple contexts (dev, staging, prod) and switch between them with kestractl config use.

Key Capabilities

• flows — list, get, deploy (single file or directory), and validate flows
• executions — trigger executions and wait for completion
• namespaces — list and filter namespaces
• nsfiles — list, get, upload, and delete namespace files
• config — manage multiple authentication contexts

# Deploy all flows in a directory to the prod namespace
kestractl flows deploy ./flows --namespace prod --override --fail-fast

# Trigger a flow and wait for completion, output as JSON
kestractl executions run prod nightly-refresh --wait --output json

# Sync namespace files
kestractl nsfiles upload prod ./assets --path resources --override

kestractl vs Kestra Server CLI

In short, use kestractl for API-level resource management and automation, and use the Kestra Server CLI for server, process, or database operations. See the full kestractl reference and Kestra Server CLI reference for details.

GitHub Action

Teams often rely on custom scripts to deploy and validate flows in CI, which leads to inconsistent pipelines and hard-to-maintain automation. A dedicated action makes these workflows repeatable across repositories. Flow deployments go through the same review and automation as application code, rather than being a separate manual step.

Kestra 1.3 introduces a refreshed GitHub Action built on kestractl, so you can reuse the same commands in CI that you run locally. Three composite actions are available:

• validate-flows — validate flow definitions against the Kestra API before deploying
• deploy-flows — deploy flows from a directory, with optional namespace override
• deploy-namespace-files — upload namespace files or folders to a target path

name: Kestra CI/CD
on: [push]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: kestra-io/github-actions/validate-flows@main
        with:
          directory: ./kestra/flows
          server: ${{ secrets.KESTRA_HOSTNAME }}
          apiToken: ${{ secrets.KESTRA_API_TOKEN }}

  deploy:
    runs-on: ubuntu-latest
    needs: validate
    steps:
      - uses: actions/checkout@v4
      - uses: kestra-io/github-actions/deploy-flows@main
        with:
          directory: ./kestra/flows
          server: ${{ secrets.KESTRA_HOSTNAME }}
          apiToken: ${{ secrets.KESTRA_API_TOKEN }}
          override: true

  upload-ns-files:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: kestra-io/github-actions/deploy-namespace-files@main
        with:
          localPath: ./config
          namespace: engineering
          namespacePath: config
          server: ${{ secrets.KESTRA_HOSTNAME }}
          apiToken: ${{ secrets.KESTRA_API_TOKEN }}

Store credentials (KESTRA_HOSTNAME, KESTRA_API_TOKEN) as GitHub Secrets. For Enterprise Edition, supply apiToken and tenant; for Open Source, use user and password instead.

Plugin Defaults UI (Namespace)

Plugin defaults are essential for consistent configurations, but managing them only in YAML makes them harder to discover, edit, and share across teams. This often slows down onboarding and pushes configuration drift into production. New team members can discover and edit defaults from the UI, and the YAML export keeps them versionable.

Kestra 1.3 adds a dedicated Plugin Defaults UI on the namespace page so you can fully manage these settings from the UI while keeping them versionable. Create new defaults with an Add plugin default button, select the plugin from a dropdown, and fill a form that clearly separates required and optional fields, with the option to switch to YAML at any time.

Additional Improvements

• SeaweedFS Internal Storage - Added support for storage-seaweedfs as an internal storage backend, giving teams an OSS-friendly option as the OSS MinIO server repository (minio/minio) is archived and no longer maintained.
• BeyondTrust Secret Manager - Added secret-beyondtrust as a new secret manager integration for secure credential retrieval.
• Kafka Plugin - Added support for Kafka 4.2 queues and share groups to make event processing more reliable, reduce duplicate work, and distribute messages more smoothly across consumers (Consume, Trigger, RealtimeTrigger).

Plugins

Seven new plugins extend Kestra to infrastructure teams managing hardware fleets, VM environments, and cloud networking. These teams typically run that automation through Ansible playbooks, custom scripts, and cron jobs, separate from any data pipeline observability. Running both through Kestra gives infrastructure and data teams shared execution history, logs, and observability.

Infrastructure

• ArgoCD – Automate GitOps delivery by syncing applications and checking sync and health status from ArgoCD inside Kestra workflows (Sync, Status).
• Cloudflare – Manage Cloudflare resources including DNS records, cache purging, WAF IP access rules, Workers KV storage, zones, and namespaces (DNS: Create, Update, Delete, Get, List, Upsert, Batch; cache: Purge; WAF access rules: Create, Delete, List; Workers KV: Get, Write; compute namespaces: Create; zones: Get, List).
• Canonical MAAS – List machines, enlist servers, commission hardware, deploy OS images, and control power states (on/off/cycle/query) for end-to-end bare-metal lifecycle automation (ListMachines, EnlistMachine, CommissionMachine, DeployMachine, PowerControlMachine).
• KVM – Manage virtualization workloads and automate VM operations on KVM, including listing VMs, creating and updating VM definitions, starting and stopping instances, and deleting domains with optional storage cleanup (ListVms, CreateVm, UpdateVm, StartVm, StopVm, DeleteVm).
• NetBox – Integrate your infrastructure source of truth (DCIM/IPAM) into orchestration workflows, including listing sites and devices, creating and updating device records, and assigning IP addresses (ListSites, ListDevices, CreateDevice, UpdateDevice, AssignIpAddress).
• Nutanix – Manage AHV VM lifecycle and recovery workflows on hyper-converged infrastructure, including VM listing, creation, updates, start/stop/reboot/reset operations, cloning and template conversions, plus snapshot creation, listing, restore, and cleanup (ListVms, CreateVm, UpdateVm, StartVm, StopVm, RebootVm, ResetVm, DeleteVm, CloneVm, CloneTemplate, ConvertVmToTemplate, ConvertTemplateToVm, CreateVmSnapshot, ListVmSnapshots, RestoreVmSnapshot, DeleteVmSnapshot).

Observability & Governance

• Graylog – Export Kestra execution logs to Graylog GELF HTTP inputs for centralized observability and SIEM workflows, with configurable host, batching, and HTTP client settings (LogExporter).
• Open Policy Agent – Add policy-as-code checks for governance and compliance by uploading, listing, compiling, evaluating, and deleting OPA policies and decisions (Upload, List, Compile, Evaluate, Delete).

Data & Automation

• Beam – Orchestrate Apache Beam jobs for unified batch and streaming pipelines, with YAML-based execution across Java and Python SDKs on Direct, Flink, Spark, and Dataflow runners (RunPipeline).
• COBOL – Run and orchestrate legacy IBM i COBOL workloads by compiling programs from inline or stored source, executing jobs synchronously with parameters, and submitting batch jobs asynchronously (CreateProgram, CallJob, SubmitJob).
• Slack App – Full Slack App integration to manage channels, messages, canvases, files, reactions, and users directly from workflows, with an event trigger for real-time Slack activity.
• Trello – Automate Trello card workflows from Kestra by creating, updating, moving, and commenting on cards, and by polling boards or lists for new and updated card activity (Create, Update, Move, Comment, Trigger).
• AI Plugin - Added Langfuse observability support to AIAgent via OpenTelemetry OTLP with opt-in export of traces, spans, and metadata (flow/task/execution context, provider/model attributes, prompt/output capture), enabling teams to monitor and debug AI agent behavior in production workflows.

LTS and Enterprise Licensing

• LTS (Long-Term Support): Kestra 1.3 is an LTS release, which means one year of support with security and bug-fix backports. LTS releases are promoted every ~6 months and are recommended for production. As described in our Releases & LTS policy, Kestra 1.0 support is planned to end in September 2026, and Kestra 1.3 will be supported for one year from its release date.
• Enterprise licensing: Enterprise users need a new license for 1.3. To prevent mismatches, new 1.3 Enterprise instances will not start with older licenses. Our Customer Success team has already reached out to customers with upgrade guidance.

Next Steps

This post highlighted the new features and enhancements introduced in Kestra 1.3. Which updates are most exciting to you? Are there additional capabilities you’d like to see in future releases? We welcome your feedback.

If you have any questions, reach out via Slack or open a GitHub issue.

If you like the project, give us a GitHub star and join the community.