Personal access keys (ev_sk_...) authenticate Envless from environments that can't run an interactive browser login: CI runners, Docker builds, production hosts, serverless platforms, and any tool calling the Envless API directly.
Each key is scoped to a workspace and can be named, rotated, or revoked from the dashboard at any time.
The envless command ships in @goenvless/cli. Install it with npm i -g @goenvless/cli@latest.
When you need one
CI / CD pipelines
GitHub Actions, GitLab, CircleCI, etc. Once ENVLESS_TOKEN is set, envless sync, envless run, and the runtime import all work.
Production hosts
Long-running servers without a cached browser session.
Docker builds
Mount the key as a build secret; never bake it into a layer.
API access
Anything talking to the Envless API programmatically.
Create a key
Open the Keys page
Go to envless.cloud/dashboard/keys and select the workspace you want a key for.
Generate
Click "Create Key", give it a descriptive name (e.g. ci-production, vercel-preview, github-actions), and click "Generate Key".
Narrow the scopes
The create dialog carries a scope builder over 11 resources: workspace, products, product access, projects, environments, variables, versions, members, roles, keys and webhooks. Each one is set to none, read or write, and each defaults to none, so a key grants exactly what you tick and nothing else. A CI runner that only needs to read variables wants variables: read plus environments: read and projects: read, and nothing more.
Fence it to a project, if it only needs one
The same dialog takes an optional project allowlist. A key with an allowlist is refused with 403 and auth.key_project_restricted on any request touching a project outside it, and is refused outright on workspace-wide surfaces such as webhooks and key management.
Prove it is you
Creating a key is a step-up guarded action. Unless you verified something else in the last hour, the dashboard asks for a verification code before the key exists, then completes the creation for you. No second click is needed.
Copy the value immediately
The full ev_sk_... value is shown once, at creation. Envless stores only a hash of it. The dashboard can never show it again. Copy it into your CI/host secret store right away.
Scopes and the project allowlist can both be edited later from the key's row menu, and a key can be disabled and re-enabled without deleting it, which is a gentler first move than revocation when you are not yet sure a key is the problem. Both of those edits are guarded by a verification code, the same as creation.
A key can never outrank the person who created it. Requested scopes are clamped down to the creator's own workspace-role permissions at creation time, and every existing key is re-clamped automatically when that member's role changes or when their role's permission list is edited. Demoting someone silently narrows the keys they already issued, which is usually what you want, but it does mean a pipeline can start failing with auth.scope_missing after an unrelated role change.
Use the key
Expose the key as ENVLESS_TOKEN in the target environment. Every Envless command and the runtime loader pick it up automatically.
export ENVLESS_TOKEN=ev_sk_xxxxxxxxxxxx
envless sync # pull encrypted variables, write .env.<slug>
envless run -- npm start # inject into a child process
node --import @goenvless/env/register server.js # runtime importThe token authenticates the fetch; it does not decrypt. Because Envless is zero-knowledge, the server only ever returns ciphertext, so on a machine you also need a decryption credential in the environment: ENVLESS_KEY (the base64url raw workspace key exported from the dashboard's CI / Machine Access page, Settings → /settings/ci-access) or ENVLESS_PASSPHRASE. Pair one of these with ENVLESS_TOKEN. See Passphrase for how the key is derived.
See Production & CI for platform-specific setups (GitHub Actions, Vercel, Docker, Kubernetes).
Naming and rotation
Name keys for the place they live, not the person who created them:
| Good | Why |
|---|---|
ci-production | One key per pipeline, easy to revoke without breaking other things |
vercel-preview | Scoped to a platform and environment |
docker-build | Targeted revocation when the image registry changes |
bardhyl-laptop | Bad: use envless login on laptops instead |
Rotate keys whenever:
- An employee with access leaves.
- A CI provider you used was breached.
- You're not sure if a key leaked; rotate first, investigate second.
Rotating
Rotation issues a new secret for an existing key and invalidates the old one, keeping the key's name, scopes and project allowlist. Open the key's row menu in the dashboard and choose Rotate. The new secret is shown once, in a modal that will not close on Escape, so copy it before you dismiss it. There is no rotate route on the public API; rotation is dashboard-only.
Revoking
From the dashboard, delete the key. The next call using it gets a 401 immediately. There's no grace period. Design pipelines around that (generate the new key, update the secret, then revoke the old).
Every key change except a rename requires step-up verification. Creating, rotating and deleting a key are guarded, and so is any edit that flips active in either direction or changes the key's scopes or project allowlist. A request that sends only a new name is the one that runs on a plain session. One code elevates you for an hour in that workspace, so a batch of key changes needs a single round trip.
The code is a 6 character one emailed to the account address, and it allows 5 attempts. If you have two factor authentication on, the dialog asks for your authenticator code instead and sends no email at all.
Without two factor authentication, whoever revokes a leaked key needs access to their Envless inbox at that moment. An account nobody can currently receive mail for cannot revoke its own keys. Do not leave production key ownership with a departed employee's account or a shared address nobody monitors.
Keep keys secret. Never commit them to git, paste them in chat, or print them in build logs. If you suspect a key has leaked, revoke it from the dashboard immediately. The old value stops working the moment you delete it.
Programmatic API access
Beyond authenticating the CLI and runtime, personal access keys let you call the Envless HTTP API directly. Pass the key as a bearer token:
curl https://api.envless.cloud/projects \
-H "Authorization: Bearer ev_sk_xxxxxxxxxxxx"The API supports full CRUD across workspaces, projects, environments, variables, and versions. Variable values are always returned (and must be sent) as ciphertext. Keys carry per-resource scopes and an optional project allowlist, so you can mint read-only or narrowly-scoped keys. See API Overview for the full surface, Authentication for the auth flow and scopes, and the Endpoints reference for every operation.
Going deeper
Two things worth having open alongside this page.