OPERATING

Platform settings

The install-wide switches: outgoing mail, public URLs, retention, the nightly cleanup and the sign-in captcha.

Admin → System holds the settings that apply to the whole install rather than to one project: where mail goes out, how the panel refers to itself in links, how long history is kept, what runs at night, and what stands between a bot and your sign-in form.

Every setting here is stored in the database and takes effect without a restart — the values in your `.env` are the fallback used when a setting is left blank, not the other way round. Blanking a field reverts to that fallback.

Credentials entered here — the SMTP password, OAuth client secrets, the Cloudflare token, the captcha secret — are encrypted before they are stored, and the admin page never receives them back. A field showing a placeholder instead of the value you typed is working correctly; retyping it is the only way to change it.

Outgoing mail

One SMTP account, used by everything the panel sends: password resets, address verification, project invitations, deployment outcomes and monitoring alerts. Send a test delivers a message with the settings currently in the form, so you find out before a password reset does.

This is not the same thing as the mail server, which receives and serves mail for *your* domains. This is the account the panel itself sends from — and it is worth pointing at a provider you do not host on this machine, so that a broken install can still email you about it.

Public URLs

Where the dashboard and the API answer from the public internet. The panel cannot infer this — it sees the request it was handed, not the address you gave your users — so it is set once and reused wherever a link has to be written down rather than followed:

The links inside outgoing emails — a reset link pointing at localhost is the classic symptom of leaving this blank.
The redirect targets for SSO and Discord sign-in, which the provider matches exactly against what you registered with it.

Both must parse as full http(s) URLs. Set them as soon as you put a domain in front of the panel.

Retention

How long each kind of history is kept before it is pruned. Leave a field blank to use the default in the last column.

History	What it holds	Default
Server metrics	Per-host CPU, memory and disk samples behind the monitoring graphs.	30 days
Container metrics	Per-container samples, taken every 30 seconds — by far the highest-volume table here.	7 days, capped at 90
Deployments	Past deployment records and their build logs.	90 days
Audit log	Who did what, from where — see audit.	365 days

A retention window is a whole number of days between 1 and 3650; the field refuses anything else rather than accepting a typo that would quietly wipe history. Backup retention is set separately, per schedule and by age — see backups.

Container metrics are the setting to lower first if the database is growing faster than you expected, and the audit log is the one to think hardest about raising — it is the only history that answers a question you will be asked months later.

The nightly cleanup

Once a night, at an hour you choose (03:00 UTC by default), the panel reclaims the disk that Docker leaks on its own:

Images left orphaned by a rebuild, and the dangling layers under them.
The BuildKit cache, which only ever grows. Turn this off if you would rather keep first rebuilds fast.
Container logs past a size you set (200 MB by default, minimum 10). The default json-file log has no ceiling of its own.

Both cleanup switches are on out of the box. An unbounded build cache and an unbounded container log are the two usual reasons a host fills up, and neither is recoverable any other way: the cache only grows, and a running container’s log is invisible to the orphan sweep. The cost of leaving them on is a slower first rebuild and losing old log lines — both cheap next to a full disk.

The same work is available on demand from the Docker page when you need the space now rather than tonight. Volumes are never swept, by either path.

Sign-in protection

The login and registration forms are the only pages an unauthenticated visitor can reach, which makes them the only pages worth a bot’s time. Four modes:

Rate limiting only: No widget. The request throttler that is always on is the whole defence. This is the default, and it is enough for a panel only your team knows the address of.
Cloudflare Turnstile: A challenge that is usually invisible to the visitor. The gentlest of the three widgets.
hCaptcha: A visible challenge, for when you want a bot to have to give up rather than merely score badly.
reCAPTCHA v3: Scores the visitor from 0 to 1 instead of challenging them; you set the threshold below which a sign-in is refused.

Each widget takes two values: a site key, which is public and rides in the page, and a secret key, which is not and never leaves the server. The challenge is verified server-side, so a client that skips the widget is refused just the same.

Verification fails closed. If the captcha provider is unreachable, sign-ins are refused rather than waved through — an anti-bot control that opens under load is not one. Should the provider have an outage, switch the mode back to rate limiting only to recover; the setting takes effect immediately, and the switch is reachable from a session you are already signed into.

This protects the *password* door. For traffic reaching your applications, see anti-DDoS; for removing the password door altogether, see SSO and two-factor.

Integrations configured here

The rest of the page registers credentials for services documented on their own pages. They live here because they belong to the install, not to a project:

Section	What it enables
SSO	Google, GitHub and OIDC sign-in, plus the signup and allowed-domain rules — see SSO.
Discord	Alert delivery to a channel or a direct message — see monitoring.
Gitea / Forgejo	A self-hosted Git provider alongside the built-in ones — see applications.
PowerDNS	Running your own authoritative nameservers from the panel — see DNS.
Backup encryption	The passphrase archives are encrypted with — see backups.

Changing any setting on this page is written to the audit trail — the key that changed, never the value, so a rotated secret does not end up in a log you ship to an aggregator.