AI runtime and access model
Everlock embeds a small LLM and exposes it in two places: 1. as a free-text prompt mode inside the admin SSH session (`backend-ai-ssh` + `backend-admin-ssh` + `frontend-ssh`) 2. as an image-caption
Documentation
Tag: backend
Calendar backend
The calendar backend is Everlock's CalDAV service. It lets one Everlock instance host one or more calendar namespaces over HTTP, authenticate with normal Everlock users, and persist events as readable
CalDAV behavior and storage reference
This page covers Everlock's CalDAV behavior and storage model. - served through `frontend-http` - multi-instance and multi-vhost - one dedicated `versioned-storage` store per instance - Everlock-user
Contacts backend
The contacts backend is Everlock's CardDAV service. It provides hosted address books over HTTP, backed by Everlock storage and the same user and grant model used everywhere else in the system. Use the
CardDAV behavior and storage reference
`backend-contacts-http` is a multi-instance CardDAV backend for Everlock. - multi-instance and multi-vhost - per-instance `versioned-storage` - Everlock-user HTTP authentication and `http/contacts/<in
DNS record derivation and address-mode reference
DNS is global, not multi-instance. Its state is split across: - `everlock-system/config/dns.toml` - `everlock-dns/<zone>.toml` The backend combines:
Image backend
The image backend is Everlock's HTTP-facing media library. It lets you host one or more image instances from a single Everlock process, route them by hostname, store the original media inside Everlock
Image instance and access reference
This page covers image instances, routing, and access control for Everlock's image service. The underlying media engine is [apimeister-photos](/docs/images/apimeister-photos); running several instance
OAuth backend
The OAuth backend turns Everlock into an OAuth 2 and OpenID Connect issuer for applications that should trust Everlock users. Instead of keeping a separate identity silo per app, Everlock can issue to
Provider model and configuration reference
This page covers Everlock's OAuth 2 and OpenID Connect provider model. The OAuth backend runs behind `frontend-http` and uses an Everlock `versioned-storage` store for client registrations, signing ke
Registry model and auth reference
This page covers registry storage, routing, and access control for Everlock's OCI service. The Distribution protocol itself comes from the embedded [apimeister-registry](/docs/oci/apimeister-registry)
Mail backend
The mail backend turns Everlock into a self-hosted mail system with SMTP delivery, authenticated submission, and IMAP access. It keeps incoming mail, mailbox access, forwarding rules, and mail-domain