Monitoring

Container Metrics

The Monitoring tab of every application, database, Compose stack and game server shows four charts:

• CPU Usage — average with a peak envelope. Measured like docker stats, so a container using several cores can go above 100%
• Memory Usage — bytes in use against the container's memory limit
• Disk Usage — the container's writable layer plus its volumes (sampled every 5 minutes, because it is expensive for Docker to compute)
• Network — inbound and outbound traffic as a rate (bytes/s)

Every running container is sampled every 30 seconds and the newest values are pushed to open dashboards over Socket.IO. For a Compose stack, the charts show the total across all of its running containers. If the service has open alerts, a banner above the charts shows them.

Metrics History

Samples are rolled up into PostgreSQL every minute, so the charts keep history across restarts. Pick a range above the charts: 1h, 6h, 24h, 7d or 30d. Ranges up to 24 hours use 1-minute resolution, and longer ranges use 1-hour resolution.

Logs

The Logs tab has two modes:

• Live — streams stdout and stderr from the running container in real time
• History — searches the stored logs by text, level (error, warn, info, debug, fatal) and time range, 100 lines per page

Logs are collected from every running container all the time, whether or not anyone has the tab open. They are kept for 7 days. Set LOG_RETENTION_DAYS to change this. Before a line is stored, DeployKit removes secrets such as tokens with a known prefix (ghp_, sk-, …), Bearer and Basic headers, password= and secret= pairs, AWS keys and long hex strings. Lines longer than 8 KB are cut. The log level is a best guess from the line's text, so don't rely on it for anything critical.

Build Logs

Build and deploy output is streamed to the dashboard during a deployment and stored with each deployment record. The same secret redaction applies to it.

Alerts

The Alerts page in the sidebar shows alert events and the rules that create them. Click New rule to create a rule with these settings:

• Each rule is checked against every 30-second sample. When the threshold is crossed, DeployKit records an event and sends a notification. It doesn't fire again for that rule until the cooldown has passed.
• An event resolves automatically on the first sample that is back inside the threshold. Use "Show resolved" to see past events.
• Every alert appears as a toast in the dashboard, whichever channel you pick. Slack and Webhook also send the alert to that URL. The webhook body has event "alert.fired".
• Viewing alerts requires no special role. Operators can create, edit and disable rules. Only admins can delete them.

Each alert rule has its own channel. Alert rules don't use the project notification channels described in Notifications, which handle deploy and backup events.

Vulnerability Scanning

DeployKit can scan each built image for known CVEs with Trivy. The scan runs after the build and before the container is deployed. Scanning is advisory: a scan that finds problems, fails or times out never blocks the deploy.

• Global default: SCAN_ENABLED=true turns scanning on for every app. If the variable isn't set, scanning is off. The sample .env.example sets it to true.
• Per app: General tab → Security Scanning → "Use server default", "Always scan" or "Never scan".
• Results: a severity badge on each deployment in the Deployments tab, and a full report in the Security tab. The report shows counts for Critical, High, Medium, Low and Unknown, plus each CVE with its package, installed version and fixed version. You can filter by severity and search by CVE, package or title.
• Trivy runs as a temporary aquasec/trivy container. Its vulnerability database is cached in the deploykit-trivy-cache volume, so only the first scan downloads it.

Optional overrides: TRIVY_IMAGE (default aquasec/trivy:latest), TRIVY_CACHE_VOLUME (default deploykit-trivy-cache) and TRIVY_TIMEOUT_SECONDS (default 300).

Interactive Terminal

The Terminal tab opens an interactive shell in your running container from the browser. It uses xterm.js over Socket.IO, so you can debug and troubleshoot without SSH.

Container Status

Each application displays its current status: