CannonadeCommand upgrades Unraid's Docker tab into a full container command post: dependency-aware, health-gated start orchestration, live CPU/RAM/bandwidth limits with built-in proof diagnostics, one-click actions, and clean, themeable badges — all injected right into the native page. A small Go engine does the work; nothing leaves your server.

Table of Contents

1. What is this?
2. Features
3. Installation
4. The Docker tab
5. The settings page
6. How it works
7. Safety notes
8. Uninstall
9. Development
10. License
11. Support this project

1. What is this?

CannonadeCommand gives Unraid's native Docker, Plugins and VM tabs both muscle and a makeover — without replacing a single page. Everything is enhanced in place.

On the Docker tab it replaces start-order guesswork with a start plan: containers declare what they depend on, and the engine starts them in dependency order, releasing the next stage only when a container is actually ready (not merely "running"). It adds per-container CPU, RAM and bandwidth limits, a compact actions column, and a badge-based UI that shows live state at a glance. The Plugins tab gets the same styling — uniform logos and badges for author, version, status and changelog — and the VM tab picks up matching icon theming.

Accent or rainbow colours, a configurable badge shape and a floating action bar tie it all together — and CannonadeCommand can extend the same theme to Unraid's main menu bar (opt-in) and turn the Settings page category icons into large square badges. A Bereiche (Areas) tab in the settings lets you turn each area — menu bar, Docker, Plugins, VMs, Settings — on or off independently, each with its own style tab.

Firepower and finish for your whole Unraid dashboard. Fire when ready.

2. Features

Orchestration

• Start plan with dependencies ("start the app after its database"), computed into parallel start stages.
• Readiness probes per container: running (with grace), TCP port, HTTP check, log-line match, or a command inside the container.
• Failure policies per node: abort dependents, continue, or degrade.
• Dependencies on containers outside the plan just work — the engine resolves them implicitly, nothing is written into your plan.
• Watchdog (auto-restart on crash or unhealthy, rate-capped per hour) and time schedules (start/stop/restart at fixed times, per weekday).
• Idle auto-stop (ContainerNursery-style): stop a container after it stays idle — low CPU and low network — for a set number of minutes. A busy container is never stopped, and a host/container-network container (whose per-container idle can't be measured) is skipped. CC does not wake it back up — a schedule, the plan, or Unraid's autostart does.

Resource limits

• Live CPU limit, CPU pinning (topology-aware, with P/E-core detection on Intel hybrid CPUs) and RAM limit via Docker update — no container restart.
• Upload limit (tbf shaper) and download limit (pure netfilter policing — never a tc ingress qdisc) per container, applied inside the container's own network namespace. Works for bridge, ipvlan and macvlan networks alike.
• Built-in proof: the bandwidth editor reads the LIVE rule from the container and shows either the applied state or the exact failure — a silent no-op is impossible.

UI

• Actions column: WebUI, log, edit, restart, pause, stop/start and a "…" menu with the container's project/support/donate links — harvested from Unraid's own page data.
• Clean badges for state, network, IPs (click to copy), ports, volumes, update status; live CPU/RAM/bandwidth values with their limit editors attached.
• List view and a card (grid) view with the same controls.
• Theming: one accent colour for everything, or rainbow mode with an editable palette; icon colours toggleable; settings sync across origins (IP, hostname, domain) via the engine — and they survive cleared browser data.
• Master theming switch: one toggle turns all visual theming off and keeps only the orchestration functions (start plan, limits, bandwidth, watchdog, schedules, idle-stop), leaving a native-looking Docker tab.
• Areas: the Docker, Plugins, VM and Favorites tabs, plus (opt-in) the main menu bar, the Start (Main) tab and the Settings-page category icons (large square badges) — each toggleable under Bereiche (Areas) with its own style tab. The VM tab is styled to match the Docker tab exactly (logo badge, state/CPU/RAM/IP badges, autostart switch); the Favorites tab reuses the category-icon badges.
• Tab view: on every tab with sub-tabs (Shares detail, Start/Main, Plugins, VMs) choose per tab whether the sub-tabs render as stacked CC sections or as native Unraid sub-tabs (native by default).
• VM tab: full Docker-tab parity — logo badge, state/CPU/RAM/IP badges, an actions column, the accent autostart switch, a list/grid (card) view and rainbow mode.
• Logo background (per area, in the View card): put the container / plugin / VM / category logo on a coloured accent badge and recolour it monochrome black or white for contrast, or leave it natural.

3. Installation

Unraid → Plugins → Install Plugin → paste:

https://raw.githubusercontent.com/junkerderprovinz/cannonadecommand/main/plugin/cannonadecommand.plg

The plugin installs the UI pages and starts the engine (a single Go daemon listening on a local unix socket). Updates install the same way; the daemon is restarted automatically.

4. The Docker tab

• Every row gets its badges, the actions column, and the resource lines (CPU / RAM / BW) with a gear each. The gear is filled in your accent colour when a limit is set.
• The plan badge opens the per-container editor: manage-in-plan toggle, dependencies, readiness probe, start delay, failure policy, watchdog and schedules — one save button stores it all.
• The bandwidth gear opens the up/down limit editor. After saving, the popup stays open and verifies the applied rule live inside the container.
• The gear in the table header opens the global menu: list/grid view, basic/advanced view, rainbow and icon-colour toggles, filter, badge selection, and the running UI + engine versions.

5. The settings page

Settings → Utilities → CannonadeCommand holds the appearance settings (accent colour with an embedded picker, rainbow palette, density, column defaults), the bandwidth interface (blank = auto-detected from the container's default route), notifications, and the diagnostics card with the engine's recent limit operations. Settings are mirrored into the engine config, so every browser and origin sees the same configuration.

6. How it works

Piece	What it does
cannonadecommand daemon (Go)	Talks to the Docker socket (list/start/stop/update only), computes start stages, runs probes, applies limits, persists plan + config on the flash
Unix socket + PHP proxy	The UI talks to /api/* through a same-origin proxy with a strict path allowlist; writes carry Unraid's csrf token
Page scripts	Enhance the native Docker tab in place (badges, actions, editors); a settings page under Utilities

The daemon exposes proof endpoints (/api/limitlog, /api/bwstatus) so the UI can always show what REALLY happened — values read back from Docker, live tc and netfilter state from the container's netns, and the monitor's last apply attempt.

7. Safety notes

• No tc ingress qdisc, ever. Download limiting is pure netfilter policing on the container's INPUT chain; the sch_ingress module (which can freeze some Unraid kernels) is never touched — a unit test enforces that the download path cannot even emit a tc command.
• Quirk compensation is built in and CI-proven: legacy iptables (≥ 1.8.12) applies byte rates as bits — detected and compensated ×8; hashlimit minimum burst honoured; every build measures real throughput through the rule in a live container netns.
• Shaping is skipped for host-network / shared-netns containers (it would shape the host or another container).
• The proxy never passes raw Docker create/exec/build; only read + lifecycle verbs are exposed.

8. Uninstall

Plugins → Remove. The daemon is stopped by PID and all program files are removed. The start plan and config on the flash are kept, so a reinstall picks up where you left off; delete /boot/config/plugins/cannonadecommand/ if you want a truly clean slate.

9. Development

go build ./...          # engine
go test ./internal/...  # unit tests (incl. the qdisc-free download guard)
bash plugin/pkg_build.sh <version>   # build the .txz package (Linux/CI)

CI builds the package, lints, and runs three hardware-truth proofs on every push: real docker update limit assertions against dockerd, the netfilter policing rule applied and verified inside a live container netns, and a real throughput measurement through the rule.

10. License

MIT — do what you like, no warranty.

11. Support this project