Everlock modular self-hosting in one binary
Search RSS feed

Documentation

Last updated in git: 2026-06-11

Configuration reference

Everlock uses namespaced module configuration instead of one giant undifferentiated settings surface.

Public mental model

  • the binary starts from CLI and environment configuration
  • modules own their own config surfaces
  • frontends and backends are enabled explicitly
  • HTTP routing is vhost-driven
  • content sites have both admin-managed site config and repo-local site.toml
  • frontend-http persists its runtime config in everlock-system/config/frontend-http.toml
  • public hosts can become ACME-managed automatically when an HTTPS listener is configured

Current CLI shape

Everlock already uses explicit server mode and includes local site actions:

everlock serve ...
everlock server ...
everlock site preview --path ./website
everlock site build --path ./website --out ./dist

serve is the canonical runtime command. server remains accepted as an alias to catch the common variant without forcing users to remember the exact spelling.

Useful examples from the docs

Site creation

/site create my-site vhost=docs.everlock.sh mode=markdown

Per-site access log

Each site can opt into a JSONL access log persisted in a dedicated git store (<site-store>-logs). The log section is absent for sites that have never enabled it.

[backend.site-http.sites.my-wiki.log]
enabled             = true
flush_interval      = "5m"
flush_max_bytes     = 262144
flush_max_entries   = 1000
buffer_hard_cap     = 1048576
channel_capacity    = 8192

Enable, disable, and tune via /site log enable|disable|set. See the access log page for the schema and operational behaviour.

Site repository config

title = "My site"
description = "Docs published from git"

[nav]
links = [
  { label = "Home", url = "/" },
  { label = "Search", url = "/search" },
]

HTTP vhost model

Everlock's HTTP transport routes first by host, then by path mount. That means backend instances stay independent and the route table stays explicit.

HTTP frontend config

The HTTP frontend keeps its persisted settings in config/frontend-http.toml. That file can describe:

  • listen_http
  • listen_https
  • acme_email
  • acme_directory
  • acme_renew_before_days
  • redirect_http_to_https
  • vhosts.<name>
  • certs."<hostname>"

Example:

enabled = true

listen_http = "0.0.0.0:80"
listen_https = "0.0.0.0:443"
acme_email = "ops@everlock.sh"
acme_directory = "https://acme-v02.api.letsencrypt.org/directory"
acme_renew_before_days = 30
redirect_http_to_https = true

[vhosts.main]
host = "everlock.sh"
backend = "site-http"

[vhosts.admin]
host = "admin.everlock.sh"
backend = "admin-http"

[certs."everlock.sh"]
not_after = "2026-08-01T12:00:00Z"
renew_after = "2026-07-02T12:00:00Z"
fullchain = "config/everlock.sh/fullchain.pem"
privkey = "config/everlock.sh/privkey.pem"

Local hosts such as localhost, *.local, and raw IPs stay plain HTTP. Public hosts become ACME-managed when listen_https is configured. The actual PEM files live under config/<host>/fullchain.pem and config/<host>/privkey.pem.

Where to read in the repository

  • docs/module-system.md
  • docs/module-design-principles.md
  • docs/system-store.md
  • docs/site/config.md
configuration ops