Browse
Users, groups, and access control
Users, groups, and access control
Everlock has a single unified user model shared across all frontends and backends. The same user identity that authenticates over SSH to push a Git repository is also the one that authenticates to an HTTP site, or that holds admin grants. There is no separate per-service account system.
Core concepts
Users are named principals. Each user has a primary_name (a lowercase slug used in URLs and paths), a display name, and one or more credentials.
Credentials are how a user proves their identity. A user can hold multiple credentials across different types: password, SSH public key, API key, or bearer token. Passwords are hashed with Argon2id before storage — the plaintext is never retained.
Groups are named sets of users. Grants given to a group apply to every member of that group.
Grants attach a role (reader, writer, or owner) to a user or group on an access path. The access path determines which resources the grant covers.
The bootstrap admin
On first start, if no admin user exists, Everlock creates a default admin account and prints the generated password in the startup output. That account holds owner on */*/* — the system admin grant that matches every resource. The first thing to do on a new instance is either record that password or change it:
/users passwd admin your-new-password
Sub-pages
- Managing users — creating users, changing passwords, listing, the implicit self-ownership rule, system admin
- Groups — creating groups, assigning members, granting and revoking group access