Hey there! Appreciate you bringing this up.

You're not missing anything. Unfortunately, this is a known gap. MAX_ADMIN_TOKEN_LIFETIME` applies to all tokens created by Owners, regardless of whether the target is a human admin or a headless service account.

That means your options right now are:

1. Increase MAX_ADMIN_TOKEN_LIFETIME and use token scoping to limit blast radius

• If you raise the limit, you can mitigate security issues by scoping the service account token to only the permissions it needs. Coder supports token scopes (e.g., template:read, workspace:read) and allow lists that restrict what resources a token can access.

2. Automate token rotation in CI

• Keep the default 7-day lifetime and have your CI pipeline rotate the token before expiry. An Owner (or a separate automation credential) calls POST /api/v2/users/{service-account}/keys/tokens on a schedule to issue a fresh token and inject it into CI secrets. This avoids raising the lifetime but adds operational complexity.

3. Hybrid: modest lifetime increase + rotation

• Set MAX_ADMIN_TOKEN_LIFETIME to something like 30 days instead of a year and combine with a monthly rotation job. This approach balances convenience with the exposure window.

We're planning to fill this gap and support finer-grained, per-role or per-user-type token lifetime policies, but I don't have an estimate for when those will land.