Superpowers Infrastructure Ops Theme: Docker, Servers, and Networks

Infrastructure Is Where Process Stops Being Optional

A coding agent with no process writes bad code, you review the diff, and life goes on. An agent with no process on a production server restarts the wrong container, deletes the wrong volume, or “helpfully” prunes an image tag you needed — and the review is an outage post-mortem. That asymmetry is the entire reason this article exists. The superpowers infrastructure ops theme is about what happens when you take a methodology built for software engineering — brainstorm, plan, dispatch, execute, verify — and point it at Docker containers, servers, and network topology instead of source files.

The thesis is simple: the workflow pattern does not care what its raw material is. Code, containers, compose files, and network bridges are all just state that an agent is about to change. What changes in the infrastructure domain is the cost of skipping the pattern — and the payoff of getting it right, which we’ll measure against a real job: a full audit of a 32-container Docker stack across 26 networks, completed in a single sitting.

The Theme: One Workflow, Zero Source Code

The using-superpowers bootstrap skill establishes the rule that makes everything else work: if there is even a 1% chance a skill applies, you invoke it before you act. On a codebase that rule routes agents toward debugging methodology. On infrastructure it does something arguably more valuable — it stops the reflex. Ask a capable agent to “look into Docker on this box” and the undisciplined move is to immediately fire docker ps, eyeball the output, and start typing cleanup commands. Each individual command may be harmless; the sequence is not, because nothing in that loop ever established scope, constraints, or a definition of done.

The infrastructure ops theme re-runs the same control flow with infrastructure-shaped payloads:

Brainstorming replaces “what should this feature do?” with “what is this host for, what is the blast radius, and what counts as a successful audit?” — and crucially, whether this run is read-only.
Writing plans replaces implementation steps with provisioning steps, deploy steps, or audit lanes — each with its own verification command.
Dispatching parallel agents replaces independent modules with independent subsystems: storage, networking, and health can be surveyed concurrently because they share nothing but read access.
Verification before completion replaces the test suite with docker ps, service status, and config read-backs — fresh output, this turn, before any claim.

What you get is the rare kind of operational discipline that survives contact with a real machine: structured where ad-hoc shell sessions are improvised, verifiable where they rely on memory, and parallel where they are strictly sequential.

Case Study: SYNAS — 32 Containers, 26 Networks

SYNAS is our always-on home server: OpenMediaVault on Debian, 62.82 GiB of RAM, 456 GB of disk, reachable at 10.10.10.12 over a bonded interface and fenced behind an nftables drop-only ruleset. It runs 32 Docker containers spread across 26 networks: a monitoring stack (checkmk, Portainer, the ten-container Tactical RMM estate), three game servers (DayZ, Ark: Survival Evolved, 7 Days to Die), an AI corner (open-webui, rea-mcp, typesense, icarus), automation (n8n behind cloudflared), a web/portal cluster (nocodb, browserless, playwright-mcp, open-terminal), and storage/media services (vaultwarden, Plex). The brief was deliberately small: audit the Docker environment and tell me if it’s healthy.

The audit produced a real deliverable — a status report with a container-health table, a categorized service inventory with per-container CPU and memory, a resource analysis, a network topology map, and a recommendation list. The headline results: 32 of 32 containers healthy, zero restarts in 48 hours, 41 GiB of 62.82 GiB memory used with only 2.7 GiB of a 32 GiB swap touched, disk at 31%. And under “nice-to-have,” a pile of small findings an unstructured glance would have missed: four orphaned networks left over from compose renames, a 79 MB orphaned volume (pg_memory_data), roughly 1.9 GB of dangling images, 24 entirely inactive build-cache entries, and one container (icarus) writing 1.87 GB into its writable layer with no volume mount.

None of that required genius. It required coverage, and coverage is what a plan plus parallel lanes buys you.

Related Deep Dives in the Series

The superpowers-infra skill ships a mapping from the general library to operations work. The four load-bearing entries deserve a closer look.

Skill	Infrastructure role
brainstorming	Architecture decisions: container vs. bare metal, network topology, read-only vs. mutating scope, blast-radius agreements.
writing-plans	Multi-step deployments and server provisioning: every step written with its verification command defined before execution.
dispatching-parallel-agents	Concurrent audit lanes over independent subsystems — storage, networking, health — each briefed with only its own scope.
verification-before-completion	Health checks as evidence: a fresh `docker ps`, a status read-back, a config diff — run this turn, read in full, cited in the claim.
systematic-debugging	Root-cause analysis before touching anything that looks “wrong” in `docker stats`.
requesting-code-review	Reviewing Dockerfiles, compose files, nginx configs, and systemd units with the same gates as application code.

Brainstorming: deciding before the engine is running

Infrastructure is unusual in that the design conversation has the highest leverage of the whole chain, because the artifact is already built and serving traffic. The SYNAS audit began with three questions the skill’s dialogue forced before any command ran: Is this survey read-only? (Yes — nothing here restarts, prunes, or rewrites.) What is the deliverable? (A status report, not a cleanup.) What’s the blast radius of being wrong? (Everything — this box runs our password manager.) That last answer set the bar for evidence quality for the entire run. Architecture decisions get the same treatment: whether a service belongs on its own bridge network, whether a host-driver container is justified, whether a dual-homed container is a feature or a leak.

Writing-plans: deployments as checkbox arithmetic

A deployment plan written under writing-plans discipline is not a narrative; it’s a checklist where every step carries its proof. “Recreate vaultwarden on vaultwarden_net only” is a wish. “Recreate vaultwarden; verify: docker inspect -f '{{range $k,$v := .NetworkSettings.Networks}}{{$k}} {{end}}' vaultwarden returns exactly one network” is a step. The same discipline applied to the audit itself: the plan declared the three lanes and what each had to return before the first SSH command executed, which is why the final report has sections matching the plan one-for-one.

Dispatching: three lanes, no shared state

The audit decomposed cleanly into three domains that share nothing but read-only access to one host: a storage lane (docker system df -v: images, volumes, writable layers, build cache), a network lane (docker network ls plus per-network inspect: attachments, drivers, orphans), and a health lane (docker ps -a, docker stats --no-stream, and a 48-hour event sweep). The two heaviest lanes went out as one parallel delegate_task batch while the orchestrator ran the health sweep itself. Each subagent’s brief was self-contained — the SSH host alias, user, key path, the exact commands, the output format, and an explicit constraint: read-only, report numbers, change nothing. That last clause is the infrastructure-specific hardening the general dispatching skill doesn’t assume you need. Here you always need it.

Verification: the last command of the audit

The report’s headline claim — “all 32 containers healthy” — was not assembled from the lanes’ summaries. The verification-before-completion gate ran one final time, end to end: identify the command that proves the claim (docker ps -a | grep -ci 'up'), run it fresh against the live host, read the single line of output — 32 — and only then let the number into the summary. The discipline also polices the claims in the other direction: it’s what forces “4 orphaned networks” to mean four networks with zero attached containers, enumerated by name, not “there seemed to be some dead ones.”

superpowers-infra: A Meta-Skill for the Domain

The pattern’s endgame is superpowers-infra itself — a custom skill that packages this theme into a reusable meta-skill. It carries three things the general library can’t know about your box:

The workflow sequence for ops: bootstrap with using-superpowers, plan with writing-plans, fan out with dispatching-parallel-agents, execute, then close with a fresh verification-before-completion check. Always in that order; the order is the safety model.
A command vocabulary: the exact Docker invocations that produce machine-checkable output — docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}', docker stats --no-stream, docker system df -v, docker events --since 48h, docker network inspect — plus the SSH context for reaching the host non-interactively.
A finding taxonomy with thresholds: orphaned volumes and networks, writable-layer bloat, host-driver containers that bypass isolation, and when a scary number is actually fine. This is where the domain expertise hides.

The thresholds earned their place the hard way. The raw docker stats output from the SYNAS audit had two numbers that would trigger a confident wrong fix in any untrained pair of hands: dayz at 110.88% CPU and icarus at 4.3 GB of RAM. The taxonomy says: a hyperthreaded game-server process reporting over 100% is arithmetic, not pathology — watch sustained usage, not instantaneous spikes. And 4.3 GB only matters next to the system total (21 GiB available) and the container’s own history — icarus’s real smell wasn’t the RAM figure, it was the 1.87 GB accumulating in its writable layer, which points at a missing volume mount, not a memory leak. Guessing would have “fixed” the wrong thing and restarted the DayZ server for nothing.

Sidebar: How an AI agent can audit your entire Docker stack in minutes

You don’t need a monitoring vendor to do this. The sequence that audited 32 containers and 26 networks on SYNAS:

One access path. Give the agent a single SSH alias for the host — and state the constraint up front: “read-only; report, don’t change.”
Three questions before any command. What’s the scope, what’s the deliverable, what’s the blast radius? Thirty seconds of answers, hours of avoided thrash.
Parallel lanes. Health (docker ps -a, restart counts, 48h events), storage (docker system df -v), and networking (docker network ls + inspect) run at the same time because they read different things.
One verification at the end. A fresh count command whose output must match the report’s headline number — printed in the report itself so you can re-run it.

The whole point: what used to be an afternoon of scattered terminal tabs becomes a plan you can read before it runs and an evidence pack you can check after it finishes. Minutes, because the lanes ran concurrently — and trustworthy, because the last thing the agent did before saying “healthy” was prove it.

Inside the Parallel Audit

The concurrency model matters, because this is where “structured” converts into wall-clock time. The Hermes dispatching runtime caps concurrent subagents at three, so a three-lane decomposition is the practical maximum for one fan-out — and it’s exactly right for a Docker audit, where the lanes are naturally independent. The health lane stayed with the orchestrator on purpose: its findings (restart storms, unhealthy states) would have changed how the storage and network findings should be read, so keeping it local kept the correlation in the one place that has full context.

What came back was mergeable by construction, because the briefs didn’t overlap. The storage lane returned the per-type breakdown — 30 images using 27.52 GB with nothing reclaimable at the image level, 12 volumes with one orphan, 24 build-cache entries with not a single active one — and the network lane returned the topology: per-service bridge networks, Portainer on the host driver, Tactical RMM spread across a proxy/API/mesh/redis/db web, and vaultwarden sitting on two bridge networks, flagged as “verify intent” rather than “fix.” Every line carried its command output, so the orchestrator’s integration step was reconciliation, not re-investigation.

The reconciliation pass is where judgment shows up, and it’s worth quoting two rulings from the report because they show verification doing something no command can do alone:

Scary-looking finding	Ruling after verification
`dayz` at 110.88% CPU	Expected. A DayZ headless server on a hyperthreaded core legitimately reports >100%. Watch sustained trend, not the snapshot.
`vaultwarden` on two bridge networks	Likely intentional — one network for LAN, one for the reverse-proxy path. Flagged for owner confirmation instead of silently “cleaned up.”
24 build-cache entries, 531 MB	All inactive. Safe prune, worth ~532 MB. Recommendation, not action — the run was read-only by contract.
4 orphaned networks + 79 MB orphaned volume	Renamed compose stacks leaving corpses behind. Enumerated by name so a future mutating run can prune them as a checklist.

Notice what did not happen: nothing restarted, nothing pruned, nothing “optimized.” The design gate at the top of the chain had marked the run read-only, so every finding landed as a recommendation with receipts. On a box running your password manager, the best outcome of an audit is a diff you approve later — and only a process that separates “observe” from “act” can promise that in advance.

Adapting the Theme to Your Own Stack

If you want to run this pattern somewhere else, the port is cheap. The superpowers-infra skill is a template more than a rulebook: swap the SSH host facts and the box-specific thresholds, keep the workflow order, the command vocabulary, and the iron law that a status claim without a this-turn verification command is not a finding — it’s a vibe. Then let the meta-skill do what meta-skills do: on the next audit, the agent doesn’t rediscover that game servers spike or that orphaned networks hide in docker network ls. It loads the domain pack, plans the lanes, dispatches, verifies, and reports — in minutes, with evidence, and leaving the blast radius exactly where it found it.

Where This Fits in the Series

This is the fifth and final theme article in the Superpowers deep-dive series. The Planning & Execution theme covers the brainstorm-to-plan-to-execute spine; Parallelism goes deeper on dispatching independent work; Verification & Quality unpacks the evidence-before-assertions principle; and Systematic Debugging handles the root-cause discipline that keeps a scary number from becoming a wrong fix. Infrastructure ops is where all four themes run on live machines at once — which makes it the best place to see why the process was worth it in the first place. If you’re new to the underlying library, start at the top with using-superpowers, the bootstrap that routes every one of these runs.