# Administration dashboard and preferences

The authenticated panel is the primary way to manage RustProxy. Pages cover **Overview**, **Vhosts**, **Web Server**, **Certificates**, **Docker vhosts**, **Streams**, **Traffic**, **Cache**, **Logs**, **Settings** and **Documentation**. Availability of individual cards depends on enabled features and the account's display preferences.

## Stylesheet updates

The panel and login page load one versioned stylesheet embedded in the Rust
binary. Source styles are split into eight modules and assembled during the
build. Rebuild the binary to apply CSS changes; copying individual CSS files to
an installed server does not update the panel. The authenticated documentation
page has its own stylesheet.

## Overview cards and layouts

The Overview contains live counters, charts and optional backend, cache, PHP, Docker and Stream cards. Under **Settings → Appearance → Dashboard layout** or the Overview editor, configure visibility, order, card width, density and the number of history samples. A hidden card stops consuming its optional browser-side visualization work but does not turn off its underlying proxy feature.

In 0.34.1, the unlocked Overview layout exposes a single **Save and lock** action (plus Cancel), removing the redundant lock-and-save button.

**Dashboard Presets** supports up to **16 named layouts per administrator**. Save, load, rename, overwrite and delete presets; a factory layout can be restored. Presets preserve the dashboard arrangement, not the live traffic values. Interface theme, scale and other display settings are also account-scoped and do not alter proxy routing or rewrite shared configuration.

## Editing configuration safely

1. Open the relevant workspace and inspect existing state before editing.
2. Change a logically related group of settings and review the editor's effective-preview/status where available.
3. Save against the expected current configuration revision. A stale edit should be reloaded instead of silently overwriting a newer change.
4. Confirm whether the saved setting is active immediately or requires a process restart (notably listener binds and administration HTTPS).
5. Check the live page and request logs after sending test traffic.

Unfinished editors may be minimized into a draft dock; this is a UI convenience and **not** a durable change or backup until saved.

## History and restore

**Configuration history** stores retained validated snapshots. Restoring a snapshot creates a new configuration revision. It does not restore every filesystem file, external certificate, Secret Store key or accumulated cache/log history. For disaster recovery, use a full encrypted backup; see [Backup](BACKUP.md).

## Interpreting charts

- The **Cache hit ratio** donut shows cumulative `HIT / (HIT + MISS)`: BYPASS and requests outside cache are deliberately excluded from its denominator.
- The **Cache outcomes** compact horizontal 100% bar is **hidden by default**; enable it in **Settings → Appearance → Dashboard layout** or the Overview layout editor. It summarizes **cumulative request counters since the current service process started**, not recent polling intervals. The upper-right number shows the total HTTP requests since service start (full description in its tooltip and accessible label); the legend shows counts and percentages for HIT, MISS, BYPASS and OTHER. The percentages use all HTTP requests as the denominator. BYPASS includes requests where the cache path was considered but disabled/skipped (including globally disabled cache); OTHER covers requests without a cache decision, e.g. early rejected or redirect paths. These are request counts, not bytes; service restarts reset them. Values appear immediately with the first HTTP request; refreshing or pausing the browser does not reset totals. If independently counted cache outcomes exceed the request counter (e.g. while snapshots are inconsistent or a request incurs multiple cache events), the summary shows unavailable rather than fabricating OTHER or a normalized 100% breakdown. The separate recent cache trend chart remains unchanged.


- Live views are process/sampling-based and can show no-data when an integration has not reported yet.
- Per-backend protocol badges can distinguish configured HTTP mode from the protocol actually observed in connection traffic.
- Response-header timing excludes the full streamed body duration. HTTP server/client percentages refer to the specified layer.
- A data sampling gap, a reset after restart and a true zero are not always equivalent.

See [Monitoring](MONITORING.md) for metric details and [Configuration](CONFIGURATION.md) for persistent service settings.