Self-update

Everlock can replace its own binary in place — no SSH into the server, no manual service-restart dance, no downtime beyond the few seconds it takes to hand the sockets to the new process. There are two ways an update lands:

Automatic. A daily job fetches a newer binary from everlock.sh, verifies it, and applies it. On by default.
Manual. You drop a verified binary into a staging directory and it applies on the next tick (or immediately, if you trigger the job).

The serving side — checksummed binaries behind stable /dl/latest/… paths — is built from the site engine's own downloads & redirects. This page is the apply side: how a staged binary becomes the running one.

How it works

The self-update job runs on a daily (24 h) interval, staggered by each instance's start time so a fleet never hits everlock.sh in lockstep. Each run has two halves:

Retrieve (only if auto-update is enabled). HEAD the asset for this build's variant/platform, compare the advertised X-Everlock-SHA256 to the running exe. On a difference, GET the binary, re-hash to verify, and write it to the staging file. Unreachable host → logged and skipped; the apply half still runs.
Apply. Read the staging file (<data-dir>/everlock-updates/everlock.new, or everlock.exe.new on Windows), SHA-256-compare it to the running exe, and if they differ:
1. Write the new bytes to a temp file alongside the current exe.
2. Rename the current exe to everlock.old (kept as a one-step rollback copy).
3. Rename the new binary into place, and remove the staging file.
4. Trigger the graceful restart (below).

The decision is purely digest-driven — identical bytes never trigger a restart, and there is no version comparison. If everlock.sh moves latest back to an older build, its digest differs from the running exe and the engine follows it — a server-side rollback the fleet picks up.

The staged binary is a plain file in the data dir; the rollback copy is the on-disk .old next to the running exe.

Automatic updates

On by default. Once a day the server checks everlock.sh, and on a new digest it downloads, verifies, and applies — then takes the graceful restart. Under systemd with socket activation the socket stays bound across the swap, so the hand-off is seamless (see the systemd guide).

Three ways to turn it off, coarsest last:

# Live, from the admin console (persists in everlock-system settings)
/server settings set update.enabled false

# Per launch (env or flag)
EVERLOCK_UPDATE_ENABLED=false everlock serve …

# Hard off — beats the stored setting; the escape hatch for pinning a recovered binary
everlock serve … --no-update

Where updates come from is configurable too:

--update-url (env EVERLOCK_UPDATE_URL) — the base URL to fetch from, https://everlock.sh by default. Point it at a private mirror that serves the same path shape.
--update-pin (env EVERLOCK_UPDATE_PIN) — track a fixed version path (e.g. 0.4) instead of latest.

Manual updates

Use this for air-gapped hosts, a custom build, or a version everlock.sh isn't serving. Drop the binary at the staging path and let the apply half pick it up:

# 1. Copy the new binary into place (must be the exact bytes you want to run).
mkdir -p <data-dir>/everlock-updates
cp /path/to/new-everlock <data-dir>/everlock-updates/everlock.new

# 2. Apply immediately from the admin console (or wait for the daily tick).
#    The job kind is the registered handler name:
/jobs run system.self-update

Notes:

The staged file does not need the executable bit — it's read as bytes and re-permissioned when written next to the current exe.
It only applies when its SHA-256 differs from the running exe.

Watch the log for confirmation:

INFO  everlock_jobs::self_update  self-update: new binary detected (sha256: e5f6a7b8→a1b2c3d4), applying
INFO  everlock_jobs::self_update  self-update: binary replaced (previous kept at /usr/local/bin/everlock.old)
INFO  everlock                    jobs: system.self-update (…) succeeded: update staged, restarting

Rollback

The previous binary is kept at <exe-path>.old (e.g. /usr/local/bin/everlock.old). To roll back:

mv /usr/local/bin/everlock.old /usr/local/bin/everlock
systemctl restart everlock          # or your supervisor's restart

To make the rollback stick, prevent the next tick from re-fetching the "bad" latest:

Start with --no-update, or
/server settings set update.enabled false, or
clear any leftover staged file: rm -f <data-dir>/everlock-updates/everlock.new.

One generation is kept (.old). To go further back, fetch that version from everlock.sh (or supply your own binary) via the manual flow above.

Restart model

The apply step never restarts inline — it flags a restart and triggers the same graceful drain used by /backends enable and systemctl stop. The main loop then re-launches:

Platform	Restart mechanism	Downtime
Linux / macOS (systemd socket activation)	Drain, exit; systemd keeps the socket bound and starts the new binary	~1–2 s (backlog preserved)
Linux / macOS (standalone)	`exec()` in-place — same PID, args, and environment; listeners rebind	~1–2 s (socket rebind)
Windows	Spawn the new binary, old process exits `0`; a supervisor restarts the service	~2–5 s (new process start)

On Windows a process supervisor (Windows Service, NSSM, WinSW, …) is required for the service to come back automatically. Without one the update is still applied (the new binary is in place); you start the process manually once after it exits.

Restart=always is required in the systemd unit — a socket-activated update drains and exits, and that's what brings the new binary back up. The systemd guide covers the full unit setup.

Security

Network trust. Auto-fetch runs code from everlock.sh as the server. Trust rests on HTTPS + everlock.sh and a SHA-256 integrity check, so a corrupted or truncated download never applies; --no-update pins the current binary.
Staging is filesystem-scoped. A manual update writes to <data-dir>/everlock-updates/ under the data directory; who can push an update is governed by host filesystem permissions on that directory, not by the git access model. Lock the data dir down to the service user.
Digest-gated apply. The binary is only replaced when its SHA-256 actually differs from the running exe — identical content never triggers a restart.
One-step rollback. The .old copy is a local, offline fallback that does not depend on the server (or any store) being reachable.