Skip to main content
An action’s steps run on the install runner, which carries a small toolchain. Setting image on an action runs its steps inside a container image you build instead, so the tools a step needs (psql, a migration binary, a specific helm version) ship with the action rather than being installed by the script on every run.
Container actions are behind the image-backed-actions org feature flag and are off by default. Reach out to Nuon to enable it for your org.

​
Requirements

  • The image-backed-actions org feature turned on.
  • An AWS install runner. Azure and GCP installs reject the run.
  • Every step in the action uses inline_contents. command, public_repo, and connected_repo steps are not supported alongside an image.

​
Configure it

Add image to the action and write each step as inline_contents:
actions/db_migrate.toml
Sync it the same way as any other action:
Everything else about the action is unchanged: triggers, timeout (30 minutes maximum), role, enable_kube_config, env_vars, and template interpolation all behave exactly as they do for a host-run action. See Configure actions for those.

​
Choosing an image

image is templated per install, so it can be a fixed reference or resolved from install state.

​
A public reference

actions/db_migrate.toml

​
A private image

Publish the image as a container image component and point image at its image.ref output:
actions/db_migrate.toml
Registry access is configured once on the component, and every action referencing it inherits that. Referencing the component also registers it as a dependency of the action, so you do not need to list it under dependencies.
Use the component’s image.ref output, not image.repository and image.tag. A bare repository:tag is rejected with not digest-pinned.

​
Building the image

Your steps run with the image’s own PATH, and the runner’s tooling is not available inside the container, so every binary a step calls has to be in the image.