Documentation
Managing users
All user management happens from the admin SSH console. This page covers creating users, managing passwords, listing users, and the two special access rules that apply automatically without any explicit grant.
Creating a user
/users add <login> <password>
Example:
/users add alice hunter2
Expected output:
user 'alice' created
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:
alice Alice [writers]
bob Bob []
admin Administrator []
Columns are: login (primary name), display name, and group memberships. Users without a display name show the login as a fallback.
Changing a password
/users passwd <login> <new-password>
Example:
/users passwd 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. Only explicit grants are shown here — implicit grants from self-ownership and group membership are not listed, 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.
The implicit self-ownership rule
Every user automatically owns any resource whose namespace segment matches their primary_name — no explicit grant needed.
The access path has three segments: frontend/backend/namespace. When the namespace matches the user's login, that user is owner regardless of whether a grant exists:
alice → automatic owner of */*/alice
This means:
alicecan always push tossh://alice@host/alice(the repo namedalice)alicecan always read/write their own mail store, their own admin paths, etc.- No one needs to run
/users grant alice */git/alice ownerafter creating the user
This rule exists so every user has a private namespace they fully control by default. Resources that belong to someone else still require an explicit grant.
What this looks like in practice
/users add alice hunter2
Alice can immediately clone and push to ssh://alice@localhost:2222/alice without any further setup. She cannot access anyone else's resources until explicitly granted.
If you create a repository named alice:
/git create alice
Alice automatically owns it. If you create a repository named shared-project, no one owns it by default except the user who ran /git create.
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
Users can hold credentials of four types. Passwords and SSH keys are currently manageable through the admin console:
| Type | How set | Used for |
|---|---|---|
password | /users add, /users passwd | SSH login, HTTP Basic auth |
ssh-key | /users ssh-keys add, /users ssh-keys delete | SSH authentication without a password |
api-key | Not yet in admin console | Programmatic API access |
bearer-token | Not yet in admin console | OAuth / token-based access |
SSH key management commands:
/users ssh-keys list <login>
/users ssh-keys add <login> "<openssh-public-key>"
/users ssh-keys delete <login> <fingerprint>
The add 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.