wagmios
Provides an API interface for agents to manage Docker containers and homelab applications securely, bypassing direct root/sudo needs.
Install
mkdir -p .claude/skills/wagmios && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/15398" && unzip -o skill.zip -d .claude/skills/wagmios && rm skill.zipInstalls to .claude/skills/wagmios
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Give your OpenClaw agent a homelab. Use when managing Docker containers, installing marketplace apps, or any Docker-related tasks on behalf of the user. Scope-based API key permissions — agent can only do what the key allows. On Linux, Docker requires sudo — without root access, WAGMIOS is the only safe interface for agent homelab control. Supports multi-machine management — one agent can manage multiple WAGMIOS instances across different hosts, each with its own scoped key. Requires X-API-Key header on every request (user provides at runtime). Includes Docker installation check and startup validation.Key capabilities
- →Confirm Docker availability on the host
- →Check WAGMIOS backend reachability
- →Verify API key scopes via `GET /api/auth/status`
- →List Docker containers and inspect their details
- →Create, start, stop, and restart Docker containers
- →Install marketplace applications
How it works
WAGMIOS acts as an API-only interface for Docker management, enforcing scope-based permissions for all container operations.
Inputs & outputs
When to use wagmios
- →Manage Docker containers
- →Install homelab marketplace apps
- →Validate Docker installation
- →Control infrastructure via API
About this skill
WAGMIOS
Scope = Permission. API Only. No Workarounds.
Core Principle
The WAGMIOS API is the primary interface for container management. On Linux, Docker requires sudo — without root access, WAGMIOS is the only interface agents can use for homelab control. Do not:
- Execute
dockerCLI commands directly - Access the Docker socket or daemon
- Manipulate API keys or scopes
- Bypass scope restrictions through any means
If a scope is missing, the agent cannot do the task — ask the user to enable it.
Startup Check (First Interaction)
Before attempting any WAGMIOS operation:
- Confirm Docker is available — WAGMIOS manages Docker containers, so Docker must be running on the host
- Confirm backend is reachable — the backend port (default 5179) must be accessible
- Check key scopes — call
GET /api/auth/statusto know what the key can do
If Docker is not installed or running:
→ See references/docker-install.md for installation instructions by OS.
If WAGMIOS backend is not reachable: → Ask the user to confirm the backend is running at the provided URL.
Authentication
Every request requires the X-API-Key header. The user provides the key and base URL at runtime — do not store it.
Base URL: http://localhost:5179 (user provides, may differ for remote hosts)
Header: X-API-Key: <key>
Check key scopes first via GET /api/auth/status — this tells you what the key can do.
Credential handling:
- Keys are provided by the user at runtime, not stored by the agent
- The API key is scoped — it only allows what the user explicitly granted
- Do not log or expose the full key value
Scope Map
| Scope | Permitted Actions |
|---|---|
containers:read | List containers, inspect, view logs |
containers:write | Create, start, stop, restart containers |
containers:delete | Remove containers (with user confirmation) |
images:read | List Docker images |
images:write | Pull and delete images |
templates:read | Use saved container templates |
templates:write | Create and edit templates |
marketplace:read | Browse the app marketplace |
marketplace:write | Install, start, stop marketplace apps |
Standard Workflow
- Verify scope — check
GET /api/auth/statusbefore attempting any action - Confirm — for destructive actions (delete), always confirm with user before executing
- Execute — call the appropriate API endpoint
- Report — return the result clearly
Decision Tree
User asks to do X
│
├── Missing scope for X?
│ YES → Tell user, ask them to enable it in Settings
│ NO → Continue
│
├── X is destructive (delete, stop)?
│ YES → Confirm with user before executing
│ NO → Execute immediately
│
└── Execute via API, report result
Multi-Machine Management
WAGMIOS supports managing multiple hosts from a single agent. Each machine runs its own WAGMIOS instance with its own URL and its own scoped API key.
How it works:
- User installs WAGMIOS on each machine they want to manage
- User creates a separate API key per machine, with only the scopes that machine needs
- User provides the agent with the URL and key for each machine
- Agent routes requests to the correct machine based on the user's request
Example:
User: "Install Jellyfin on the media server and make sure Nginx is running on the NAS."
Agent → POST media-server:5179/api/marketplace/create { "app_id": "jellyfin" }
Agent → GET nas:5179/api/containers
Agent → POST nas:5179/api/containers/nginx/start
"Jellyfin is installing on the media server (port 8096). Nginx is running on the NAS."
Key principle: Each instance is independent. The agent cannot move containers between machines, cannot escalate permissions beyond what a key allows, and each action is logged in the instance's own activity feed.
Safeguards
→ See references/safeguards.md
Docker Installation
→ See references/docker-install.md
API Reference
→ See references/api.md
Marketplace
→ See references/marketplace.md
Workflows
→ See references/workflows.md
Scope Reference
→ See references/scopes.md
When not to use it
- →When executing `docker` CLI commands directly
- →When attempting to access the Docker socket or daemon
- →When trying to bypass scope restrictions
Prerequisites
Limitations
- →Requires an `X-API-Key` header on every request
- →Agent cannot perform tasks if a scope is missing
- →Does not allow direct `docker` CLI commands or Docker socket access
How it compares
This skill provides a secure, API-driven interface for Docker management with granular permissions, unlike direct Docker CLI access which often requires root privileges.
Compared to similar skills
wagmios side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| wagmios (this skill) | 0 | 4mo | No flags | Intermediate |
| deployment-engineer | 4 | 4mo | No flags | Advanced |
| devops | 2 | 7mo | Review | Intermediate |
| k8s-kind | 1 | 6mo | Review | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
deployment-engineer
sickn33
Expert deployment engineer specializing in modern CI/CD pipelines, GitOps workflows, and advanced deployment automation. Masters GitHub Actions, ArgoCD/Flux, progressive delivery, container security, and platform engineering. Handles zero-downtime deployments, security scanning, and developer experience optimization. Use PROACTIVELY for CI/CD design, GitOps implementation, or deployment automation.
devops
mrgoonie
Deploy to Cloudflare (Workers, R2, D1), Docker, GCP (Cloud Run, GKE), Kubernetes (kubectl, Helm). Use for serverless, containers, CI/CD, GitOps, security audit.
k8s-kind
rohitg00
Manage kind (Kubernetes IN Docker) local clusters. Use when creating, testing, or developing with local Kubernetes clusters in Docker containers.
devops-engineer
Jeffallan
Use when setting up CI/CD pipelines, containerizing applications, or managing infrastructure as code. Invoke for pipelines, Docker, Kubernetes, cloud platforms, GitOps.
eks
itsmostafa
AWS EKS Kubernetes management for clusters, node groups, and workloads. Use when creating clusters, configuring IRSA, managing node groups, deploying applications, or integrating with AWS services.
kubernetes
OpenHands
Set up and manage local Kubernetes clusters using KIND (Kubernetes IN Docker). Use when testing Kubernetes applications locally or developing cloud-native workloads.