Skip to main content
Actions allows you to define and remotely execute custom workflows in installs. You can automate common tasks, implement healthchecks, and even automate runbooks to handle incidents.

​
Configuring Action Workflows

Action workflows can be configured in your app’s TOML config. For example, to define an HTTP healthcheck:
actions/http_healthcheck.toml
# action
name = "http_healthcheck" timeout = "0m15s"

[[triggers]] type = "cron" cron_schedule = "_/5 _ \* \* \*"

[[triggers]] type = "manual"

[[steps]] name = "healthcheck" command = "./healthcheck"

[steps.public_repo] repo = "nuonco/actions" branch = "main" directory = "common"

[steps.env_vars] ENDPOINT =
"https://your-app.{{.nuon.install.sandbox.outputs.public_domain.name}}" METHOD =
"HEAD" EXPECTED_STATUS_CODE = "200"
actions/<your-action>.toml
# action
version      = "v1"
description  = "Your app on AWS."
display_name = "Your App"

[[actions]]
source = "./actions/alb_healthcheck.toml"
Once configured and synced, you will see the workflow in the “Actions” tab for your app. Following that example, we can describe the parts of a workflow.

​
Timeout

Each workflow must have a timeout limiting how long it can run. The maxiumum allowed timeout is 30 minutes. Timeouts must be provided as valid Golang time.Duration strings. The example workflow will timeoute after 15 seconds, more than enough time to make a simple HTTP request.

​
Action Triggers

Action triggers are now available for all workflows. You can now use the following set of triggers:
  • pre-provision
  • post-provision
  • pre-reprovision
  • post-reprovision
  • pre-deprovision
  • post-deprovision
  • pre-deploy-all-components
  • post-deploy-all-components
  • pre-teardown-all-components
  • post-teardown-all-components
  • pre-deprovision-sandbox
  • post-deprovision-sandbox
  • pre-reprovision-sandbox
  • post-reprovision-sandbox
  • pre-update-inputs
  • post-update-inputs
  • pre-secrets-sync
  • post-secrets-sync
Each workflow trigger is called at the beginning or end of the workflow. In some cases, such as pre-provision or pre-reprovision that include a stack-run, the trigger will be called right after the runner is healthy. The following triggers require a component_name field to be set, as they are tied to a specific component:
  • pre-deploy-component
  • post-deploy-component
  • post-teardown-component
  • pre-teardown-component
Actions can be triggered manually, on a cron, or by install events. You can define multiple triggers for an action. The example action defines two triggers. It will run every five minutes, and can also be triggered manually at any time.
actions/<action-name>.toml
# action
[[triggers]]
type          = "cron"
cron_schedule = "*/5 * * * *"

[[triggers]]
type = "manual"

​
Steps

Each step in an action requires a command to be run. You can optionally load a script from a repo and provide env vars to configure the environment the command will run in. The example action is pretty simple, so it has only one step. It loads a curl script from our open-source repo of commonly-used scripts, and sets a few env vars to configure it.
actions/<action-name>.toml
# action
[[steps]]
name    = "healthcheck"
command = "./healthcheck"

[steps.public_repo]
repo      = "nuonco/actions"
branch    = "main"
directory = "common"

[steps.env_vars]
ENDPOINT             = "https://your-app.{{.nuon.install.sandbox.outputs.public_domain.name}}"
METHOD               = "HEAD"
EXPECTED_STATUS_CODE = "200"

​
Adhoc Actions

Adhoc actions let you run a one-off command or bash script on an install without defining it in your app’s TOML config. This is useful for debugging, running database migrations manually, or any other operational task that doesn’t need a recurring or lifecycle-triggered workflow.

​
Running an Adhoc Action

Navigate to an install in the dashboard and click Manage > Run adhoc action. You’ll beprompted to configure the run:
  • Name (optional) — a display name shown in workflow history.
  • Single Command / Bash Script — choose between a single-line shell command or a multi-line bash script.
  • Timeout — execution timeout in seconds (1–3600, default: 300).
  • Environment Variables — key/value pairs injected into the execution environment. Values support Go template interpolation (see below).
  • Role — the IAM role the runner will assume when executing the action.
After submitting, you’ll be taken directly to the workflow run to monitor logs and status.

​
Template Interpolation

Both commands and scripts support Go template syntax for injecting install state at execution time. For example: 
#!/bin/bash
curl -f "https://{{.nuon.install.sandbox.outputs.public_domain.name}}/health"
Environment variable values also support templates: 
#!/bin/bash
curl -f "$HEALTH_ENDPOINT"

HEALTH_ENDPOINT = "https://{{.nuon.install.sandbox.outputs.public_domain.name}}/health"

​
Rerunning an Adhoc Action

From the workflow run detail view, you can rerun a previous adhoc action. The form will be pre-populated with the original command, script, environment variables, and role — you can edit before submitting.

​
Monitoring Workflow Runs

Actions workflow runs can be monitored on the “Actions” tab in each install. You can see a list of all workflow runs, and inspect each run to see logs, what triggered the run, and whether it succeeded or not.