Hi! I'm your Kestra AI assistant. Ask me anything about workflows.
EXAMPLE QUESTIONS
How to trigger a flow after another one?
How to run dbt?
How to write expression for previous tasks outputs?
Add state, gates, and visibility to Ansible.
Run ansible-playbook from cron, webhooks, or any HTTP signal. Add step-level retries, parsed per-host results via the Kestra callback, approval gates between waves, and chain Ansible with Terraform, NetBox, or ServiceNow in one execution history.
Replace Ansible Tower / AAP with a workflow engine that listens to cron, webhooks, or alerts, handles drift detection and rolling waves with per-host verification, and chains ansible-playbook with Terraform, NetBox, and ServiceNow. Drop the AAP subscription; halt a wave at the first failed health probe.
Nightly check-mode audit with the Kestra Ansible callback
Open blueprint
Rolling OS patch wave with serial and per-batch health probe
Open blueprint
Build inventory from NetBox at run time, then play against it
Open blueprint
Around every playbook, every host, every wave.
What Kestra wraps around your Ansible runs: when playbooks fire, what comes back per host through the callback, who approves the next wave, and where the audit lives. Your playbooks, roles, inventory, and Vault stay where they are.
Schedule and event triggers wrapped around ansible-playbook
Native cron, fixed intervals, webhooks, S3 file arrivals, Kafka messages, and database row changes all fire ansible-playbook directly. The trigger payload reaches the flow as trigger.body, so the right host gets the right --extra-vars from a single execution. No AWX, no Tower, no EDA controller.
Check mode + diff mode as drift detection
Run the playbook with --check --diff on a nightly schedule. The Kestra Ansible callback emits per-host changes, the flow surfaces only the hosts that drifted, and the diff lands in Slack. No enforcement, no surprises, the whole fleet audited overnight.
Inventory built at run time from Terraform, NetBox, or vCenter
A terraform output, a NetBox API call, or vmware.vcenter.ListVms writes the inventory at the start of the flow. The next task templates it into inventory.ini. No stale static inventory file, no manual sync between source of truth and what Ansible reads.
Per-host results from the Kestra Ansible callback, iterable in YAML
The Kestra Ansible callback emits structured per-host outputs after each play. A ForEach task loops over the hosts and branches on changed, failed, or any fact. Route alerts by tag, hand failing hosts to a remediation flow, or upload the play recap to S3.
Rolling restarts with serial + health verification between batches
Set serial: 1 (or 10%) in the play. The playbook runs against one batch at a time. Between batches, a Kestra HTTP probe checks the service is healthy. A failed probe halts the flow before the next batch, preserving the rest of the fleet.
Replay any host from any past execution
Every play, every host, every task output is stored per execution. Open last week's run, click into the failing host, replay that step against the same target. The original inventory, vars, and ansible.cfg are preserved with the run, so the replay matches the original conditions.
How platform teams use Ansible and Kestra
Patterns infrastructure teams run in production today. Each one shows the flow end to end, with the real plugin classes in play.
Drift detection
Nightly check-mode audit, alert only on drift
Run the playbook with --check --diff against the fleet on a nightly schedule. The Kestra Ansible callback emits structured per-host output. A ForEach loops through hosts and posts a Slack alert only when a host comes back with changed: true. Clean runs stay quiet, the play recap stays attached to the execution for audit.
Check mode runs are non-destructive
--check + --diff reports what would change without touching the host.
Callback emits structured outputs
The Kestra Ansible callback writes per-host JSON the flow can iterate with ForEach.
Alert only on changed=true
Keeps Slack quiet on clean nights, surfaces only the hosts that drifted.
Full play recap stored per run
Every nightly audit is timestamped, attributed, and replayable from the execution UI.
What you get
Published as the ansible-config-drift blueprint in the Kestra catalog.
cron trigger
nightly
ansible-playbook --check
diff mode
ForEach host
per-host change?
alert
only on drift
Rolling wave
Rolling OS patch wave with serial + HTTP health probe between batches
ansible-playbook with serial: 1 patches one host at a time. Between batches, a Kestra core.http.Request task probes the application health endpoint. If the probe fails, the flow halts before the next batch and pages on-call. No half-broken fleet, no manual stop-the-pipeline.
serial picks the batch size
serial: 1, serial: 10%, or a mix. Ansible enforces the batching, Kestra runs the verify task per batch.
HTTP probe gates the next batch
core.http.Request with a retry policy decides whether the wave continues.
Halt on failure preserves the rest of the fleet
The flow exits before the next batch, the unpatched hosts stay on the old version.
Per-batch execution log
Each batch has its own log line in the execution, with the host list and the probe result.
patch window
scheduled
ansible-playbook serial: 1
one host at a time
ForEach host
verify between batches
health probe
halt on fail
notify
Slack on halt
Event-driven
Event-triggered remediation from monitoring alerts
A Splunk or CloudWatch alert fires on high CPU or a failed health check. The webhook hits Kestra, Kestra runs the remediation playbook against the affected host (inline inventory built from the alert payload), updates the ServiceNow incident with the playbook output, and posts to Slack. Same flow, same audit trail, whether the alert fires once a week or a hundred times a day.
Webhook + API triggers
Fire a playbook from Splunk, PagerDuty, ServiceNow, or any HTTP source. No glue service required.
Inline inventory from alert payload
The host name from trigger.body becomes a one-line inventory.ini, scoped to the affected host only.
Incident enrichment
Push the playbook's diagnostic output back into the ServiceNow ticket as a work note.
Replay on the same host
Re-run the playbook against the original target with one click from the execution view.
webhook
alert payload
ansible-playbook
remediate host
ServiceNow
update incident
notify
Slack
Dynamic inventory
Inventory from NetBox or Terraform output, then play against it
terraform output or a NetBox device query emits the inventory at the start of the flow. The next task templates it into inventory.ini (or hands it as a JSON dynamic inventory). The playbook runs against the freshly resolved hosts. No stale static inventory file, no manual sync between source of truth and Ansible.
Single source of truth
The inventory comes from the tool that actually knows the hosts: Terraform state, NetBox DCIM, or a cloud API.
Templated into inventory.ini per run
Inline inputFiles writes the inventory from outputs.fetch_inventory at the start of the playbook task.
Refresh per execution
Every run sees the current state, not yesterday's snapshot.
trigger
schedule or webhook
fetch inventory
Terraform / NetBox
ansible-playbook
fresh inventory
ForEach host
per-host result
ServiceNow
CMDB reconcile
The orchestration of Ansible is very poor compared to what we can do with Kestra. I doubt that we can only use Terraform and Ansible to do all our complex orchestration.
Find answers to your questions right here, and don't hesitate to Contact Us if you couldn't find what you're looking for.
Run the playbook with --check --diff on a schedule. The Kestra Ansible callback (stdout_callback = yaml plus the Kestra-specific output) emits per-host JSON. A ForEach task iterates over the hosts and branches on changed. The flow only alerts when a host actually drifted, so clean enforcement nights stay quiet. The full diff and recap are stored as task artifacts on the execution.
Kestra's Pause task suspends the flow after a wave completes. The playbook output is surfaced in the Kestra UI. A named reviewer reads it, optionally adds a comment, and resumes. Only then does the next wave run. The reviewer identity and timestamp land in the execution history. Different reviewers can be wired to different namespaces or environments through RBAC.
Yes. Set serial: 1 (or 10%) in the play. Ansible enforces the batching. After the playbook task returns, a Kestra ForEach loops over the per-host callback output and a core.http.Request probes each host's health endpoint with a retry policy. A failed probe halts the flow before the next wave, so the rest of the fleet stays on the old version.
AAP is the Red Hat-owned operational layer for Ansible: a runner, a UI, surveys, RBAC, and the EDA controller for event triggers. Kestra is a general-purpose orchestrator. It schedules playbook runs, adds native pause-and-resume between waves, parses per-host results via the Kestra Ansible callback, and chains Ansible with Terraform, ServiceNow, NetBox, ArgoCD, and your own scripts in one flow. AAP is Ansible-centric by design. Kestra works alongside AAP if you already run it, or replaces it when you want one orchestrator across the full stack.
Yes. The io.kestra.plugin.ansible.cli.AnsibleCLI task runs ansible-playbook exactly as you do today. Inventory, roles, vars, Vault files, and ansible.cfg stay where they are. You point Kestra at the playbook through inline inputFiles, Namespace Files, or a Git clone task. Nothing in the playbook itself changes.
Yes. Vault files come through Kestra's secrets backend (built-in or HashiCorp Vault) and are mounted into the task working directory at run time. Dynamic inventories work the same way they do on the CLI: include the script or plugin in the task, set the inventory path, and run ansible-playbook -i against it. Inventories built from a Terraform output or a NetBox query at the start of the flow are a common pattern, see the dynamic-inventory blueprint above.
Yes. The io.kestra.plugin.core.trigger.Webhook trigger exposes a signed endpoint. Wire Splunk, PagerDuty, ServiceNow, or any HTTP source to that URL. The alert payload is available in the flow as trigger.body, so the playbook runs against the right host with the right inputs.
No. Kestra runs ansible-playbook directly through its task runner, on the worker, in a container, or remotely via SSH. No AWX, no Tower, no EDA controller. Teams already on AAP can keep it: Kestra calls AAP jobs over the API the same way it calls Terraform or Jenkins.
Kestra ships self-hosted on Docker or Kubernetes, as a managed cloud, or air-gapped for regulated environments. The open-source edition includes unlimited workflows and event-driven triggers. Self-hosted gives full control over where playbooks execute, with no external dependency on Kestra's infrastructure. See Kestra for infrastructure automation for the broader picture across Terraform, Ansible, and cloud APIs.
Drive check-mode drift detection, gate patch waves, build inventory from Terraform or NetBox, and parse per-host results with the Kestra Ansible callback. Open source, self-hosted, event-driven.