From truenas-mcp
Deploy a Docker Compose stack to TrueNAS Scale and verify it came up healthy. Use after the deployment architecture is settled — wraps validate → deploy → poll job → verify, and on failure pulls logs and reports. For the assessment and architecture decisions that must happen first, use truenas-deployment-planning.
How this skill is triggered — by the user, by Claude, or both
Slash command
/truenas-mcp:truenas-deploy-and-verifyThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill executes a safe deploy pipeline that catches failures early.
This skill executes a safe deploy pipeline that catches failures early. It never just "fires and forgets" — the deploy is always followed by a verification step.
This skill is the hands, not the head. It assumes the deployment
architecture is already settled: which pool, which network model, what
gets exposed. If that has not happened yet, run
truenas-deployment-planning first — deploying without it means
inheriting whatever default the tooling guessed.
Use this skill once the architecture is settled and the user wants to ship a concrete compose:
If the user only asks to validate a compose file (without deploying),
call validate_compose directly instead.
[a-z0-9-], no
leading/trailing dash). It is the TrueNAS app name and the basis for
the host directory under the chosen pool. If it is missing, ask once —
do not guess it from the compose services: block.networks:
and ports: must already reflect the architecture settled during
planning.Follow these steps in order. Do not skip ahead, do not parallelize.
Call validate_compose(compose_yaml).
valid == false: stop. Show the user the errors array. Ask
whether to fix automatically or have them edit.warnings is non-empty: show them but continue.security_issues is non-empty: stop. These are blocked
(privileged, dangerous capabilities, system-path mounts). Explain
why and ask whether to remove them.Call deploy_app(app_name, compose_yaml).
The tool internally: converts the compose → checks port conflicts →
calls app.create → polls the job until SUCCESS or FAILED.
success == true: continue to Step 3.success == false: skip to Step 4 (failure handling) — do not
retry blindly.Call verify_deployment(app_name).
app_running == true and health_status == "healthy": success.
Report to the user with app name, status, ports, and — if the compose
carries a reverse-proxy label — the public URL it routes to.app_running == true but health_status != "healthy": ambiguous.
The container started but health checks are not passing. Continue to
Step 4 to pull logs.app_running == false: continue to Step 4.The deployment is in a bad state. Gather context before asking the user what to do:
get_app_details(app_name) — note the status and config.get_app_logs(app_name, lines=200) — read the tail./mnt/ pathFor each category, the recommended action is:
list_apps to find the colliding app; pick a
different host port.If the user wants to abandon the deployment, suggest purge_app(app_name)
(handled by the truenas-purge-failed skill), which removes the app and
its volumes from TrueNAS. Host directories under /mnt/ are kept — the
user decides manually whether to delete them.
When the deployment succeeds:
✓ Deployed <app-name>
Status: RUNNING
Pool: <pool from deploy result>
Ports: <list>
URL: <public URL> (only if a reverse-proxy label is present)
Job ID: <job_id>
When it fails:
✗ Deployment of <app-name> failed
Category: <category>
Symptoms: <one-line summary>
Logs:
<relevant excerpt>
Recommended: <specific next action>
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub svnstfns/claude-marketplace --plugin truenas-mcp