;}%20.st6{fill:url(%23SVGID_00000021089067129159788970000008246765442136188072_);}%20.st7{fill:url(%23SVGID_00000117639240116366130650000015074833605515028638_);}%20.st8{opacity:0.4;fill:url(%23SVGID_00000101781798616409025840000016567063639337360777_);}%20.st9{opacity:0.4;fill:url(%23SVGID_00000052086836598721292040000002033117744178971046_);}%20.st10{opacity:0.4;fill:url(%23SVGID_00000159460939004760751800000002448009281983951536_);}%20.st11{opacity:0.4;fill:url(%23SVGID_00000013177830667419993080000017721442101626521532_);}%20.st12{opacity:0.4;fill:url(%23SVGID_00000152235521444854938490000006526001119318383285_);}%20.st13{opacity:0.4;fill:url(%23SVGID_00000119823135212293698520000012774889010992664993_);}%20%3c/style%3e%3cg%3e%3cpolygon%20class='st2'%20points='134.78,14.22%20114.31,48.21%20101.33,69.75%20158.22,69.75%20177.97,36.95%20191.67,14.22%20'/%3e%3cpolygon%20class='st3'%20points='227.55,69.75%20186.61,69.75%20101.33,69.75%20129.78,119.02%20158.16,119.02%20228.61,119.02%20256,119.02%20'/%3e%3cpolygon%20class='st3'%20points='136.93,132.47%20116.46,167.93%2073.82,241.78%20130.71,241.78%20144.9,217.2%20180.13,156.18%20193.82,132.46%20'/%3e%3cpolygon%20class='st3'%20points='121.7,131.95%20101.23,96.49%2058.59,22.63%2030.15,71.91%2044.34,96.49%2079.57,157.5%2093.26,181.22%20'/%3e%3cpolygon%20class='st2'%20points='64.81,131.95%2025.15,131.21%200,130.74%2028.44,180.01%2066.73,180.72%2093.26,181.21%20'/%3e%3cpolygon%20class='st2'%20points='165.38,181.74%20184.58,216.46%20196.75,238.47%20225.19,189.2%20206.66,155.69%20193.83,132.46%20'/%3e%3c/g%3e%3c/svg%3e)
Windmill HubDrive Windmill from inside Windmill: run, deploy and delete scripts and flows, run code, watch the queue, manage schedules, resources, variables, groups and folders of the workspace — as steps of a flow, with no credential to set up.
Set up in 3 steps
Add a step
In a flow, add an action and search the hub for Windmill. There is no resource to create: each action authenticates with the token of the job it runs in.
Pick the target
Script, flow, schedule, resource, variable, group and folder inputs are dropdowns filled from your workspace.
Mind who runs it
The step can do what the user running the flow can do, in the workspace the flow runs in. A schedule runs as the user it is permissioned as. Add the Who Am I action to see which user that is.
Scripts
Building blocks, if none of the projects above fit. Fork one, run it, or call it as a step inside your own flow.
Who Am I
Wait for Job
Update Variable
Update Script
Update Schedule
Update Resource
Update Flow
Run Script by Path and Wait for Result
Run Script by Path
Run Flow by Path and Wait for Result
Run Flow by Path
Run Code
Remove User from Group
Remove User or Group from Folder
List Variables
List Scripts
List Schedules
List Resources
List Resource Types
List Jobs
List Groups
List Folders
List Flows
List Completed Jobs
List Audit Logs
List Apps
Get Workspace Settings
Get Variable Value
Get Script
Get Schedule
Flows
Multi-step workflows that already wire Windmill to something else.
Azure Event Grid flow with preprocessor template
Nextcloud event flow template
Email trigger flow with preprocessor template
GCP flow with updated preprocessor template
HTTP route flow with signature verification template
NATS flow with preprocessor template
Kafka flow with preprocessor template
WebSocket flow with preprocessor template
HTTP flow with preprocessor template
MQTT flow with preprocessor template
SQS flow with preprocessor template
Resource types
The credential shapes the scripts on this page expect — pick the one your script asks for.
api_key_auth
View raw schema →| Field | Type | Required | What it is |
|---|---|---|---|
| api_key_header | string | Yes | |
| api_key_secret | string | Yes |
aws_oidc
View raw schema →| Field | Type | Required | What it is |
|---|---|---|---|
| roleArn | string | Yes | |
| region | string | No |
basic_http_auth
View raw schema →| Field | Type | Required | What it is |
|---|---|---|---|
| username | string | Yes | |
| password | string | Yes |
cacertificate
View raw schema →| Field | Type | Required | What it is |
|---|---|---|---|
| certificate | string | No |
customai
View raw schema →| Field | Type | Required | What it is |
|---|---|---|---|
| api_key | string | No | |
| base_url | string | Yes | e.g. https://my.custom.provider/v1 |
| headers | object | No | Custom HTTP headers to include in AI requests |
json_schema
View raw schema →| Field | Type | Required | What it is |
|---|---|---|---|
| schema | object | No |
signature_auth
View raw schema →| Field | Type | Required | What it is |
|---|---|---|---|
| signature_provider | string | Yes | |
| secret_key | string | Yes | |
| authentication_config | object | No |
Questions
What can these actions access?
Exactly what the user running the job can, in the workspace the job runs in. They use the job's own token, so there is nothing to grant and nothing to rotate. Listing users, reading workspace settings or audit logs needs a workspace admin.
Can I act on another workspace or on the instance?
Not with the job's token: Windmill confines it to the job's workspace, so other workspaces and instance-level operations (workers, global users, instance settings) are refused. Use the Call Windmill API action and give it a user API token, ideally read from a secret variable.
The operation I need is not in the list.
Call Windmill API covers every operation. Its dropdown is built from your own instance's OpenAPI document, so it always matches the version you run. Give it the path parameters, query and body the operation takes; the workspace defaults to the current one.
Why does a secret reference end up resolved in a resource I created?
Windmill resolves $var: and $res: strings in a job's arguments before the script runs. A value passed to Create Resource therefore stores what the reference points to.