Give your pipelines their own credentials with service tokens
Projects can now issue service tokens: credentials for GitHub Actions, Docker, Kubernetes, and serverless runtimes that can't open a browser.
Create one from the new Service Tokens page in your project. The raw token is shown once and stored only as a SHA-256 hash. Pass it to the CLI as APIVAULT_TOKEN:
APIVAULT_TOKEN=av_live_... apivault run -- npm run build
#Limit what a token can do
- Scopes: list keys, reveal decrypted values, and modify keys are separate grants, capped by the role of whoever creates the token.
- Environment pin: a pinned token can only read and write that environment, and callers can't override the pin.
- IP allowlist: restrict a token to IPv4 or IPv6 CIDR ranges. Requests from anywhere else, or from an unknown address, are refused.
- Expiry: every token expires after 7 to 365 days, 90 by default. There is no option for a token that never expires.
#If a token leaks or its creator leaves
Service tokens reach key endpoints and nothing else. Project settings, members, invitations, encryption configuration, and token creation all reject them.
Removing a member does not revoke the service tokens they created. These credentials belong to the project and keep working until revoked or expired. The Service Tokens page flags tokens whose creator has left.
To revoke a token, open the project's Service Tokens page, find it, and choose Revoke. Owners and admins can revoke tokens; revocation takes effect immediately. Revoke a leaked token immediately, then replace it in any affected pipelines. For routine rotation, update the pipeline's CI secret with a replacement before revoking the old token.
Audit logs record token requests and refusals under their own Service source, with a filter for each token. Project owners and admins are notified when a token exports an entire environment.
Learn more in the service tokens documentation.