Documentation
Private sites and access grants
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/site/<site-name>.
When you create a site with auth=private, Everlock removes that anon grant. From that point on, only users or groups with an explicit Reader, Writer, or Owner grant on http/site/<site-name> can read the site.
How authentication works
Private sites use HTTP Basic authentication. When a browser or client requests a page on a private site without credentials, Everlock responds with:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="site"
Browsers will show a username/password prompt. Other HTTP clients need to supply credentials in the standard Authorization: Basic <base64> header.
Credentials are validated against Everlock's user model. A valid password alone is not enough: the actor must also have a matching grant on the site path.
Creating a private site
Pass auth=private when creating the site:
/site create internal-docs vhost=docs.local mode=markdown auth=private
The site is immediately private. Any request without valid credentials gets a 401 response.
Switching an existing site to private
/site set my-docs auth=private
This takes effect immediately without a restart. The site switches from public to private the moment the command succeeds.
To make it public again:
/site set my-docs auth=public
Managing users
Adding a user
/users add alice s3cr3t-passw0rd
This creates a new user alice with the given password. The user still needs an explicit site grant.
Expected output:
user 'alice' created
Changing a password
/users passwd alice new-passw0rd
Listing users
/users list
Expected output shape:
alice (password set)
bob (password set)
admin (password set)
Granting site access
Give Alice read access to one private site:
/users grant alice http/site/internal-docs reader
Give a group access instead:
/groups grant docs-team http/site/internal-docs reader
Viewing a user's grants
/users grants alice
This shows all access paths the user has been granted, including site access such as http/site/internal-docs.
Full example: a private staging site
Here is a complete walkthrough for a private staging site that mirrors a public site before changes go live.
1. Create the staging site
/site create staging vhost=staging.internal mode=markdown auth=private
2. Add team members who need access
/users add alice password-for-alice
/users add bob password-for-bob
/users grant alice http/site/staging reader
/users grant bob http/site/staging reader
3. Push staging content
git clone ssh://admin@localhost:2222/staging
cd staging
# copy or symlink content from your main site repository
git add .
git commit -m "staging: initial content"
git push
4. Review the site
Visit http://staging.internal/. The browser will prompt for username and password. Enter alice and password-for-alice to access the site.
5. Promote to production
Once the content is approved:
- push the same content to the production site repository
- optionally flip staging back to public with
/site set staging auth=public
Using a private site from scripts
Pass credentials using standard Basic auth syntax. With curl:
curl -u alice:password-for-alice https://docs.yourdomain.com/api-reference
With wget:
wget --user=alice --password=password-for-alice https://docs.yourdomain.com/api-reference
What private mode does not do
Private mode protects HTTP page access. It does not:
- restrict who can push content to the underlying Git repository (that is controlled by
/users grant) - provide per-page or per-section access control (the entire site is either open or locked)
- create separate user namespaces per site (all Everlock users share the same user model)
If you need per-repo Git access control, see the Git backend docs.