Update application settings

Global agent sandbox settings. Controls whether agent runs are isolated inside Docker containers by default. Individual agents can override this.

Bounds on one AI chat turn.

A turn is bounded by TIME rather than by a number of steps. A step count says nothing about cost or about how long someone has been watching a spinner, and it cuts short exactly the long, productive turns the chat exists for. The user can already see each tool call and press Stop; the deadline is what guarantees an unattended turn still ends.

The right value is a property of the model, which is why it is configurable rather than compiled in: a full alert-suggestion turn takes ~10 minutes against a slow local model and seconds against a hosted one.

Global AI configuration settings. Controls the default config repo containing .claude/ directory (skills, MCP servers, plugins) that gets overlaid into every agent sandbox.

Runtime limits for workspace file transfer and browser previews.

The HTTP layer additionally enforces absolute ceilings so a malformed or legacy settings row cannot turn a configurable limit into unbounded control plane memory use.

Control-plane build resource limits.

Caps how many builds run concurrently AND how much CPU/memory each build is allowed to consume. A single global semaphore in the deployer crate gates every DockerRuntime::build_image call to max_concurrent. When the semaphore is full, additional builds queue and wait — they do not fail. Per-build CPU/memory caps are forwarded to Docker via BuildImageOptions { memory, cpuquota, cpuperiod }.

cpu_limit_cores = 0.0 or memory_limit_mb = 0 means "no explicit cap" — fall back to the legacy 50%-of-host heuristic for backwards compatibility with operators who never visit the settings page.

Non-secret managed control-plane settings stored with application settings.

PartialEq but deliberately not Eq: telemetry_bulk_anomaly_factor is a float, and the total-equality contract Eq promises is one f32 cannot keep. Nothing compares two CloudSettings for equality outside this module's own tests, so the weaker bound costs nothing.

Cluster-DNS resolver settings (ADR-024, experimental beta).

When enabled, the Temps control plane starts a Hickory DNS resolver and injects it as the first nameserver into every deployed container via HostConfig.Dns — giving containers the ability to resolve *.temps.local FQDNs for service-to-service communication. Worker nodes pick this flag up from the /api/internal/nodes/{id}/network/peers wire response and gate their own per-node resolver the same way.

Default: false (disabled).

Why disabled by default: a production incident showed that when the injected Hickory resolver was slow or transiently unresponsive for a non-*.temps.local (external) hostname, glibc's resolver cycled through all three nameservers (172.20.0.1, 1.1.1.1, 8.8.8.8) at ~5 s timeout × 2 attempts each, causing 22–27 s delays for outbound TCP connections. Disabling the injection restores Docker's embedded DNS as the sole resolver, eliminating that failure mode. Operators running single/multi-node installs that depend on *.temps.local resolution must explicitly opt in by setting enabled: true.

bool defaults to false in Rust and JSON (#[serde(default)]), so the safe-off behaviour is automatic for new installs and legacy settings rows.

Per-upstream concurrent-connection limiting. Protects the proxy's own connection/file-descriptor budget from a single slow or malicious customer upstream — independent of the request/idle timeouts in RequestTimeoutSettings, which bound how long a connection may stay open, not how many may exist at once. See issue #646.

Docker container log rotation settings Controls the --log-opt max-size and --log-opt max-file for containers

Disk space alert settings for monitoring disk usage

Geolocation database configuration and freshness state.

Both the data-policy knobs an admin sets and the metadata the refresh job records live on one typed struct on purpose. The settings row is a shared JSON document and AppSettings is deserialized/reserialized in full by the generic settings endpoint, so any geo key kept outside this struct would be silently dropped the next time an unrelated settings page was saved.

The license key is stored as ciphertext only ([GeoSettings::maxmind_license_key_encrypted]). The plaintext field beside it is write-only input from the admin UI: it is skip_serializing, so it can never be persisted or returned, and [GeoSettings::apply_license_key_update] clears it after encrypting.

System-wide retention policy for locally-built deployment images.

The nightly cleanup removes a Temps-built image only once every deployment that references it is older than the owning project's retention window. Deleting an image makes rollback/promotion to that deployment impossible, so the default is deliberately generous: it is a rollback window, not a cache TTL.

MCP server settings (ADR-039).

The MCP endpoint lets AI tools (e.g. the Temps CLI wizard) interact with this Temps instance through the Model Context Protocol. Disabled by default so new installs do not expose the endpoint until the operator explicitly opts in.

bool defaults to false in Rust and JSON (#[serde(default)]), so the safe-off behaviour is automatic for new installs and legacy settings rows.

Global metrics observability configuration.

Controls whether the MetricsScraper and AlertEvaluator background tasks are active, which storage backend they write to, and how long data is kept at each retention tier.

Multi-node cluster settings

TimescaleDB compression policy configuration for append-only observability tables. Values are expressed in hours so operators can choose sub-day windows while keeping the API representation unambiguous.

Retention policy configuration for raw observability tables. Values are in days. The Settings API applies them to TimescaleDB; ClickHouse-backed proxy logs and spans retain their storage-level per-row TTL behavior.

On-demand (lazy) HTTP-01 TLS issuance settings (ADR-018).

When enabled, the proxy's certificate_callback triggers ACME HTTP-01 issuance for allowlisted, STABLE hostnames (per-environment aliases and the console host) that have no active cert, rather than silently failing the handshake. Ephemeral per-deployment hostnames are NEVER certed (ADR §2).

Off by default — operators opt in explicitly, except QuickStart (sslip.io) installs where temps setup auto-enables it and derives zone.

Workspace preview gateway settings.

The preview gateway uses a private routing container plus a hardened ingress relay bound to host loopback. The router joins each sandbox's isolated network and routes requests to workspace dev servers based on the Host header (ws-<sid>-<port>.<preview_domain>), while the relay never joins a tenant network. temps serve reconciles both containers on startup; these settings let an operator override the router image, host port, and auto-upgrade behavior.

Upstream request/connection timeouts for customer app traffic.

By default, no timeout is applied to customer app traffic at all — an existing app that happens to have a slow endpoint, a long-polling request, or an unusually long response must keep working exactly as it did before this setting existed. Timeouts here are opt-in: an operator can set a global default, and/or a project/environment can set its own override (DeploymentConfig::request_timeout_seconds / sse_idle_timeout_seconds / websocket_idle_timeout_seconds), but until one of those is explicitly configured, the proxy holds the connection open indefinitely (bounded only by TCP/OS-level limits).

default_*_timeout_seconds of 0 means "no timeout" — this is the out-of-the-box value for all three. max_request_timeout_seconds is a hard ceiling that only comes into play once a timeout is actually configured (globally or per project/environment): whatever value is resolved is always clamped to it, so lowering the ceiling here takes effect immediately without needing every environment row re-saved. It never creates a timeout for traffic that has none.

Controls the console's one-click "Update now" action.

Ceilings on the resource overrides a tenant may set for their own project or environment.

The knobs these bound (memory_limit, max_concurrent_connections, the request/idle timeouts) are deliberately uncapped-by-sentinel: 0 means "unlimited". That is the right default for a single-team self-hosted install, where the person editing a project is the operator. It is the wrong default on a shared host, where it lets one project opt out of the operator's protection and take the node — or the shared proxy's connection budget — down with it.

Every ceiling here is therefore off by default, and turning one on is what makes the corresponding tenant override enforceable. A caller holding Permission::SettingsWrite (operators: Admin/PlatformAdmin, never Role::User) may still exceed them — the ceiling constrains tenants, not the operator who set it.

Violations are rejected, not clamped: silently rewriting a value the user asked for leaves them debugging a limit they believe they removed, and self-hosted operators have no support channel to ask.