Files
steward/docs/configuration.md
T
abrown38andClaude Opus 5.5 7b3f0f764c The web UI's certificate from Let's Encrypt, through Jarl
tls.acme names the certificate and jarl: the Jarl server and a token that
may only write the challenge record. Steward gets the certificate with
DNS-01 (lego), writing the record through Jarl's API into every view that
has the zone, renews it with a third of its lifetime left and swaps it
in without a restart. A check runs before every order: Jarl, the zone,
the token's permission, a test record, the zone's name servers, public
resolvers, clean-up; each step says what to fix. Staging by default.

With a certificate, each listener serves HTTPS and plain HTTP on one port
(redirecting plain HTTP, except from the server itself).

steward cert / cert check / cert renew, Server -> Certificate in the web
UI, GET /certificate, POST /certificate/check|renew. docs/certificates.md
and docs/jarl.md (the Jarl user and the token's grant).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-14 15:46:36 +01:00

2.6 KiB

Configuration file

/etc/steward/steward.yaml says how stewardd runs. The DHCP configuration (subnets, pools, reservations, options) isn't here; it is in the database, changed with the CLI or the web UI.

stewardd config --example prints a commented file with the defaults. Every setting is optional; unknown settings are an error. stewardd reads the file when it starts.

Setting Default
listen ["127.0.0.1:8067"] addresses of the web UI and API (host:port). Keep them on localhost or a management network
tls.cert_file, tls.key_file none serve HTTPS with this certificate; stewardd rereads it when the file changes, or on systemctl reload steward
tls.acme.* off get the certificate from Let's Encrypt, with Jarl publishing the challenge (certificates.md)
jarl.server, jarl.token_file (or jarl.token), jarl.ca_cert, jarl.insecure none the Jarl server Steward uses for DNS, and its token (jarl.md)
trusted_proxies [] addresses or prefixes of reverse proxies whose X-Forwarded-For and X-Forwarded-Proto are believed
socket /run/steward/steward.sock the local API socket; "" turns it off
database /var/lib/steward/steward.db the SQLite database: configuration, leases, history, users, audit log
log.level info debug (every HTTP request), info, warn or error
log.format text text or json
session.lifetime 12h how long a web UI login lasts
session.idle_timeout 2h logged out after this long without use
session.cookie_secure auto auto (secure over HTTPS), always or never
backup.dir /var/backups/steward where stewardd backup writes
backup.retention 30d backups older than this are deleted…
backup.keep_at_least 7 …keeping at least this many

Durations are written 15s, 12h or 30d.

HTTPS

Over plain HTTP, passwords and tokens cross the network in the clear; stewardd warns when it listens on a non-loopback address without TLS. Let it get its own certificate through Jarl (certificates.md), or give it one:

listen: ["10.0.10.2:8067"]
tls:
  cert_file: /etc/steward/tls/fullchain.pem
  key_file: /etc/steward/tls/privkey.pem

Or keep it on 127.0.0.1 behind a reverse proxy that terminates TLS, and list the proxy in trusted_proxies. With a certificate, the same port answers HTTPS and redirects plain HTTP to it, except from the server itself. Ports below 1024 work too: the unit grants CAP_NET_BIND_SERVICE for DHCP's port 67.