wagmios
- Repo stars 55
- License Apache-2.0
- Author updated Live
- Author repo wagmios
- Domain
- DevOps
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 94 / 100 · audit passed
- Author / version / license
- @mentholmike · Apache-2.0
- Token usage
- Lean
- Setup complexity
- Manual integration
- External API key
- Required · Vendor-specific
- Operating systems
- Linux · Docker
- Runtime requirements
- Docker
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: wagmios
description: Give your OpenClaw agent a homelab. Use when managing Docker containers, installing marketplace…
category: devops
runtime: Docker
---
# wagmios output preview
## PART A: Task fit
- Use case: 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..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Core Principle / Startup Check (First Interaction) / Authentication” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “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.”.
- **02** When the source has headings, the agent prioritizes “Core Principle / Startup Check (First Interaction) / Authentication” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; may access external network resources; requires Vendor-specific API keys.
## Running Rules
- read files, write/modify files, run shell commands; may access external network resources; requires Vendor-specific API keys.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/api`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Start with a small task and check whether the result follows “Core Principle / Startup Check (First Interaction) / Authentication”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: wagmios
description: Give your OpenClaw agent a homelab. Use when managing Docker containers, installing marketplace…
category: devops
source: mentholmike/wagmios
---
# wagmios
## When to use
- Give your OpenClaw agent a homelab. Use when managing Docker containers, installing marketplace apps, or any Docker-re…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Core Principle / Startup Check (First Interaction) / Authentication” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; may access external network resources; requires Vendor-specific API keys.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "wagmios" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Core Principle / Startup Check (First Interaction) / Authentication
rules -> SKILL.md triggers / order / output contract
runtime -> Docker | read files, write/modify files, run shell commands | may access external network resources
guardrails -> requires Vendor-specific API keys + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} 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
Decide Fit First
Design Intent
How To Use It
Boundaries And Review