Documentation
This is the complete catalogue of what you can grant. Everything Everlock controls is reachable through **one** grant model: a `role` attached to a subject (user or group) on an `access path`. There i
Each site can record an HTTP access log. It's off by default; when you turn it on, every request to the site is captured as a JSONL entry and committed to a dedicated git store. The design keeps commi
By default, every site Everlock creates is public: anyone who can reach the server over HTTP can read the pages. Public access is expressed through the built-in `anon` user having `Reader` on `http/si
This page covers the full path from a working local site to a live public site with automatic HTTPS certificate management. Everlock handles certificate issuance and renewal through ACME (the same pro
A single Everlock instance can serve any number of sites simultaneously. Each site has its own Git-backed content repository, its own vhost mapping, and its own auth and mode settings. The HTTP fronte
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
Groups let you manage access for multiple users at once. Instead of granting each user access to a repository individually, you grant the group and then add members to it. New members pick up all grou
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. /users create <login> <password> E
Everlock uses namespaced module configuration instead of one giant undifferentiated settings surface. - the binary starts from CLI and environment configuration - modules own their own config surfaces
