A service account is a named machine identity in your Nuon org. Use service accounts for automation, CI/CD pipelines, and any integration that calls the Nuon API on behalf of a system rather than a person.
Unlike a one-off API token, a service account is a persistent identity you manage. You can rename it, change its role, and mint (or invalidate) multiple tokens for it over time.
Managing service accounts requires org admin access.
Roles
Every service account is assigned exactly one role, which determines its permissions. Roles are org-scoped. See Access control for the available roles and what each grants — Admin (org_admin) and Read-only (org_read_only).
You can list the available roles at any time using the CLI:
Managing service accounts
Service accounts can be managed in the Dashboard on the Service accounts page, and with the CLI service-accounts commands.
Create
Create a new service account. Both a name and a role are required.
Mint a token
Create a token for a service account. The duration will default to one year.
Optionally set a custom duration.
The token value is shown only once. Copy it immediately into your secret manager or CI secret store — you cannot retrieve it again.
Update a service account
You can change a service account’s name or role.
A service account can only have one role at a time. Updating the role will replace the service account’s current role.
List
List active service accounts.
Delete
Deleting a service account will remove its roles and invalidate all of its tokens.
Runner service accounts
Every runner is backed by its own machine identity — a service account with the special runner role. This is an implementation detail you can mostly ignore. You do not need to create or manage these service accounts yourself.
Because they’re managed for you, runner service accounts are hidden from nuon service-accounts list by default, but you can see them with the --include-runners flag.
Stack service accounts
When an install is provisioned with the stack Terraform module, Nuon creates a service account for it with the reserved stack role. This is the identity the nuonco/stack provider authenticates as when it reads the install’s configuration and reports phone-home data. You don’t create these yourself — one is created with the install.
Unlike other roles, the stack role is scoped to a single install: a token minted for one install’s stack service account cannot read any other install’s configuration. Tokens for it are created from the Await install stack step’s TF Module tab. See Provision Stacks with a Terraform Module for the full flow.
Like runner accounts, stack service accounts are hidden from listings by default. The dashboard’s Service accounts page has a “Show stack accounts” checkbox to reveal them, and the CLI accepts an --include-stacks flag.
