General settings reference

Every field on Settings → General, grouped exactly as on the page. Settings are stored as a single versioned document — the form uses optimistic concurrency, so if another admin saved while you were editing, your save is rejected with a conflict and the page reloads the current values.

Approval requirements

When a toggle is on, operators must get admin/owner approval before performing that operation. Admins and owners are auto-approved but still go through the request flow, so the action is captured as an approval record.

Field	Gated operation	Default
require_approval_for_issue	Issuing new certificates	off
require_approval_for_reissue	Reissuing existing certificates with new parameters	off
require_approval_for_renew	Renewing certificates approaching expiration	off
require_approval_for_revoke	Revoking active certificates	off
require_approval_for_download	Downloading certificate private keys	off
config_change_approval_disabled	Operator create/update/delete of distribution configuration — targets, target groups (and their members), PathSets, ActionSets, project variables, module configs	gate on (field defaults to false)
require_approval_for_distribution	Operator distribution link / update / unlink / execute / rollback	off

caution

config_change_approval_disabled reads backwards

It is a kill switch, so false (the default) means the gate is ON. The UI presents it positively as "Require approval for configuration changes", and leaving that switch on is the default state. It is stored inverted because settings are a single JSON document with no per-field migration — an upgraded instance that has never saved the field must still come up with the gate enabled.

Three consequences worth knowing before you upgrade:

• Those configuration writes were admin-only before; operators gained them together with the gate. Module credentials stay admin-only, as do health checks.
• A gated operator write answers 202 Accepted with an approval request instead of the created or updated resource. Scripted clients that read an id out of the response must handle that shape — or run as an admin, who bypasses both gates.
• Only an owner can change either of these two toggles.

Only the manual, operator-initiated action is gated. The scheduler's automatic post-renewal distribution is not gated — gating it would block renewals.

See Certificate policy & approval workflow for the request/approve/reject flow.

Certificate defaults

Defaults applied to new certificates; each can be overridden per certificate at issue time.

Field	What it does	Range	Default
default_renewal_threshold_days	Days before expiration at which a certificate becomes eligible for automatic renewal.	1–90 days	30
default_key_type	Default key algorithm for new certificates. ECDSA is faster and smaller; RSA has broader legacy compatibility.	ECDSA-P256, ECDSA-P384, RSA-2048, RSA-3072, RSA-4096	ECDSA-P256
default_key_rotation_policy	Reuse keeps the same private key across renewals; Rotate generates a fresh key each time.	reuse / rotate	reuse
default_auto_renew	Whether new certificates are automatically renewed before expiration.	on / off	on
cert_history_max_versions	How many certificate versions (current + historical) to retain per certificate — labelled History Versions in the UI. Older versions and any private key no longer referenced by a retained version are pruned automatically at every artifact write (issuance, renewal, and certificate import alike — not only at renewal). A version that a distribution still references is pinned and never pruned. 0 = the default (10); -1 = unlimited.	-1–100	10

See Renewal for how the renewal sweep uses the threshold, and Download a certificate for browsing/downloading retained versions.

Runtime limits

warning

These settings directly affect system performance and resource usage. The page shows the same warning.

Field	What it does	Range	Default
renewal_check_interval_minutes	How often the scheduler scans for certificates that need renewal. Lower values detect expiring certs faster but increase database load.	5–1440 min	60
domain_check_interval_minutes	How often tracked domains are checked for certificate changes or expiration on remote endpoints.	5–1440 min	60
domain_check_batch_size	Number of domains checked concurrently per scan cycle.	1–500	50
default_max_job_attempts	Retry attempts for failed jobs before they are marked permanently failed.	1–10	3
distribution_execution_timeout_minutes	Maximum time a distribution job may run across all its targets; the job is cancelled if exceeded.	5–120 min	30
distribution_parallel_execution_enabled	Distribution modules process targets concurrently. Disable to force sequential execution (one target at a time) for every module as a safety fallback — it wins over distribution_ssh_max_concurrency, which is not consulted while this is off.	on / off	on
distribution_ssh_max_concurrency	System-level override for SSH distribution concurrency. 0 = use the module config default (10). Higher values speed up large deployments but may hit remote sshd connection limits.	0–50	0
distribution_fanout_threshold	Target count above which a distribution is split into parallel child jobs. 0 = disabled (single job for all targets). Recommended: 50+.	0–500	0
distribution_fanout_batch_size	Targets per child job when fan-out is active. 0 = default (50). Smaller values create more parallel jobs.	0–200	0

The three distribution_* fan-out fields drive the fan-out execution engine — see Distribution fan-out.

DNS propagation

These fields control the local propagation gate that runs before the CA is asked to validate a DNS-01 challenge. They matter most on locked-down networks — see DNS propagation settings for scenario guidance.

Field	What it does	Range	Default
dns_propagation_timeout_seconds	Maximum time to wait for DNS challenge records to propagate before giving up on ACME validation.	30–600 s	120
dns_propagation_poll_interval_seconds	How often propagation is re-checked during validation. Must be less than the propagation timeout (the form enforces this).	2–60 s	5
dns_resolvers	Resolvers used for the manual-DNS TXT propagation pre-check. Entries are host or host:port; bare hosts default to port 53 (e.g. 10.0.0.53 or dns.internal:53). Empty = public default (8.8.8.8, 8.8.4.4, 1.1.1.1).	list	empty
dns_propagation_allow_partial	Off (strict, default): a TXT record counts as propagated only if every resolver returns it. On: a single agreeing resolver is enough — for networks that can reach only one resolver.	on / off	off
dns_propagation_skip_precheck	Off (default): manual-DNS Validate first confirms the TXT record is visible via the resolvers above before asking the CA. On: skip the local gate and let the CA validate directly — for split-horizon networks where the local check can't see what the CA sees.	on / off	off

Skip pre-check trade-off

The pre-check is only an optimisation — the CA is the authoritative validator and does its own lookup. But if you skip the gate and the record isn't actually ready, a CA validation attempt is wasted, and failed validations count against the CA's rate limits.

See Manual DNS validation for the workflow these settings gate.

UI preferences

Field	What it does	Range	Default
default_page_size	Items shown per page in tables throughout the UI.	5–100	20
dashboard_refresh_interval_seconds	How often the dashboard auto-refreshes. Lower values are closer to real-time but increase API calls.	10–3600 s	60

See also

• Scheduler status & sweeps — where the interval settings take effect
• Distribution fan-out
• DNS propagation settings
• Certificate policy & approval workflow