Documentation

Everlock brings sites, Git, mail, DNS, registries, calendars, contacts, and other self-hosted services together in one system. This documentation explains how those parts work and how to use them.

If you want a first setup, start with Guides. If you want to understand a specific service, open the matching backend page below.

Start here

Page	Why to read it
Architecture	The big-picture split between frontends, backends, and shared primitives
Deployment	How to run Everlock — the downloaded binary standalone or as a systemd service (recommended); Docker for container-only platforms
Server settings	The runtime-tunable settings behind /server settings — keys, defaults, and precedence
Frontends	How SSH, HTTP, DNS, SMTP, IMAP, and mDNS behave as transports
Backends	The backend modules, what each one serves, and how instances are configured
Primitives	The small shared building blocks reused across the system
Versioned storage	The history-keeping store primitive behind sites, mail, calendars, and the vault

Backend families

Each backend page starts with an overview, followed by reference pages and setup guides for that service.

• Sites — Static and Markdown site hosting over HTTP

  • Getting started: Markdown site
  • Getting started: HTML site
  • Directory structure
  • Writing and customizing templates
  • Taxonomies and tag pages
  • Cross-linking pages with all_pages
  • Running multiple sites
  • Publishing over public HTTPS
  • Private sites and access grants
  • Per-site access log
  • Local preview and build workflow
  • site.toml configuration reference
  • Downloads and redirects
  • This site on Everlock

• Git — Git repositories, SSH interaction, and repository persistence

  • Managing repositories
  • Pull requests
  • Access control and grants

• Users, groups, and access control — The unified identity and permission model

  • Managing users
  • Groups
  • Permissions reference

• Images — Image and media serving over HTTP, powered by the embedded apimeister-photos (ami) engine

  • The apimeister-photos engine (ami)
  • E-paper photo frames
  • Running multiple image instances
  • Public hosting: DNS vhosts and ACME
  • Private networks: mDNS discovery
  • Image instance and access reference

• Admin — Operator-facing admin flows over SSH, HTTP, and MCP

  • Admin over SSH and CLI
  • Admin over HTTP
  • Admin over MCP

• AI — Embedded AI prompting through the admin SSH session, and image captioning shared with the image backend, all on the self-developed gguf-runner engine

  • AI model variants (SmolVLM vs Qwen3)
  • The gguf-runner inference engine
  • AI runtime and access model

• DNS — Authoritative DNS and derived records from Everlock services

  • DNS record derivation and address-mode reference

• OCI — OCI registry backend over HTTP, powered by the embedded apimeister-registry engine

  • The apimeister-registry engine
  • Public hosting: DNS vhosts and ACME
  • Private networks: mDNS discovery
  • Registry model and auth reference

• Mail — SMTP receive and submission, IMAP read/write access, rules-based storage, and forwarding

  • Mail rules reference
  • Mail rules cookbook

• Calendar — CalDAV calendars with Everlock auth and versioned storage

  • CalDAV behavior and storage reference

• Contacts — CardDAV contacts with Everlock auth and versioned storage

  • CardDAV behavior and storage reference

• OAuth — OAuth 2 / OIDC token issuance

  • Provider model and configuration reference

• Vault — Bitwarden-compatible, end-to-end-encrypted password manager with versioned storage

  • Bitwarden behavior and storage reference

Troubleshooting

• Known issues — Errors we've hit ourselves, each with the fix and why it works