Documentation
Backend families
Backends are where Everlock's service logic lives. They should stay transport-agnostic and avoid depending directly on SSH, HTTP, SMTP, or other frontend libraries.
Implemented families
| Backend | What it handles |
|---|---|
backend-git-ssh | Git wire operations over the SSH transport |
backend-ai-ssh | Embedded AI prompting through the admin SSH session, plus image captioning for backend-image-http |
backend-site-http | Static files and rendered Markdown sites from git-backed stores |
backend-image-http | Image and video storage plus gallery-like HTTP behavior |
backend-admin-ssh / backend-admin-http | Admin interaction surfaces |
backend-dns-dns | Global authoritative DNS record logic served through frontend-dns |
backend-dns-http | DNS records over HTTP (read/write API) |
backend-oci-http | OCI distribution-compatible registry with Everlock auth and store-backed persistence |
backend-mail-smtp | Inbound mail storage, forwarding, and submission-backed delivery rules |
backend-mail-imap | Read/write IMAP access on top of the SMTP backend's mail store, sharing the same versioned storage |
backend-calendar-http | CalDAV calendars with Everlock auth and versioned .ics storage |
backend-contacts-http | CardDAV contacts with Everlock auth and versioned .vcf storage |
backend-oauth-http | OAuth2 / OIDC token issuance with versioned client and key storage |
Shared resource crates
Some heavy resources are owned by their own crate so multiple backends can consume the same instance without loading it twice:
| Crate | Owned resource | Consumers |
|---|---|---|
everlock-mail-storage | Mail tree layout, IMAP UID allocator, MailEventBus | backend-mail-smtp, backend-mail-imap |
everlock-ai-runtime | Embedded GGUF model + llama.cpp worker thread | backend-ai-ssh, backend-image-http |
everlock-acme | ACME account + challenge handling | frontend-http |
Multi-instance model
Backends differ in whether they can serve multiple independent instances from a single Everlock process, each on its own vhost.
| Backend | Model | Instances managed via |
|---|---|---|
backend-site-http | Multi-instance, multi-vhost | /site create / /site set — hot-reload |
backend-image-http | Multi-instance, multi-vhost | /image create / /image set — vhost changes hot-reload, create/delete require restart |
backend-oci-http | Multi-instance, multi-vhost | /oci create / /oci set — hot-reload |
backend-calendar-http | Multi-instance, multi-vhost | /calendar create / /calendar set — restart required |
backend-contacts-http | Multi-instance, multi-vhost | /contacts create / /contacts set — restart required |
backend-git-ssh | Multi-repo, single backend | /git repo create — repositories within one backend |
backend-mail-smtp / backend-mail-imap | Single shared store, multi-domain | /mail domains create — domains within one store |
backend-dns-dns | Global, single instance | /dns zones create — zones within one backend |
backend-admin-ssh / backend-admin-http | Single instance | CLI flags only |
backend-ai-ssh | Single instance | CLI flags only |
Hot-reload means vhost routing updates take effect immediately without restarting Everlock. Backends that require restart do so because their instance initialisation involves async startup work (spawning workers, opening connections) that cannot be done inline in a command handler.
Design rule
A backend should expose domain operations and storage rules. It should not own SSH packet parsing, HTTP routing, or SMTP session handling. Those live in frontends.
For a broader summary, continue with Frontends or Primitives.