Documentation
Managing users
All user management happens from the admin SSH console. This page covers creating users, managing passwords, listing users, and where a new user's access comes from.
Creating a user
/users create <login> <password>
Example:
/users create alice hunter2
Expected output:
created user 'alice'
login becomes the user's primary_name — the stable slug used in access paths and SSH URLs. It is unique system-wide and cannot be changed after creation. Choose it carefully: it appears in clone URLs and grant paths.
Passwords are hashed with Argon2id immediately. The plaintext is not stored anywhere.
Listing users
/users list
Expected output shape:
name display name groups kind password set last login
alice Alice [writers] user 2026-08-02 2026-09-26
bob Bob [] user 2026-08-11 never
admin Administrator [] user 2026-07-14 2026-09-27
Columns are the login (primary name), display name, group memberships, the kind
of principal, the day the current password was set, and the day the user last
authenticated by any means. A user without a display name shows the login as a
fallback; never means no successful authentication has been recorded.
A use is noted in memory on the authentication path and written by a daily job,
so the two timestamp columns read accurate to the day rather than to the second —
a share link served all day costs one commit. The same applies to the created
and last used columns on /users ssh-keys list and /users apikey list. A
credential stored before these fields existed is stamped the first time it is
loaded.
Changing a password
/users password <login> <new-password>
Example:
/users password alice new-secure-password
Expected output:
password updated for 'alice'
This replaces all existing password credentials for the user with a single new one. Other credential types (SSH keys, API keys) are not affected.
Inspecting a user's grants
/users grants <login>
Example:
/users grants alice
Expected output shape:
alice
grant: */git/api-docs writer
grant: */git/config reader
Use this to audit what a user can access before adding or removing grants. Grants a user receives through group membership are not listed here, but they do apply.
Granting and revoking access
/users grant <login> <path> <role>
/users revoke <login> <path>
See Git access control and grants for the full explanation of paths, roles, and wildcard patterns. The commands work identically for any backend, not just Git.
Where a new user's access comes from
A newly created user holds no grants, and every access decision is made from grants alone — a resource name never carries privilege by itself. Access arrives in two ways:
- Resource-creating commands mint the initial grant.
/git creategrants the creating userowneron*/git/<name>;/image create,/site create, and the other create commands do the same for their resources. - Everything else is granted explicitly — with
/users grant, either directly to the user or to a group they belong to.
What this looks like in practice
/users create alice hunter2
/git create alice-notes
/users grant alice */git/alice-notes writer
Alice can clone and push alice-notes because of the explicit grant — the repository's name plays no role in the decision. A mailbox works the same way: /users grant alice */mail/example.com:alice owner gives her IMAP access and send rights for alice@example.com.
System administrators
A user is a system administrator if they hold owner on the path */*/*. This path matches every frontend, every backend, and every namespace — it is the broadest possible grant.
/users grant ops-team-lead */*/* owner
System admins can read, write, and delete any resource on the instance. The bootstrap admin account is created with this grant on first start.
To check whether a user is a system admin, look for */*/* owner in their grants:
/users grants admin
admin
grant: */*/* owner
Grant system admin access sparingly. For most team scenarios, targeted grants on specific repositories or resource paths are the right approach.
Credential types
A user holds credentials of three kinds, all managed from the admin console:
| Type | How set | Used for |
|---|---|---|
password | /users create, /users password | SSH login, HTTP Basic auth |
ssh-key | /users ssh-keys create, /users ssh-keys delete | SSH authentication without a password |
api-key | /users apikey create, /users apikey revoke | programmatic access over HTTP |
OAuth access tokens are not credentials in this sense: the OAuth backend issues signed JWTs that are validated by signature rather than looked up against a stored credential.
SSH key management commands:
/users ssh-keys list <login>
/users ssh-keys create <login> "<openssh-public-key>"
/users ssh-keys delete <login> <fingerprint>
The create command accepts a normal OpenSSH public-key line such as
ssh-ed25519 AAAA... comment. Everlock stores the trailing OpenSSH comment as
the key alias and shows it in /users ssh-keys list together with the key
type and SHA-256 fingerprint. The delete command targets the fingerprint shown
by the list command.
API keys
An API key is the credential for everything that talks to Everlock over HTTP without a browser:
/users apikey create <login> [alias]
/users apikey list <login>
/users apikey revoke <login> <key-id>
create prints the key once — it is stored only as a hash, so a lost key is
replaced rather than recovered. Keys carry an evapi_ prefix.
A key works anywhere a password does over HTTP, in either of two ways: as an
HTTP Bearer token, or as the Basic password under any username, which is
the convention git's credential helper and forge access tokens rely on:
The key names its own user, so the username is ignored. That covers the admin HTTP API and MCP, git over HTTP, calendar and contacts clients, registry pulls, and access-controlled sites.
list shows each key's key_id, alias, when it was created, when it expires,
and when it last authenticated — so a key nothing uses is visible as one to
revoke.