opschain admin service-accounts
Included from Basic tier
Manage service accounts: durable non-human principals that standing automations — triggers and scheduled activities — run as, so the automation survives its creator leaving. Users come and go; service accounts and groups remain.
A service account has no login lane: it never authenticates on any lane
(no password, no session, no api key — the mints refuse by name), and it is
never an approver (approvals remain human). It exists purely
as a run-as target, and takes its authority exactly like any identity —
through policy assignments and group membership (opschain admin groups add-member works on a service account; groups grant, principals act).
Point an automation at one with run_as (your act_as trust grant
authorises the delegation — the run-as flag of opschain triggers update,
or the run-as field on a scheduled activity), and move a leaver's
automations onto one with opschain admin users reassign-automations.
Personal automations (run as yourself) remain fully legal and first-class — a service account is the durable recommendation for anything a team depends on, never a mandate.
| Subcommand | Purpose |
|---|---|
create | Mint a service account — opschain docs cli/admin-service-accounts-create |
list | List service accounts — opschain docs cli/admin-service-accounts-list |
disable | Stop its firings resolving — opschain docs cli/admin-service-accounts-disable |
enable | Reverse a disable — opschain docs cli/admin-service-accounts-enable |
admin service-accounts itself takes no flags; every subcommand carries
the admin connection pair --server / --auth-token (see opschain docs cli/admin-users for the shared connection errors).
See also
opschain docs cli/admin-users-reassign-automations— move a leaver's automations onto a service account.opschain docs cli/admin-groups— group membership (ownership and policy routing).opschain docs cli/triggers-update— point a trigger'srun_asat one.