Triggers
DevOps & SecuritytriggersTriggers is an Agent Skill for devops & security published in the windmill-labs/windmill repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.
MUST use when configuring triggers.
How to use this skill
Bring this guide into your coding agent with a prompt tailored to the tool you use.
- Open your project in Codex.
- Copy and paste the prompt below.
- Review files and risks before approving any action.
Inspect the Agent Skill at https://github.com/windmill-labs/windmill/blob/HEAD/system_prompts/auto-generated/skills/triggers/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/triggers, but wait for my approval before writing files or running scripts.
Copying this prompt does not install or run the skill. Review third-party files before use.
Windmill Triggers
Triggers allow external events to invoke your scripts and flows.
File Naming
Trigger configuration files use the pattern: {path}.{trigger_type}_trigger.yaml
Examples:
u/user/webhook.http_trigger.yamlf/data/kafka_consumer.kafka_trigger.yamlf/sync/postgres_cdc.postgres_trigger.yamlf/inbound/orders.email_trigger.yaml
Email Triggers
An email trigger routes incoming emails to a script or flow. Each trigger reserves a local-part: emails sent to <local_part>@<windmill_email_domain> are delivered to the configured runnable. Set workspaced_local_part: true to namespace it per workspace (the actual recipient becomes <workspace_id>-<local_part>@…); on Windmill Cloud this is required.
Senders may append URL-style extras to the local-part with +: mytrigger+foo=bar+baz=qux@…. They flow through to the script as email_extra_args (see below).
Payload
The runnable receives:
parsed_email—{ headers, text_body, html_body, attachments[] }. Eachattachmenthas{ headers, body }.raw_email— the raw RFC 822 message as a string, or an S3 object ({ s3: "windmill_emails/<job_id>/raw.eml" }) if the message exceeds 1 MiB.email_extra_args(optional, only when sender appended+key=valueextras) — a flat object of the parsed extras.
With a preprocessor, all of the above are nested under event along with event.kind = "email" and event.trigger_path (the trigger's path). Without a preprocessor, trigger_path is not exposed — add a preprocessor if you need it.
Attachments are S3 objects
Binary attachments are uploaded to the workspace S3 bucket and surface in parsed_email.attachments[i].body as:
{ "s3": "windmill_emails/<job_id>/attachments/<filename>" }
To read the bytes inside a script, use the wmill SDK:
// TypeScript
import * as wmill from "windmill-client"
const file = await wmill.loadS3File(parsed_email.attachments[0].body)
# Python
import wmill
data = wmill.load_s3_file(parsed_email["attachments"][0]["body"])
If the workspace has no S3 resource configured (Workspace Settings → Object storage), body falls back to the string "configure s3 in the workspace settings to handle attachments". The same applies to large raw_email bodies. Email attachment storage requires the server to be built with the parquet feature.
Text/HTML/inline parts are placed inline in body as strings.
CLI Commands
wmill sync push deploys local changes to the workspace and can be destructive to remote state — only suggest/run it when the user explicitly asks to deploy/publish/push, not when they say "run", "try", or "test". sync pull is safe to run yourself — it never mutates remote state, though it does overwrite local files to match the remote (use sync pull --dry-run to only preview).
# Push trigger configuration — only when the user explicitly asks to deploy
wmill sync push
# Pull triggers from Windmill
wmill sync pull