triggers skill

Overview

This skill documents how to configure and manage Windmill triggers that let external events invoke your scripts and flows. It explains filename conventions and the CLI commands used to push and pull trigger configurations. Use it to standardize trigger files and automate deployments in self-hosted or team environments.

How this skill works

Triggers are defined as YAML files named with a path and trigger type suffix (for example, .http_trigger.yaml). The runtime watches these files; when synced, Windmill registers them so external systems (HTTP, Kafka, Postgres CDC, etc.) can invoke scripts or flows. Use the CLI to push local trigger configs to the platform or pull existing configs for local editing.

When to use it

• When adding webhooks or HTTP endpoints to invoke flows
• When configuring message consumers (Kafka, SQS, etc.)
• When setting up change-data-capture triggers for databases (Postgres CDC)
• When syncing trigger definitions between local and remote environments
• When standardizing deployment of triggers across teams

Best practices

• Name files using the pattern {path}.{trigger_type}_trigger.yaml to keep triggers discoverable
• Keep trigger files in source control and treat them as code for traceability
• Use wmill sync push to deploy trigger changes and wmill sync pull to fetch remote updates before editing
• Validate trigger YAML locally before pushing to avoid runtime errors
• Group related triggers under a consistent folder structure (u/ for user, f/ for flows)

Example use cases

• Expose a script as a webhook with u/user/webhook.http_trigger.yaml to receive HTTP POSTs
• Create a Kafka consumer with f/data/kafka_consumer.kafka_trigger.yaml to process streaming messages
• Set up f/sync/postgres_cdc.postgres_trigger.yaml to react to row changes in a Postgres table
• Keep environment-specific differences in CI/CD so wmill sync push deploys the correct trigger set

FAQ