Everlock One server for your digital life

Documentation

Last updated: 2026-07-28

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
FieldRequiredPurpose
listen_httpYesPort for HTTP traffic and ACME challenges
listen_httpsYesPort for HTTPS traffic; triggers ACME when set
acme_emailNoContact email on the ACME account; without it the account is created without a contact
redirect_http_to_httpsNoWhen true, HTTP requests redirect to HTTPS automatically

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:

  1. bind the HTTP listener on port 80
  2. bind the HTTPS listener on port 443
  3. detect which vhosts are public hostnames (not localhost, *.local, or raw IP addresses)
  4. request a certificate from Let's Encrypt for each public hostname
  5. serve HTTPS immediately once the certificate is issued

The first certificate request takes a few seconds. Everlock logs the outcome:

frontend-http: issuing or renewing certificate for docs.yourdomain.com
frontend-http: certificate persisted for docs.yourdomain.com
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)
  • raw IP addresses

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.

sites https tls acme ops