skills/coolify-orchestrator/SKILL.md
Expert Coolify management skill for self-hosted infrastructure. Deploy, manage, provision, and debug services, handle environment variables, and automate workflows with or without MCP.
npx skillsauth add fatih-developer/fth-skills coolify-orchestratorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
A stack-aware, MCP-optional skill that orchestrates your Coolify infrastructure.
Understand which mode you are operating in at the beginning of each session:
MCP_AVAILABLE = Can coolify-mcp MCP tools be called?
Yes → MCP mode: use tools directly (references/api.md is unnecessary)
No → API mode: use Coolify REST API via curl/bash (read references/api.md)
Even in MCP mode, the decision trees and playbooks in this SKILL.md are valid — MCP is just the transport layer.
Find or ask for environment variables:
COOLIFY_BASE_URL — e.g. https://coolify.example.comCOOLIFY_ACCESS_TOKEN — Coolify Settings → API TokensIf these aren't in the env, ask the user. Do not ask for the second time — save it for the duration of the conversation.
Match the user's request with this tree:
Is it about "deploy" or "build"?
+ Turborepo / monorepo / package error → [TURBO-DEPLOY]
+ Normal app deploy → [DEPLOY-VERIFY]
Is it about "down" / "unhealthy" / "error"?
+ Container/file issue (htaccess, config, .env) → [CONTAINER-EXEC]
+ API/service issue → [DEPLOY-VERIFY] (diagnose flow)
Is it about "new" / "provisioning" / "tenant"?
→ [PROVISIONING]
Is it about "env var" / "environment" / "secret"?
→ [MULTI-TENANT-ENV]
Is SSH / container terminal / exec requested?
→ [CONTAINER-EXEC]
Read the relevant reference file for each playbook.
Detail:
references/turborepo-deploy.md
When to trigger: When a Turborepo monorepo is deployed on Coolify and the following errors are seen:
Cannot find module '@myapp/shared'tsconfig.json cannot be foundQuick diagnosis:
COPY order in the Dockerfile — shared packages must be built firstturbo.json?# API mode — fetch build logs
curl -s -H "Authorization: Bearer $COOLIFY_ACCESS_TOKEN" \
"$COOLIFY_BASE_URL/api/v1/applications/{uuid}/logs" | tail -100
In MCP mode: Use application_logs(uuid) → deployment(action: list_for_app) to find the last deploy.
When you identify the problem, read references/turborepo-deploy.md — fix patterns are there.
Detail:
references/deploy-verify.md
Objective: Trigger deploy, verify healthy operation, diagnose if there is an error.
Steps:
1. Trigger deploy
MCP: deploy(uuid, force_rebuild?)
API: POST /api/v1/applications/{uuid}/start
2. Monitor deploy status (max 3 minutes, 10s intervals)
MCP: deployment(action: get, uuid: deploy_uuid)
API: GET /api/v1/deployments/{uuid}
Expected: "finished" — if "failed", fetch logs
3. Application health check
MCP: diagnose_app(uuid or domain)
API: GET /api/v1/applications/{uuid} → status: "running:healthy"?
4. HTTP probe (For Hono/Next.js)
curl -sf https://{domain}/health || curl -sf https://{domain}/api/health
Successful if it returns 200.
5. If failed → analyze logs and find the root cause
Bun/Hono health check endpoint assumption:
GET /health → { status: "ok", uptime: X }
GET /api/health → 200 OK
If this endpoint does not exist, ask the user to add it.
Deploy monitoring loop (bash):
for i in $(seq 1 18); do
STATUS=$(curl -s -H "Authorization: Bearer $COOLIFY_ACCESS_TOKEN" \
"$COOLIFY_BASE_URL/api/v1/deployments/$DEPLOY_UUID" | jq -r '.status')
echo "[$i] $STATUS"
[ "$STATUS" = "finished" ] && break
[ "$STATUS" = "failed" ] && echo "ERROR: Deploy failed" && break
sleep 10
done
Detail:
references/provisioning.md
Objective: Set up all services from scratch for a tenant/project.
Standard order — strictly follow this order:
1. Create project (or find existing project)
2. Create environment (staging / production)
3. Create database and obtain connection credentials
4. Create application (source: Docker image / GitHub repo)
5. Set env vars (including DB_URL)
6. Deploy
7. Run [DEPLOY-VERIFY] loop
Select stack template (ask user if not specified):
| Stack | Template |
|-------|----------|
| Bun + Hono + PostgreSQL | references/provisioning.md#bun-hono-pg |
| Next.js + PostgreSQL + Redis | references/provisioning.md#nextjs-pg-redis |
| PostgreSQL only | references/provisioning.md#db-only |
Pre-provisioning data collection from user:
Detail:
references/multi-tenant-env.md
Objective: Manage env vars securely and isolatedly for multiple apps/tenants.
Basic rules:
Update env var for single application:
# List
curl -s -H "Authorization: Bearer $COOLIFY_ACCESS_TOKEN" \
"$COOLIFY_BASE_URL/api/v1/applications/$APP_UUID/envs"
# Add/update
curl -s -X POST -H "Authorization: Bearer $COOLIFY_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{"key":"DATABASE_URL","value":"...","is_multiline":false}' \
"$COOLIFY_BASE_URL/api/v1/applications/$APP_UUID/envs"
In MCP mode: env_vars(resource: application, action: create|update, uuid, key, value)
Bulk update (multiple applications):
If MCP is present: bulk_env_update(app_uuids: [...], key, value) — write to all apps with a single command.
In API mode: run the references/multi-tenant-env.md#bulk-script script.
Verify: isolation check
List the env vars of each app, ensure that DATABASE_URL values are different.
Detail:
references/container-exec.md
When to use:
.env / config file needs to be edited inside the containerAccess strategy (try in order):
1. Coolify Dashboard → Service → Terminal (web UI) — easiest
2. SSH → server → docker exec — if shell access is available
3. Coolify API exec endpoint (if available) — programmatic
SSH + docker exec:
# Connect to server
ssh user@coolify-server
# Find container name
docker ps | grep <service-name>
# Enter container
docker exec -it <container-name> sh
# or if bash exists:
docker exec -it <container-name> bash
File path assumptions in Coolify:
| Service | File path |
|--------|------------|
| Bun/Node app | /app/ or /usr/src/app/ |
| Next.js | /app/ |
| PostgreSQL data | /var/lib/postgresql/data/ |
After in-container operations are completed, always restart the service:
# API mode
curl -X POST -H "Authorization: Bearer $COOLIFY_ACCESS_TOKEN" \
"$COOLIFY_BASE_URL/api/v1/applications/$APP_UUID/restart"
Token efficiency: First use summary endpoints, if detail is needed go to single source.
Order in case of error:
references/ files for known error patternsSecurity:
DATABASE_URL=postgres://***Coolify API base pattern:
curl -s \
-H "Authorization: Bearer $COOLIFY_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
"$COOLIFY_BASE_URL/api/v1/{endpoint}"
Read the relevant file in the following cases:
| File | When |
|-------|----------|
| references/turborepo-deploy.md | Turborepo/monorepo build issues |
| references/deploy-verify.md | Deploy loop details, Bun/Hono/Next.js health check patterns |
| references/provisioning.md | New service provisioning templates |
| references/multi-tenant-env.md | Bulk env update, isolation verification |
| references/container-exec.md | SSH patterns, file editing, container debug |
| references/api.md | All Coolify REST API endpoints (if MCP unavailable) |
tools
Create, optimize, critique, and programmatically structure prompts for AI systems. Use this skill whenever the user is designing or improving a static prompt, system prompt, coding prompt, agent prompt, workflow prompt, MCP-oriented prompt package, or an algorithmic prompt optimization pipeline. Also use it when the user asks to turn vague AI behavior into a precise instruction set, tool policy, agent spec, evaluation metric, or prompt architecture.
testing
Assumption-first architecture review skill to stress-test project plans and expose hidden risks.
testing
Enforce and manage DESIGN.md specifications, extract design systems from URLs, and combine design reasoning with token roles to prevent drift.
testing
Forces the agent to act with a Claude-like product mindset, prioritizing user journey, UX states, and visual quality before coding.