Everlock architecture

Everlock is organized around a simple rule: transport and service logic stay in separate components.

flowchart LR
subgraph Frontends
  SSH[frontend-ssh]
  HTTP[frontend-http]
  DNS[frontend-dns]
  SMTP[frontend-smtp]
  IMAP[frontend-imap]
  MDNS[frontend-mdns]
end
subgraph Backends
  GIT[backend-git-ssh]
  AI[backend-ai-ssh]
  ADMINS[backend-admin-ssh]
  ADMINH[backend-admin-http]
  ADMINM[backend-admin-mcp]
  SITE[backend-site-http]
  IMAGE[backend-image-http]
  OCI[backend-oci-http]
  CAL[backend-calendar-http]
  CONTACTS[backend-contacts-http]
  OAUTH[backend-oauth-http]
  VAULT[backend-vault-http]
  DNSH[backend-dns-http]
  DNSB[backend-dns-dns]
  MAIL[backend-mail-smtp]
  MAILI[backend-mail-imap]
end
subgraph Primitives
  subgraph VS [versioned-storage]
    SYSSTORE[everlock-system.git]
    DNSSTORE[everlock-dns.git]
    MAILSTORE[everlock-mail.git]
    CALSTORE[everlock-calendar.git]
    CONTACTSSTORE[everlock-contacts.git]
    VAULTSTORE[everlock-vault.git]
    SITESTORE["<site-name>.git"]
    OCISTORE["<registry-name>.git"]
    IMGSTORE["<image-name>.git"]
  end
  USER[user]
  JOBS[jobs]
end
SSH --> GIT
SSH --> AI
SSH --> ADMINS
HTTP --> SITE
HTTP --> IMAGE
HTTP --> OCI
HTTP --> ADMINH
HTTP --> ADMINM
HTTP --> CAL
HTTP --> CONTACTS
HTTP --> OAUTH
HTTP --> VAULT
HTTP --> DNSH
DNS --> DNSB
SMTP --> MAIL
IMAP --> MAILI
GIT --> SITESTORE
SITE --> SITESTORE
MAIL --> MAILSTORE
MAILI --> MAILSTORE
CAL --> CALSTORE
CONTACTS --> CONTACTSSTORE
VAULT --> VAULTSTORE
OCI --> OCISTORE
IMAGE --> IMGSTORE
ADMINS --> SYSSTORE
ADMINH --> SYSSTORE
ADMINM --> SYSSTORE
OAUTH --> SYSSTORE
DNSH --> DNSSTORE
DNSB --> DNSSTORE
ADMINS --> JOBS
JOBS --> SYSSTORE

The broker model

At the top level, Everlock is one binary that loads configuration, starts the enabled modules, and routes requests to the right backend instances. A frontend answers the question, "how does a client arrive here?" A backend answers, "what domain operation is this system performing?"

Frontends

The current transport model documented in the repository includes:

The HTTP frontend is explicitly vhost-driven. It does not assume a global route table.

Backends

Backends are grouped by domain and stay transport-agnostic. Today the repository includes implemented backend families for Git, sites, images, OCI, mail (SMTP + IMAP), DNS, calendars, contacts, OAuth, a Bitwarden-compatible password vault, AI, and the three admin outlets (SSH console, HTTP dashboard, and MCP tools), all thin layers over the shared everlock-admin-core command engine.

The naming scheme reflects that separation:

• backend-git-ssh
• backend-site-http
• backend-dns-dns
• backend-admin-ssh
• backend-admin-http
• backend-admin-mcp

Shared primitives

The architecture doc anchors every service on three reusable primitives:

This keeps the project from fragmenting into backend-specific identity and storage models. If a backend needs a custom file layout, that layout belongs to the backend rather than to a generic shared storage layer.

Two further shared components sit alongside the primitives. They own resources that more than one backend depends on:

The pattern is the same in both cases: one component owns the heavy resource, exposes small traits, and backends register or consume those traits through the BackendRegistry.

Security posture

One of the most important architectural constraints in the project is the "embed over execute" rule. Everlock is not meant to shell out to git, sh, or other host tools. That keeps the static binary contract intact and reduces avoidable command-injection and environment-leak problems.

Read more

• Docs: frontends
• Docs
• Sites
• Git
• Docs: primitives
• Implemented vs planned