Configuration and environment

Both binaries read one YAML file (--config, default /etc/peart/config.yaml), and each reads only its own sections. The shipped config.example.yaml is the authoritative, commented reference and does not run as-is (its render token is a placeholder the validator rejects). This page is the field summary; see First run and configuration for the walkthrough.

Paths

Field	Meaning
db_path	The SQLite database file.
master_key_path	The master key. Must never equal or sit inside any data root; boot refuses it there. Created on first boot if absent.
evidence_root	Encrypted evidence.
rendition_root, report_root	Client-facing renditions and generated reports.
logo_root, avatar_root, installation_root	Client logos, account avatars, installation assets.

Every path must exist and be writable by the running user, except master_key_path's own parent, which PEART writes the key into on first boot.

Surfaces

Field	Meaning
internal.listen_addr	Internal surface listen address (e.g. :8080).
portal.listen_addr	Portal listen address (e.g. :8081).
internal.public_url, portal.public_url	The external base URL of each surface (scheme + host), from which enrollment and other absolute links are built. Optional, normalized (no trailing slash), and when set must be absolute; https is required when tls: true.

TLS and sessions

Field	Meaning
tls	true means a reverse proxy terminates TLS in front; turns on HSTS.
accept_insecure_http	Must be true for tls: false to start at all.
session.inactivity_timeout, session.absolute_timeout	Shared session policy; default 1h / 12h. Inactivity cannot exceed a fixed maximum (4h).

Rendering sidecar

Field	Meaning
render.base_url	How the process reaches the sidecar (http://127.0.0.1:8090 for systemd, http://peart-render:8090 for compose).
render.token	Shared secret checked on every render request; PEART_RENDER_TOKEN in the environment overrides it.
render.work_root	The shared work directory for staged render jobs.
render.timeout	Per-render timeout.

Notifications and the outbound webhook

Field	Meaning
notification.severities	Which finding severities create a notification row when published. Omitting the block falls back to critical and high; a value outside critical, high, medium, low, info is a boot error, so a typo fails loudly instead of never matching.
webhook.url	Where the signed event is posted. No url at all means no dispatch and no boot error, which is the documented way to leave it off.
webhook.secret	Shared HMAC-SHA256 key every request body is signed with, in the X-Peart-Signature header. A url without a secret refuses to boot.
webhook.timeout	Per-request timeout; omitted falls back to 5s.

PEART never sends email. What it emits is one identifier-only event, after a finding is published at a severity the list names, or a report is released to the portal, and the operator routes that single signal to wherever it has to arrive (a chat bridge, a mailer, an internal queue). The payload carries identifiers and classification, never finding content, for the same reason the audit trail does not copy content: a webhook body is the least controlled place in the deployment.

Environment

PEART_RENDER_TOKEN is the one secret the internal process and the sidecar must share; when set it is preferred over render.token, so a compose deployment keeps it in one .env entry both containers read. The systemd units read their per-service EnvironmentFile under /etc/peart (peart.env, portal.env, render.env).