GO — Healthy across the board

• Last commit today
• 19 active contributors
• Distributed ownership (top contributor 26% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Kestra is an open-source, event-driven workflow orchestration and scheduling platform written primarily in Java (8.5MB) with a Vue/TypeScript frontend (3.8MB) that enables users to define, schedule, and execute complex data pipelines and microservice workflows declaratively. It handles both time-based scheduling and event-triggered automation for mission-critical applications through a unified platform. Monorepo structure: root build.gradle orchestrates subprojects including :cli (main entry point io.kestra.cli.Kestra), backend services, and frontend (Vue in typescript under separate build). Kubernetes deployment via Helm charts in /charts/kestra-starter/. DevOps tooling in .devcontainer/ for standardized development environments. CI/CD automation across .github/workflows/ triggers on PR, merge, and release events.

Data engineers, DevOps teams, and platform engineers who need to orchestrate ETL pipelines, microservices, and scheduled jobs without building custom orchestration infrastructure. Users working with Kubernetes, Docker, and cloud-native environments who want Infrastructure as Code practices applied to workflow definitions.

Kestra is actively developed and production-ready: the repository shows strong activity with recent commits across multiple workflows (.github/workflows/ has 15+ automation files), comprehensive CI/CD setup (pull-request.yml, main-build.yml, e2e-scheduling.yml), and established release processes (global-create-new-release-branch.yml, helm-release.yml). The project has GitHub stars prominence mentioned in README and uses semantic versioning with pre-release management.

Dependencies are well-managed through Gradle with OWASP dependency checking (org.owasp.dependencycheck version 12.2.2 enabled), but the large Java codebase (8.5MB) means significant maintenance surface. The monolithic architecture mixing orchestration engine, CLI, and UI increases complexity; breaking changes could affect users across the full stack. Single release coordination across Java backend, Vue frontend, Helm charts, and Docker images requires careful version management.

Active development with multiple concurrent workflows: main build pipeline (main-build.yml), pull request validation (pull-request.yml), scheduled e2e testing (e2e-scheduling.yml), automated UI translation (auto-translate-ui-keys.yml), and dependency management (dependabot.yml, vulnerabilities-check.yml). Release infrastructure is sophisticated with separate pre-release, docker, and Helm release pipelines indicating frequent versioning.

Clone and build: git clone https://github.com/kestra-io/kestra.git && cd kestra && ./gradlew build. The Makefile and build.gradle handle Java compilation (toolchain Java 25 required). Use devcontainer setup with devcontainer open .devcontainer for standardized environment, or manually: ./gradlew run (see Makefile for additional targets).

Daily commands: Dev server: ./gradlew run (uses mainClass = io.kestra.cli.Kestra). Frontend development likely via npm within the frontend subproject. Full stack: Docker compose or devcontainer (see .devcontainer/devcontainer.json). Docker image build: docker build -t kestra:latest . then docker run with appropriate config volume mounts.

• build.gradle — Root build configuration defining all dependencies, plugins (Micronaut, Gradle Shadow, SonarQube), and multi-project structure for orchestration platform
• cli/src/main/java/io/kestra/cli/Kestra.java — Main CLI entry point; orchestrates command routing and initialization for the event-driven scheduling platform
• .github/workflows/main-build.yml — Primary CI/CD pipeline defining build, test, and deployment stages for every commit
• cli/src/main/java/io/kestra/cli/StandAloneRunner.java — Core runner enabling standalone execution mode; essential for understanding how flows execute outside distributed cluster
• charts/kestra/templates/deployment.yaml — Helm deployment template; defines Kubernetes production deployment topology and resource requirements
• README.md — High-level project overview describing event-driven orchestration capabilities and getting started guidance
• Dockerfile — Production Docker image definition; entrypoint for containerized deployments of the orchestration platform

Add a New CLI Command

1. Create command class extending AbstractCommand or AbstractApiCommand in appropriate subdirectory under cli/src/main/java/io/kestra/cli/commands/ (cli/src/main/java/io/kestra/cli/commands/flows/FlowCommand.java)
2. Use @Command annotation from Picocli with name, description, and options/parameters (cli/src/main/java/io/kestra/cli/commands/configs/sys/ConfigCommand.java)
3. Implement run() or call() method with command logic, inheriting configuration from BaseCommand (cli/src/main/java/io/kestra/cli/BaseCommand.java)
4. Register command in Kestra.java main class via @Command subcommands array (cli/src/main/java/io/kestra/cli/Kestra.java)

Add a New Flow Type or Task Plugin

1. Define plugin in separate namespace under cli/src/main/java/io/kestra/cli/ following existing plugin patterns (cli/src/main/java/io/kestra/cli/commands/flows/FlowCommand.java)
2. Implement task execution logic with proper error handling and state transitions (cli/src/main/java/io/kestra/cli/StandAloneRunner.java)
3. Add task configuration schema and validation in FlowTestCommand or similar validation class (cli/src/main/java/io/kestra/cli/commands/flows/FlowTestCommand.java)
4. Update build.gradle to add plugin dependencies if external integrations required (build.gradle)

Deploy to Kubernetes Cluster

1. Customize Helm values in charts/kestra/values.yaml for resource limits, replicas, and environment-specific config (charts/kestra/values.yaml)
2. Configure application properties via charts/kestra/templates/configmap.yaml for database, executor, and plugin settings (charts/kestra/templates/configmap.yaml)
3. Define pod specifications and security context in charts/kestra/templates/deployment.yaml (charts/kestra/templates/deployment.yaml)
4. Run: helm install kestra ./charts/kestra -n kestra --values custom-values.yaml to deploy to cluster (charts/kestra/Chart.yaml)

Add a New Migration or Data Update

1. Create migration command class extending or similar to V2ExecutionResubmitMigrationCommand under cli/src/main/java/io/kestra/cli/commands/migrations/ (cli/src/main/java/io/kestra/cli/commands/migrations/V2ExecutionResubmitMigrationCommand.java)
2. Implement migration logic with rollback support and progress tracking (cli/src/main/java/io/kestra/cli/commands/migrations/MigrationCommand.java)
3. Register migration in MigrationCommand base class discovery mechanism (cli/src/main/java/io/kestra/cli/commands/migrations/RunMigrationCommand.java)
4. Test migration with RunMigrationCommand before production deployment (cli/src/main/java/io/kestra/cli/commands/migrations/RunMigrationCommand.java)

• Gradle with shadow plugin — Multi-project build system enabling modular CLI and server components; shadow creates fat JARs for standalone distribution
• Picocli for CLI — Modern command-line framework providing auto-completion, help generation, and structured command hierarchy
• Micronaut framework — Lightweight JVM framework optimized for microservices with minimal startup time and memory footprint for containerized deployments
• Helm charts — Kubernetes package manager enabling templated, environment-agnostic deploy

Java 25 toolchain is required (toolchain { languageVersion = JavaLanguageVersion.of(25) }); building with older Java will fail. Frontend build is integrated via com.github.node-gradle.node plugin—Node/npm must be available or explicitly managed. Shadow JAR plugin (com.gradleup.shadow) creates fat JARs; understand packaging when debugging classpath issues. Gradle wrapper is implicit but essential. Database migrations (PLpgSQL files present) suggest PostgreSQL dependency for state management—ensure it's running for local development. Pre-commit hooks in .github/.hooks/setup_hooks.sh must be initialized manually.

• Event-Driven Orchestration — Core Kestra differentiator allowing workflows to trigger on external events (Kafka, webhooks, file uploads) not just schedules—essential for reactive data platforms
• Infrastructure as Code (IaC) — Kestra uses declarative YAML for workflow definitions rather than imperative code, enabling versioning, CI/CD integration, and GitOps practices for orchestration logic
• Directed Acyclic Graph (DAG) — Underlying execution model for task dependencies; workflows are compiled to DAGs for parallel execution and dependency resolution
• Container Orchestration — Kestra executes tasks in containerized environments (Docker, Kubernetes) enabling reproducible, isolated workload execution across platforms
• State Management & Persistence — PostgreSQL backing (PLpgSQL migrations present) enables durable state tracking, execution history, and failure recovery—critical for mission-critical workflows
• Shadow JAR / Fat JAR Packaging — com.gradleup.shadow plugin creates self-contained JARs with all dependencies—necessary for simple deployment without external classpath management
• Helm Package Management — Kestra uses Helm Charts (charts/kestra-starter/) for Kubernetes deployment templates, enabling reproducible infrastructure provisioning and version-controlled deployments

• apache/airflow — Direct competitor: DAG-based orchestration platform; differs in event-driven approach and declarative YAML-first design vs. Airflow's Python-first paradigm
• prefecthq/prefect — Alternative orchestration platform with modern Python-based approach; Kestra targets broader use cases including non-Python workloads and event triggers
• dbt-labs/dbt-core — Complementary ecosystem tool for data transformation; users often orchestrate dbt runs via Kestra for full data pipeline automation
• kubernetes/kubernetes — Underlying infrastructure for cloud-native deployments; Kestra targets Kubernetes-native orchestration with Helm charts and container-first architecture
• hashicorp/nomad — Alternative workload orchestrator; Kestra is workflow-focused while Nomad is general-purpose infrastructure scheduling

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive GitHub Actions workflow for dependency vulnerability scanning in pull requests

The repo has .github/workflows/vulnerabilities-check.yml but no dedicated PR workflow that runs OWASP dependency checks on PRs before merge. Given the Gradle build includes org.owasp.dependencycheck plugin (version 12.2.2) and .dependabot.yml exists, a PR-specific workflow would catch vulnerabilities early and prevent supply chain risks in this mission-critical orchestration platform.

• [ ] Create .github/workflows/owasp-dependency-check-pr.yml that runs dependencycheck task on PRs
• [ ] Configure the workflow to fail the PR if vulnerabilities above a severity threshold are found
• [ ] Reference the existing build.gradle OWASP plugin configuration and integrate with Dependabot alerts
• [ ] Add step to upload SARIF reports to GitHub Security tab for visibility
• [ ] Test against a PR to ensure it properly gates merges

Add integration tests for Helm chart deployments in CI/CD pipeline

The repo contains two production Helm charts (charts/kestra/ and charts/kestra-starter/) with templates for StatefulSet, ConfigMap, Ingress, and Secrets, but there's no dedicated workflow to validate Helm chart syntax, template rendering, or Kubernetes manifest validity. .github/workflows/helm-release.yml exists but a separate PR validation workflow is missing.

• [ ] Create .github/workflows/helm-chart-validation.yml that runs on PRs touching charts/ directory
• [ ] Add steps using helm lint for both charts/kestra and charts/kestra-starter with custom values
• [ ] Add helm template rendering tests to catch manifest generation errors
• [ ] Integrate kubeval or kube-score to validate generated Kubernetes manifests
• [ ] Test with sample values.yaml overrides to catch common configuration mistakes

Add pre-commit hook validation for codespell and Spotless formatting enforcement

The repo has .codespellrc, .github/.hooks/pre-commit, and io.kestra.gradle.spotless-conventions plugin configured, but the pre-commit hook setup in .github/.hooks/ is incomplete. New contributors often miss running formatters locally, causing CI failures on .github/workflows/codespell.yml and formatting checks.

• [ ] Enhance .github/.hooks/pre-commit to run ./gradlew spotlessCheck before commit
• [ ] Add codespell validation to the hook (reference .codespellrc configuration)
• [ ] Update .github/.hooks/setup_hooks.sh to make hook installation simple for new contributors
• [ ] Document hook installation in CONTRIBUTING.md (currently exists but hook setup is underdocumented)
• [ ] Add validation that hook files are executable and update .gitattributes if needed

• Add integration tests for the new task types by examining existing test patterns in the test suite and creating parallel test coverage for underrepresented orchestration scenarios
• Improve documentation for the CLI command structure by generating help text from the codebase (cli subproject) and auto-generating reference docs in a docs/ directory
• Create example workflows in an examples/ directory demonstrating common patterns (Kubernetes job orchestration, multi-step data pipelines, event-driven triggers) with accompanying README guides

• High · Outdated Gradle Dependency Check Plugin — build.gradle - OWASP dependency check plugin. The project uses org.owasp.dependencycheck version 12.2.2. This version may have known vulnerabilities or security issues. The plugin should be regularly updated to detect and warn about vulnerable dependencies in the project. Fix: Update to the latest version of org.owasp.dependencycheck plugin and ensure it is applied to all subprojects. Review and remediate any flagged vulnerabilities in transitive dependencies.
• High · Gradle Shadow Plugin Security Risk — build.gradle - Shadow plugin configuration. The project uses com.gradleup.shadow version 9.4.1 for creating fat JARs. This can inadvertently include vulnerable dependencies or sensitive files in the final artifact if not properly configured with exclusion filters. Fix: Implement strict exclusion rules in the shadow plugin configuration. Exclude unnecessary dependencies, credentials, and configuration files. Regularly audit the generated JAR contents for sensitive data.
• High · Insecure Docker Image Base - Missing Security Patches — Dockerfile - FROM eclipse-temurin:25-jre. The Dockerfile uses 'eclipse-temurin:25-jre' as a base image without pinning to a specific digest. Additionally, while apt-get upgrade is performed, the image may still contain unpatched vulnerabilities depending on the base image's build date. Fix: Pin the base image to a specific digest hash (e.g., 'eclipse-temurin:25-jre@sha256:...') to ensure reproducible, immutable builds. Use automated image scanning tools in CI/CD to detect vulnerabilities in the base image.
• Medium · Insecure Package Installation from External Source — Dockerfile - curl -LsSf https://astral.sh/uv/0.6.17/install.sh | sh. The Dockerfile downloads and executes a shell script directly from astral.sh to install 'uv'. This is a security risk as it downloads executable content from the internet without verification. Fix: Verify the integrity of downloaded scripts using checksums or GPG signatures. Consider pre-installing the tool in the base image or using a package manager. If using curl | sh, validate the script source and implement signature verification.
• Medium · User Account with Write Access to Application Directory — Dockerfile - useradd -m -g kestra kestra and chown -R kestra:kestra /app. The 'kestra' user is created with home directory (-m flag) and has full ownership of /app directory. If compromised, an attacker gains persistent write access to the application directory. Fix: Review if the kestra user needs write access to /app. Consider creating separate read-only and writable directories. Use capability restrictions and seccomp profiles to limit the user's system access. Run with a non-root, unprivileged user (already done).
• Medium · Missing Security Headers in Helm Chart — charts/kestra/templates/deployment.yaml and charts/kestra/templates/statefulset.yaml. The Helm chart templates do not appear to include security context definitions (securityContext, capabilities, readOnlyRootFilesystem, runAsNonRoot) in the statefulset and deployment configurations. Fix: Add comprehensive securityContext definitions including: runAsNonRoot: true, runAsUser: non-zero, readOnlyRootFilesystem: true (if applicable), capabilities.drop: [ALL], allowPrivilegeEscalation: false. Add network policies and pod security policies.
• Medium · Incomplete Security Policy Documentation — SECURITY.md - Incomplete policy. The SECURITY.md file is incomplete (ends abruptly mid-sentence). The security policy lacks details on security update timelines, patch management procedures, and vulnerability severity classifications. Fix: Complete the security policy document with: clear vulnerability disclosure timeline, SLA for security patches, supported version matrix with EOL dates, security scanning procedures, and incident response procedures.
• Medium · Dynamic Plugin Installation with Untrusted Sources — Dockerfile - ARG. The Dockerfile allows installation of arbitrary Kestra plugins via the KESTRA_PLUGINS build argument without validation. Malicious plugins could be installed and executed with application privileges. Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/kestra-io/kestra shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live kestra-io/kestra repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/kestra-io/kestra.

What it runs against: a local clone of kestra-io/kestra — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in kestra-io/kestra | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch develop exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of kestra-io/kestra. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/kestra-io/kestra.git
#   cd kestra
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of kestra-io/kestra and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "kestra-io/kestra(\\.git)?\\b" \\
  && ok "origin remote is kestra-io/kestra" \\
  || miss "origin remote is not kestra-io/kestra (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify develop >/dev/null 2>&1 \\
  && ok "default branch develop exists" \\
  || miss "default branch develop no longer exists"

# 4. Critical files exist
test -f "build.gradle" \\
  && ok "build.gradle" \\
  || miss "missing critical file: build.gradle"
test -f "cli/src/main/java/io/kestra/cli/Kestra.java" \\
  && ok "cli/src/main/java/io/kestra/cli/Kestra.java" \\
  || miss "missing critical file: cli/src/main/java/io/kestra/cli/Kestra.java"
test -f ".github/workflows/main-build.yml" \\
  && ok ".github/workflows/main-build.yml" \\
  || miss "missing critical file: .github/workflows/main-build.yml"
test -f "cli/src/main/java/io/kestra/cli/StandAloneRunner.java" \\
  && ok "cli/src/main/java/io/kestra/cli/StandAloneRunner.java" \\
  || miss "missing critical file: cli/src/main/java/io/kestra/cli/StandAloneRunner.java"
test -f "charts/kestra/templates/deployment.yaml" \\
  && ok "charts/kestra/templates/deployment.yaml" \\
  || miss "missing critical file: charts/kestra/templates/deployment.yaml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/kestra-io/kestra"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.