How to read the reference

The Reference section answers “what exists” for a self-hosted deployment: the environment variables the application documents, the commands its command line registers, the jobs its scheduler can run, and the endpoints that report its health.

Reference pages report. They do not recommend. When you need to decide which value to set, follow the link from the entry to the guide that explains the choice, or start from About self-hosting.

Where these facts come from

Every page here is scoped to one release of the application. A snapshot of that release’s own reference inputs is stored in this repository, and the pages are rendered from that snapshot rather than written by hand, so a page cannot drift from the release it names without the snapshot changing first.

Each page states its release and commit in its opening sentence, and its frontmatter cites the application files the facts were read from. A fact that could not be established from the source is labelled as undetermined rather than filled in with a plausible value.

Nothing on these pages was produced by running the application. Where a guarantee depends on how a deployment behaves at run time, the page says what the source shows and leaves the rest to the operator’s own checks.

Declared defaults and example values

The three things an entry can show about a value are different, and the distinction matters more than it looks:

• A declared default is the value the source states the application uses when you set nothing. It is safe to reason about.
• An example line is the line as the application’s own reference file writes it, commented out or active, with whatever placeholder value that file chose. It shows the shape of the setting, not a recommendation, and it is never the same claim as a default.
• An undetermined value means the source did not settle the question. Treat it as a question for your deployment, not as an absence of behaviour.

Unset, empty, null, omitted, derived and run-time dependent are also distinct states, and an entry keeps them distinct. An empty string is a value. In this application an empty string is also truthy, so a variable set to nothing is not the same as a variable left alone.

A value listed here is what the application resolves on its own. Your deployment’s own configuration files layer on top of it, so the effective value in a running instance can differ from the default an entry shows.

What is here

• Environment variables covers every variable the application documents, grouped the way its own reference file groups them, with the example line, declared default and release annotation for each.
• Command line reference covers every registered command, what it writes, the flag that lets it write, its effects outside the host and what it needs in order to run.
• Scheduled jobs reference covers every job the scheduler can register, its trigger, the key that enables it and what it changes.
• Health endpoints reference covers the health and status endpoints, who may reach them, what they return and which subsystems each one actually probes.

The configuration pages cover the YAML files. Configuration files and precedence explains which files the application reads, how their values combine and how an environment variable reaches a key; Site and interface, Features and branding, Datastore and queues, Email and delivery and Auth, logging and billing files publish the key records themselves. The Configuration generator produces a starting set of files from a few choices about your deployment.

When a release moves on

The snapshot is refreshed deliberately, by a maintainer, against a chosen release. A refresh regenerates these pages and shows the change as a reviewable difference, so a new variable or a changed default arrives as an edit someone approved rather than as a silent correction.

If your deployment runs a release newer than the one a page names, treat the page as the record for the release it names. The upgrade guides carry what changed between releases and what an operator has to do about it.