A focused dashboard for container monitoring, safe updates, notifications, and Compose-aware operations.
statainer is a lightweight web UI for Docker hosts. It combines live container metrics, Compose project grouping, configurable alerts, update discovery, rollback history, and day-to-day container controls in one interface.
It is designed for self-hosted environments where you want fast operational visibility without giving up practical controls.
- Live CPU, RAM, network I/O, block I/O, uptime, restart count, process count, ports, image, and status visibility.
- Table and chart views for individual containers and top-N comparisons.
- Compose project summaries with grouped container states.
- Optional GPU metrics when NVIDIA tooling is available.
- Start, stop, and restart containers from the UI.
- Open exposed container endpoints directly from the dashboard.
- Inspect container logs without leaving the app.
- Persist filters, visible columns, chart mode, theme, refresh interval, and layout preferences locally.
- Detect update-ready containers and Compose stacks.
- Run Quick Update for individual targets.
- Run
Update selectedorUpdate allfrom the Update Manager. - Show blocked stacks with explicit guidance when original Compose files are missing or externally managed.
- Keep a persistent update and rollback history.
- CPU, RAM, status, and image update alerts.
- Browser-side notification center with pending event history.
- External delivery through Pushover, Slack, Telegram, Discord, ntfy, and generic webhooks.
|
|
|
|
|
|
|
|
- Docker
- Docker Compose plugin
- Access to the Docker socket on the host
git clone https://github.com/Drakonis96/statainer
cd statainer
docker compose up --build -dOnce started, open:
http://localhost:5001
The bundled docker-compose.yml exposes:
- statainer on
5001 - cAdvisor on
8080
It also mounts:
- Docker socket as read-only
- Local app data into
./data
| Variable | Purpose | Default |
|---|---|---|
AUTH_ENABLED |
Enables authentication | true |
AUTH_USER |
Admin username | empty |
AUTH_PASSWORD |
Admin password | empty |
AUTH_PASSWORD_FILE |
Password file alternative | empty |
APP_SECRET_KEY |
Session secret | generated if missing |
APP_SECRET_KEY_FILE |
Secret file alternative | empty |
LOGIN_MODE |
Login flow: popup or page |
popup |
APP_VERSION |
Version shown in the UI footer | v0.9.10 |
DOCKER_SOCKET_URL |
Docker socket URL | unix:///var/run/docker.sock |
CADVISOR_URL |
cAdvisor endpoint | http://cadvisor:8080 |
GPU_METRICS_ENABLED |
Enables GPU collection | true in bundled compose |
- There are no built-in credentials.
- Set
AUTH_USERand eitherAUTH_PASSWORDorAUTH_PASSWORD_FILEbefore exposing the app. - Set
APP_SECRET_KEYorAPP_SECRET_KEY_FILEto keep sessions stable across restarts. - If you want no authentication, set
AUTH_ENABLED=falseexplicitly.
Choose the login experience with:
LOGIN_MODE: "page"Available values:
popuppage
- Filter by container name, status, and Compose project.
- Sort by CPU, RAM, uptime, restarts, image, I/O, update availability, and more.
- Toggle visible columns per user.
- Export current metrics to CSV.
- Line, bar, and pie visualizations.
- Top-N comparison views for CPU, RAM, and uptime.
- Zoom and pan support where applicable.
- Group containers by Compose project.
- Inspect project summaries alongside per-container rows.
- Switch between
ContainersandCompose Stacksviews from the dashboard tabs.
The Update Manager is designed around safety and operator visibility.
Quick Updatefor a single target.Update selectedfor checked stacks or containers.Update allfor all ready targets in a tab.
- Each update-ready stack or standalone container exposes a checkbox.
- You can select a range with
Shiftto batch multiple adjacent targets. - Batch operations run sequentially to avoid overlapping recreations.
- Every successful or failed managed update is recorded in history.
- Eligible successful updates expose rollback actions.
- History is persistent and survives modal reloads.
If a stack was originally created by another tool, statainer may not have the original Compose files available on disk. In that case the app can:
- mark the stack as blocked when it cannot safely manage it
- explain why the Compose files are unavailable
- use a safe external recreate workflow when runtime metadata is sufficient
This is especially relevant for stacks created through tools such as Portainer, Yacht, or similar management layers.
| Provider | Required Variables |
|---|---|
| Pushover | PUSHOVER_TOKEN, PUSHOVER_USER |
| Slack | SLACK_WEBHOOK_URL |
| Telegram | TELEGRAM_BOT_TOKEN, TELEGRAM_CHAT_ID |
| Discord | DISCORD_WEBHOOK_URL |
| ntfy | NTFY_TOPIC |
| Generic webhook | GENERIC_WEBHOOK_URL |
- Set the provider environment variables.
- Restart statainer.
- Open the notification panel as an admin user.
- Enable the event types you want.
- Save the configuration.
- Use
Send testbefore relying on the provider in production.
- CPU threshold exceeded
- RAM threshold exceeded
- Container status changed
- Update available
Pushover
PUSHOVER_TOKEN=your-application-token
PUSHOVER_USER=your-user-keySlack
SLACK_WEBHOOK_URL=https://hooks.slack.com/services/...Telegram
TELEGRAM_BOT_TOKEN=123456:abcde...
TELEGRAM_CHAT_ID=123456789Discord
DISCORD_WEBHOOK_URL=https://discord.com/api/webhooks/...ntfy
Basic public ntfy setup:
NTFY_TOPIC=statainer-home
NTFY_SERVER_URL=https://ntfy.shProtected or self-hosted ntfy examples:
NTFY_TOPIC=statainer-prod
NTFY_SERVER_URL=https://ntfy.example.com
NTFY_TOKEN=tk_your_token_hereNTFY_TOPIC=statainer-prod
NTFY_SERVER_URL=https://ntfy.example.com
NTFY_USERNAME=myuser
NTFY_PASSWORD=mysecret
NTFY_TAGS=docker,monitoring,prod
NTFY_MARKDOWN=falseGeneric webhook
Simple JSON webhook:
GENERIC_WEBHOOK_URL=https://example.com/hooks/statainerPlain-text body example:
GENERIC_WEBHOOK_URL=https://example.com/hooks/statainer
GENERIC_WEBHOOK_METHOD=POST
GENERIC_WEBHOOK_CONTENT_TYPE=text/plain; charset=utf-8
GENERIC_WEBHOOK_BODY_TEMPLATE=[{event_type}] {title}\n{message}Custom headers:
GENERIC_WEBHOOK_URL=https://example.com/hooks/statainer
GENERIC_WEBHOOK_HEADERS={"Authorization":"Bearer super-secret-token","X-Environment":"prod"}Available placeholders:
{app}{host}{title}{message}{priority}{priority_label}{event_type}{container}{container_id}{value}{prev_value}{timestamp}{timestamp_iso}{event_json}
statainer can work with:
- Docker API only
- Docker API plus cAdvisor
The Docker API path is usually enough. cAdvisor is useful if you want broader metric compatibility or a more established metrics source for some host environments.
GPU metrics are available for NVIDIA-enabled hosts.
- NVIDIA drivers on the host
nvidia-smiavailable in the runtime environment- GPU-enabled container access where applicable
environment:
GPU_METRICS_ENABLED: trueIf GPU data is available, statainer surfaces GPU load and memory usage per container in the dashboard.
CPU percentage is calculated per core. On multi-core systems the effective ceiling is:
100% x number of available CPU cores
Exited containers stay visible in the main table so you can:
- inspect their last known state
- review recent resource usage
- restart them directly from the UI
statainer requires access to your Docker environment to inspect containers, operate on them, and evaluate updates. Use it only on systems where you understand the implications of Docker socket access and trust the deployment.
Managed updates are designed to preserve volumes, configuration, environment, networks, and other persistent state whenever possible, but you should still review updates before applying them in production.
This project is licensed under the MIT License. See LICENSE for details.