Workflow actionsNEW
The action catalog, variables, conditions, timeouts and error handling for workflow steps.
Who runs an action
- Proxmox actions are carried out by the portal through the Proxmox API.
- Agent actions are sent to the Verlocx agent inside the guest. Script, reboot and wait actions need an up-to-date agent.
- Portal actions are waits handled by the portal itself.
Proxmox and identity actions
| Action | What it does |
|---|---|
| proxmox.clone | Full clone of the template into a new VMID, using the template's VMID rules and storage |
| proxmox.start | Powers on the clone and waits for the start task |
| proxmox.backup_job | Adds the VM to its node's backup job |
| proxmox.ha_rule | Registers the VM for HA and adds it to the node-affinity rule; best placed last |
| agent.rename | Sets the hostname (default {{vm.hostname}}); folded into the domain join when one follows |
| agent.domain_join | Waits for a domain controller, joins, reboots and verifies, using the project's join account |
| agent.local_admins | Adds accounts to the local Administrators group (default: the owner) |
| agent.verify | Reads hostname and domain live and fails if they aren't what the workflow set |
Generic agent and portal actions
| Action | What it does |
|---|---|
| agent.script | Runs a PowerShell, cmd, sh or bash script, streams output and checks the result: exit code, text the output must or must not contain, or JSON fields. Can retry until the check passes and reboot afterwards. |
| agent.reboot | Restarts the guest; the step finishes when the agent is back |
| agent.wait_for | Polls until a service runs, a port opens, a file exists or a check script exits 0 |
| agent.wait_ready | Holds until Windows setup has finished, so it is safe to rename, join or install |
| portal.wait | Waits a fixed number of seconds |
| portal.wait_agent | Waits until the guest's agent is online |
Building blocks (module actions) are listed on the Configuration runs page; they can be used in provisioning workflows too.
Variables
Text fields can use variables in double curly braces. They are filled in per VM when the step runs; unknown variables are flagged before saving.
| Variable | Value |
|---|---|
| {{vm.name}}, {{vm.hostname}}, {{vm.vmid}}, {{vm.node}}, {{vm.ip}} | The VM's name, hostname, VMID, node and IP |
| {{vm.os}}, {{vm.os_family}}, {{vm.cpu}}, {{vm.ram_gb}}, {{vm.disk_gb}} | OS and sizing |
| {{vm.owner}}, {{vm.owner.account}}, {{vm.owner.email}} | The owner's name, Windows account and email |
| {{project.name}}, {{project.slug}} | The project |
| {{deploy.domain}}, {{deploy.ou}}, {{deploy.join_user}} | Domain-join settings of the project or template |
| {{steps.<id>.output}} | Output of an earlier script step |
| {{secret:join}} | The domain-join password; only ever sent to the agent |
Conditions, timeouts and errors
- When: a step runs only if its condition holds after variables are filled in. A bare value such as {{deploy.domain}} holds when it is not empty (and not false, 0, no or off); comparisons use == and !=.
- Timeout: a hard limit in seconds for the whole step, including retries and reboots.
- Continue on error: a failure is recorded but the workflow carries on. Without it, a failed step stops the deployment.
Steps that reboot the guest are waited out by the runner. The agent remembers finished steps across reboots, so a step is not repeated after the guest comes back.
Features on this page
- Action catalogNEW
- Workflow variablesNEW
- Conditions, timeouts and continue on errorNEW
- Script checksNEW
More in AutomationAll topics
Deployment workflowsDefine what a new VM goes through, as stages, tasks and steps, and pick a workflow per template.Configuration runsApply configuration workflows to existing VMs with idempotent building blocks, a dry run and a results grid.Configuration runsApply configuration workflows to existing VMs with idempotent building blocks, a dry run and a results grid.