Site backend

The site backend lets Everlock host websites directly from Git-backed content stores.

What it is

Each site is mapped to one or more hostnames and backed by a repository that holds the actual content. Push changes to the repository, and Everlock serves the new site state over HTTP.

Today there are two practical modes:

html: serve files as they exist in the repository
markdown: render Markdown pages, generated lists, feeds, search, templates, taxonomies, and shortcodes

What it supports today

plain static HTML sites
Markdown sites with generated lists, feeds, templates, taxonomies, and search
public sites such as everlock.sh
private sites protected by normal Everlock grants

Typical setup flow

There are three separate concerns that work together:

enable the backend
create a site entry
push content into the store

1. Enable the backend

For a practical site setup, you normally enable both the site backend and the Git backend together:

/backends enable site-http git-ssh

The site backend serves content, and the Git backend is how you publish that content.

Expected result:

  enabled: site-http, git-ssh
  restart required

2. Create a site

Create a public Markdown site:

/site create everlock-docs vhost=docs.local mode=markdown

Or create a plain HTML site:

/site create landing vhost=landing.local mode=html

Expected output shape:

  Site 'everlock-docs' created (store: everlock-docs, auth: public).
  Granted admin write access to push content: */git/everlock-docs
  Add vhosts with: /site set everlock-docs vhost=<host>

This creates the site record and its initial access model:

creates or registers the site name
associates it with a store name
maps one or more vhosts to that store
records the mode (html or markdown)
grants the creator write access to the Git store
grants the creator owner access on http/site/<site-name>

3. Push content

Once the site exists, clone the repository shown by /site list and push content into it:

git clone ssh://admin@localhost:2222/everlock-docs
cd everlock-docs
git add .
git commit -m "initial content"
git push

Everlock serves the updated content directly from that repository state.

Expected result:

the repository behaves like a normal Git checkout
git push publishes the new site state immediately
the HTTP site now serves the updated content from the same store

How public hosting fits in

If the site is meant to be public under a real hostname, there is one more layer involved: the HTTP frontend.

For example:

register the site vhost such as everlock.sh
configure frontend-http with plain HTTP and HTTPS listeners
provide an ACME contact email

Conceptually:

the site backend knows that everlock.sh belongs to a given store
the HTTP frontend sees that everlock.sh is a public hostname
if HTTPS is enabled, the frontend manages ACME http-01
once the certificate exists, the frontend serves the site over HTTPS

So the site backend owns the content mapping, while the HTTP frontend owns transport, TLS, and certificate lifecycle.

Expected startup shape for a public HTTPS host:

frontend-http: active vhosts: everlock.sh
frontend-http: binding HTTP listener on 0.0.0.0:80
HTTP server listening on http://0.0.0.0:80
frontend-http: issuing or renewing certificate for everlock.sh
...
frontend-http: certificate persisted for everlock.sh
frontend-http: binding HTTPS listener on 0.0.0.0:443 for 1 host(s)
HTTPS server listening on https://0.0.0.0:443

How data is persisted

Two kinds of state are involved:

Everlock system configuration

This includes:

site name
store name
vhosts
auth mode
site mode

That state is stored in the Everlock system store.

Site content repository

This includes:

HTML files
Markdown pages
templates
assets
images
site.toml

That content lives in the site's own Git-backed store and is updated by git push.

How auth works

Each site can be:

public
private

public means the built-in anon user has Reader on http/site/<site-name>. private means that anon grant is removed, so only explicitly granted users or groups can read the site.