Super Admin Renamed to Instance Owner
For the complete documentation index, see llms.txt. For a full content snapshot, see llms-full.txt. Append .md to any kestra.io/docs/* URL for plain Markdown.

Super Admin is renamed to Instance Owner in 2.0. The privilege is otherwise unchanged.

Deprecated aliases are retained for the CLI, configuration, and HTTP request bodies. The only breaking change is HTTP API responses: the field superAdmin is renamed to instanceOwner with no alias. Update API consumers that read this field.

What changed

Terminology

“Super Admin” and “Superadmin” become “Instance Owner” across the UI, docs, and API. The privilege is a boolean on a user or service account — not a role, not a binding, not tenant-scoped.

CLI (kestra auths users)

OldNewAlias retained
--superadmin flag on users create--instance-ownerYes — --superadmin still works
set-superadmin subcommandset-instance-ownerYes — set-superadmin still works

Configuration

Old keyNew keyAlias retained
kestra.security.super-adminkestra.security.instance-ownerYes — old key still works

Updated config structure:

kestra:
  security:
    instance-owner:
      username: <username>
      password: <password>
      tenant-admin-access:
        - <optional>

HTTP API

Request bodies still accept superAdmin via a JSON alias — no changes required for callers creating or updating users.

Responses now emit instanceOwner instead of superAdmin:

if (user.superAdmin) { ... }
if (user.instanceOwner) { ... }

Deprecated HTTP paths under /superadmin still work but will be removed in a future major version.

What requires action

  1. API consumers reading superAdmin from responses — update to read instanceOwner. This is the only change without a deprecated alias.
  2. Config using kestra.security.super-admin — update to kestra.security.instance-owner before the alias is removed.
  3. CLI scripts using --superadmin or set-superadmin — update to --instance-owner and set-instance-owner before the aliases are removed.

No database migration is required. Existing users and service accounts with the Instance Owner privilege are unaffected.

Was this page helpful?