Publishing a site over public HTTPS

This page covers the full path from a working local site to a live public site with automatic HTTPS certificate management. Everlock handles certificate issuance and renewal through ACME (the same protocol used by Let's Encrypt) without any external tooling.

Prerequisites

Before you start, you need:

an Everlock instance reachable from the internet on ports 80 and 443
a domain name with a DNS A record pointing at that server's IP
the site already created in Everlock (see Getting started with a Markdown site)

ACME certificate issuance uses the http-01 challenge, which means Everlock needs to be reachable on port 80 from Let's Encrypt's servers at the moment it requests a certificate. The domain must resolve to your server's public IP before you start.

Step 1 — Configure the HTTP frontend

Everlock's HTTP frontend reads its settings from config/frontend-http.toml inside the Everlock data directory. Create or edit that file:

listen_http  = "0.0.0.0:80"
listen_https = "0.0.0.0:443"
acme_email   = "ops@yourdomain.com"
redirect_http_to_https = true

Field	Required	Purpose
`listen_http`	Yes	Port for HTTP traffic and ACME challenges
`listen_https`	Yes	Port for HTTPS traffic; triggers ACME when set
`acme_email`	No	Contact email on the ACME account; without it the account is created without a contact
`redirect_http_to_https`	No	When `true` (the default), HTTP requests for a public host redirect to HTTPS once its certificate is served

The redirect is a 308 Permanent Redirect to the port the HTTPS listener is actually bound on, read from its sockets (socket activation included), so listen_https = "0.0.0.0:8443" redirects to https://<host>:8443/…. The URL leaves the port out when it is 443. When the listener binds several ports, the redirect uses 443 if it is among them and the lowest port otherwise. ACME challenge requests (/.well-known/acme-challenge/…) are never redirected.

The contact email can also be set at runtime with /server settings set acme.email — the setting wins over the CLI flag and this file.

Step 2 — Map your domain to the site

In the admin console, add your public domain as a vhost on the site:

/site set my-docs vhost=docs.yourdomain.com

If the site backend is already running, this takes effect immediately without a restart — Everlock also requests the Let's Encrypt certificate for the new public vhost in the background and starts serving it the moment it is issued. You can confirm the mapping with:

/site list

Expected output shape:

  my-docs  (store: my-docs, auth: public, mode: markdown)
    vhosts: localhost, docs.yourdomain.com
    clone:  ssh://admin@localhost:2222/my-docs

Step 3 — Restart once to apply the listener config

This restart is a one-time step needed only because you edited frontend-http.toml by hand — a hand edit isn't picked up live. Restart the Everlock process once so it binds the HTTPS listener with your new listen_https / acme_email:

# If running via systemd
systemctl restart everlock

# If running directly
kill <pid> && everlock serve

On startup, Everlock will:

bind the HTTP listener on port 80, which answers the ACME challenges
detect which vhosts are public hosts: public hostnames and publicly routable IP addresses
request a certificate from Let's Encrypt for each public host that needs one, one host at a time
bind the HTTPS listener on port 443, serving every certificate issued in step 3 from its first connection

A host whose request fails is retried by the renewal sweep with a backoff, and HTTPS binds either way. The first certificate request takes a few seconds. Everlock logs the outcome:

HTTP server listening on http://0.0.0.0:80
frontend-http: issuing or renewing certificate for docs.yourdomain.com
frontend-http: certificate for docs.yourdomain.com persisted
HTTPS server listening on https://0.0.0.0:443

How ACME works here

Everlock uses the http-01 challenge. Let's Encrypt sends a request to http://<your-domain>/.well-known/acme-challenge/<token> to verify that you control the domain. Everlock responds to this challenge automatically on the HTTP listener. No separate certbot, nginx, or external tool is involved.

The certificate and private key are stored in:

config/<hostname>/fullchain.pem
config/<hostname>/privkey.pem

Renewal is also automatic. Everlock checks the certificate expiry at startup and renews it if it expires within acme_renew_before_days (default: 30 days).

Using a staging CA for testing

Let's Encrypt's production CA has strict rate limits. When testing the setup, use the staging endpoint to avoid hitting those limits:

acme_directory = "https://acme-staging-v02.api.letsencrypt.org/directory"

Staging certificates are not trusted by browsers, but they let you verify that the whole issuance flow works before switching to production. Remove the acme_directory line (or set it to the production URL) when you're ready.

Local and development vhosts are never ACME-managed

Everlock automatically skips ACME for hosts that cannot have publicly trusted certificates:

localhost
anything ending in .local (mDNS hostnames)
private IP addresses (loopback, LAN, link-local and similar ranges)

These vhosts are served over plain HTTP regardless of whether listen_https is configured. This means you can add localhost as a vhost for local development and docs.yourdomain.com for production, and Everlock handles each one correctly without any per-vhost configuration.

Multiple public domains

A single site can serve multiple public domains. Each gets its own certificate:

/site set my-docs vhost=docs.yourdomain.com
/site set my-docs vhost=www.yourdomain.com

Everlock issues and renews each certificate independently.

You can also run multiple separate sites on different domains from a single Everlock instance. See Multi-site setup for the full walkthrough.

Removing a public domain

/site unset my-docs vhost=docs.yourdomain.com

This removes the vhost mapping immediately without a restart. The certificate files on disk are not deleted, but they will not be renewed.