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, including an e-paper photo frame endpoint
backend-admin-ssh / backend-admin-http / backend-admin-mcp	Admin interaction surfaces — thin outlets over the shared everlock-admin-core command engine
backend-dns-dns	Global authoritative DNS record logic served through frontend-dns
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
backend-vault-http	Bitwarden-compatible, end-to-end-encrypted password vault with versioned per-instance storage

backend-dns-http holds the capability trait for a DNS management API; DNS records are managed through the admin console (/dns) today.

Shared resource components

Some heavy resources live in their own component so multiple backends can use 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 + self-developed gguf-runner 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-vault-http	Multi-instance, multi-vhost	/backends enable vault-http to turn on; instances via config/vault-http.toml / CLI flags — 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 / backend-admin-mcp	Single instance	CLI flags; the HTTP outlets pin their vhost via the admin.http.vhost / admin.mcp.vhost server settings
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.