Dispatch a workflow_dispatch from cron, S3 events, Kafka messages, dbt completions, or any HTTP signal. Pass typed inputs, listen for the workflow_run webhook back, auto-open issues on flow failure, and chain Actions output with Terraform, dbt, or ServiceNow in one execution history.
Replace cron triggers and reusable workflow YAML with a workflow engine that fires workflow_dispatch on dbt completions, S3 events, or Kafka messages, handles cross-repo dispatch with approval gates outside the workflow itself, and chains Actions output with Terraform, dbt, and ServiceNow. Dispatch the same workflow across every repo in one ForEach (matrices cannot span repos).
GitHub Actions runs the job inside the runner. Kestra wraps everything around it: when a workflow_dispatch fires, what runs before, who approves the prod deploy, and where the cross-tool audit trail lives once the runner exits. The workflow YAML, the matrix, and the action marketplace stay where they are.
GitHub Actions fires on push, pull_request, schedule, or the workflow_dispatch UI. Kestra fires it on a Kafka message, an S3 file landing, a dbt Cloud job completing, a Fivetran sync, a Pylon ticket, or any HTTP webhook. The actions.RunWorkflow task sends the dispatch with a typed inputs payload, and the workflow YAML stays in the repo where it belongs.
The runner finishes, GitHub sends the workflow_run webhook back to Kestra's Webhook trigger, and the next flow step starts. Outputs from the Actions run, the test artifact, the built image digest, the deployment URL, become inputs to a Terraform apply, a dbt build, a ServiceNow ticket update, or a Slack release note. One execution ID across the chain.
issues.Create opens an issue against the right repo when a critical upstream flow fails, with the execution URL and the failing step in the body. issues.Comment posts test results back to the PR that triggered the original run. pulls.Create raises a PR for auto-generated config changes (rotated secrets, new env values, dependabot-style updates) and waits for review.
repositories.Search returns every repo matching an org + topic + language filter. code.Search finds every file with a pattern. A ForEach iterates over the result and dispatches the same workflow per repo. GitHub Actions matrices cannot span repositories, so security scans, dependency bumps, or compliance checks across 200 repos become one flow definition.
GitHub Environments offer protection rules per environment, but they live inside one workflow definition. Kestra's Pause task gates the dispatch itself: the flow runs pre-flight checks (Trivy scan, Cosign verify, staging tests), surfaces a summary in the Kestra UI with the candidate revision, and pauses. A named reviewer resumes and only then does actions.RunWorkflow fire the prod workflow.
The GitHub Actions tab shows runs in isolation. Kestra shows the whole story: what upstream event fired the workflow, who approved each gate, what the Actions runner produced, what ran after, and which step in the broader pipeline failed. The execution history pages link directly to the Actions run, the Terraform plan, and the ServiceNow ticket created downstream.
Patterns engineering teams ship in production. Each one shows the flow end to end, with the real plugin classes in play.
A dbt Cloud job completes. Kestra picks up the completion via webhook, runs a quick freshness check on the new tables, then fires actions.RunWorkflow against deploy.yml with the new revision as a workflow_dispatch input. GitHub Actions builds, deploys, and sends its workflow_run webhook back. Slack confirms with the deploy URL. The commit that triggered everything is two upstream steps away from the runner.
No git poll, no committed trigger file, no waiting on the next cron. dbt finishes at 11:47, the deploy starts at 11:47.
The new revision, the target environment, and the feature flag set all pass through as named workflow inputs.
GitHub fires workflow_run on completion. Kestra's Pause task resumes when the matching run ID arrives.
Debugging starts in the Kestra UI. The execution links directly to the dbt run, the Actions run, and the Slack message.
A scheduled flow that loads warehouse data fails on the dbt step. The errors branch runs issues.Create against the data-platform repo with the failing step name, the execution URL, the last 50 log lines, and an @-mention for the on-call rotation. The same branch comments on the most recent PR that touched the failing model. Engineers wake up to context, not a paging alert.
The failure happens in the orchestrator. The issue opens in the repo that owns the model. GitHub Actions cannot easily do this across repos.
The issue body has the execution URL, the failing step, the last logs, and a link back to the runtime view in Kestra.
If the failing model was touched in a recent PR, the flow finds it via pulls.Search and posts the same context as a PR comment.
repositories.Search returns every repo in the org tagged platform-service. A ForEach iterates over the result. Per repo, actions.RunWorkflow fires the same security-scan.yml workflow with the scan profile as input. Each workflow_run webhook updates a running summary in Kestra. Slack posts the final report with per-repo pass or fail. GitHub Actions matrices cannot span repositories. Kestra can.
Tag-based, language-based, or topic-based filters in repositories.Search. The list updates itself as repos are added or labeled.
Each dispatched workflow runs in its own repo with the repo's own secrets and runners. Kestra coordinates, GitHub Actions executes.
The flow aggregates per-repo results and posts a single Slack report. The Actions tab in each repo still shows the raw run.
An image lands in the registry. Kestra runs Trivy for critical CVEs and Cosign for signature verify. It pulls the staging workflow_run status via the GitHub API to confirm tests passed there. The summary surfaces in the Kestra UI: scan result, sig status, staging test pass count, candidate digest. A Pause task waits for a named reviewer. On resume, actions.RunWorkflow fires deploy-prod.yml with the verified digest and the reviewer name baked into the workflow input.
GitHub Environments protect deployments inside a workflow. Kestra gates the dispatch itself, so the workflow_run never starts until pre-flight passes and a reviewer resumes.
The Pause output includes the reviewer identity. That value flows into the workflow_dispatch input, so the Actions log shows who approved the release.
Trivy output, Cosign result, staging test summary, and the reviewer signature all live in the Kestra execution. The Actions log links back.
Terraform is quite a big deal for us because that's basically how we work most of the day to roll out changes. Kestra will be the entity to roll out everything. This should resolve the issues we are facing currently with everyone working in parallel.
| Capability | | | Custom webhook listener + GitHub API | |
|---|---|---|---|---|
| Dispatch a workflow from a non-Git event (Kafka, S3, dbt) | Native triggers, actions.RunWorkflow with typed inputs | schedule cron + manual UI dispatch only | Build and host the listener yourself | Still GitHub-internal, no external triggers |
| Capture workflow_run completion in another flow step | Webhook trigger + Pause resume on matching run ID | Not in scope, no external flow | Custom polling against the runs API | Only within the same workflow |
| Dispatch the same workflow across N repos in one run | repositories.Search + ForEach + actions.RunWorkflow | Manual per-repo dispatch | Custom for-loop in your listener | Cannot span repositories |
| Open issues, comment on PRs from the flow | issues.Create, issues.Comment, pulls.Create as flow tasks | Action steps inside the workflow only | Custom code | Inside the workflow only |
| Approval gate before dispatch (not inside workflow) | Pause + resume, named reviewer logged | GitHub Environments protect inside the workflow | Custom approval UI | GitHub Environments inside the called workflow |
| Chain Actions output with non-GitHub tasks | Outputs flow into Terraform, dbt, ServiceNow, Slack tasks | Action steps in the workflow only | Custom code per chain | Same workflow scope |
| One execution history across Actions, dbt, Terraform, ServiceNow | One execution ID, links to each system | Actions tab only | Custom dashboard | Actions tab only |
| Self-hosted, air-gapped, OSS edition | Self-hosted by default, OSS edition free | GHE Actions or hosted runners | Self-hosted | GHE or hosted |
| Beyond GitHub: orchestrate the rest of the stack | 1300+ plugins, cross-stack | GitHub ecosystem only | Whatever you write | GitHub ecosystem only |
Find answers to your questions right here, and don't hesitate to Contact Us if you couldn't find what you're looking for.
Automate infrastructure workflows in Kestra
How Kestra orchestrates GitHub Actions, Terraform, Ansible, Docker, Argo CD, and the rest of the stack in one declarative flow.
Chain GitHub Actions with Argo CD
The common pattern: Kestra fires the CI workflow on event, GitHub Actions builds and signs the image, Kestra fires the Argo CD sync at the verified digest.
GitHub plugin reference
Every GitHub task (actions.RunWorkflow, issues.*, pulls.*, code.Search, repositories.Search) with copy-ready YAML examples and full property reference.
Dispatch workflows from data events instead of commits, gate the prod deploy with a named reviewer, auto-open issues from failed flows, and dispatch the same workflow across every repo with a tag. Open source, self-hosted, event-driven.
