name: xcloud-docker-deploy description: "xCloud Docker Deploy v1.4.1 — a confirmation-gated skill for preparing projects for xCloud. It inspects or changes files only after user consent, generates Docker/GHCR deployment files, fixes xCloud port rules, and routes live API work only after a separate explicit token-consent step." license: Apache-2.0 version: "1.4.1" author: "M Asif Rahman" homepage: "https://github.com/Asif2BD/xCloud-Docker-Deploy-Skill" source: "https://github.com/Asif2BD/xCloud-Docker-Deploy-Skill" repository: "https://github.com/Asif2BD/xCloud-Docker-Deploy-Skill" metadata: { "openclaw": { "emoji": "🐳", "requires": { "bins": ["git", "docker"] }, "install": [ { "id": "github", "kind": "link", "label": "GitHub", "url": "https://github.com/Asif2BD/xCloud-Docker-Deploy-Skill", }, { "id": "release", "kind": "link", "label": "Latest Release", "url": "https://github.com/Asif2BD/xCloud-Docker-Deploy-Skill/releases/tag/v1.4.1", }, { "id": "xcloud-agent-skills", "kind": "link", "label": "xCloud Agent Skills", "url": "https://app.xcloud.host/agent/skills", }, { "id": "xcloud-api", "kind": "link", "label": "xCloud API Docs", "url": "https://app.xcloud.host/api/v1/docs", }, { "id": "security", "kind": "link", "label": "Security Notes", "url": "https://github.com/Asif2BD/xCloud-Docker-Deploy-Skill/blob/main/SECURITY.md", }, ], }, } tags: - docker - deployment - devops - xcloud - docker-compose - github-actions - wordpress - laravel - nextjs - nodejs - python - ci-cd - hosting - infrastructure category: "DevOps & Deployment" platforms: - claude-code - openClaw - claude-ai - cursor - windsurf - codex - any security: verified: true package_no_runtime_network_calls: true no_executables: true templates_only: true requires_explicit_user_confirmation: true live_api_requires_separate_consent: true
Built for xCloud Custom Docker deployments by Asif2BD · GitHub · Latest Release · xCloud Agent Skills
This is a deployment-preparation skill. Before it inspects a project, edits files, recommends production changes, asks for API tokens, or routes to live xCloud API skills, the agent must confirm the exact action with the user.
Use this safe opening:
I can do read-only analysis first, or I can generate deployment files after your confirmation. I will not push, deploy, collect tokens, or call live xCloud APIs unless you explicitly approve that exact step.
Use normal human language. Ask:
This is my project. I want to deploy it on xCloud. Please inspect it, decide whether it should use xCloud native deployment or Docker, generate the proper Dockerfile, Docker image workflow, docker-compose.yml,
.env.example, and give me the exact xCloud deployment steps.
If you already have a compose file, ask:
Please make this
docker-compose.ymlwork on xCloud. Fix anything xCloud does not support, especially Docker build steps, proxy services, and host ports 80/443.
The agent should then: 1. Ask whether to perform read-only analysis or generate files. 2. Detect the stack after the user confirms project inspection. 3. Choose native xCloud deployment or Custom Docker. 4. Generate or fix Docker files only after explicit confirmation. 5. Explain the exact xCloud UI/API steps in simple language. 6. Before any production-impacting step, recommend a branch, backup, and staging/test deployment.
xCloud port-safety notice: final compose output must never bind host port
80or443. If an app listens on container port80, use3080:80and set xCloud's exposed/primary port to3080.
Adapt any docker-compose.yml to work with xCloud — a git-push Docker deployment platform.
git push → xCloud runs: docker-compose pull && docker-compose up -d
xCloud never runs docker build. Images must be pre-built in a public registry. SSL, reverse proxy, and domain routing are handled by xCloud — your stack must not duplicate them.
Read references/xcloud-constraints.md for the full ruleset before making changes.
xCloud now publishes API-backed agent skills for operational work:
| Official skill | Owns |
|---|---|
xcloud:servers |
Servers, PHP, databases, cron, firewall/fail2ban, sudo users, WordPress provisioning |
xcloud:sites |
Site lifecycle, status, backups, domains, cache, SSH, site cron, git |
xcloud:wordpress |
WordPress plugins, themes, updates, debug, magic login, vulnerabilities, PageSpeed |
xcloud:ssl |
SSL certificates: view, install, renew, status, delete |
xcloud:account |
Current user, API tokens, Cloudflare integrations, blueprints, health |
Use this skill for project detection, Dockerfile/compose generation, GHCR CI, and xCloud Custom Docker readiness. Use the official API skills when the user asks to inspect or mutate live xCloud resources.
This Docker deploy skill can work alongside the official xCloud API skills when those skills/tools are available. If a task needs live xCloud data or live actions:
XCLOUD_API_TOKEN.xcloud:servers for server capacity, PHP, databases, cron, firewall, sudo users, WordPress provisioningxcloud:sites for site status, domains, backups, cache, SSH, git, deployment logsxcloud:wordpress for WordPress plugins, themes, updates, debug, magic login, vulnerabilities, PageSpeedxcloud:ssl for certificatesxcloud:account for current user, API tokens, Cloudflare integrations, blueprints, healthBefore recommending git push, deployment webhooks, migration commands, cache clears, DNS changes, SSL changes, or live API actions:
Before anything else, scan the project directory for these files:
Read DETECT.md for full detection rules. Quick routing:
| Found in project | Stack | Action |
|---|---|---|
wp-config.php or wp-content/ |
WordPress | Read references/xcloud-native-wordpress.md |
composer.json + artisan |
Laravel | Read references/xcloud-native-laravel.md |
package.json + next.config.* |
Next.js | Docker path → use dockerfiles/nextjs.Dockerfile + compose-templates/nextjs-postgres.yml |
package.json (no framework config) |
Node.js | Read references/xcloud-native-nodejs.md |
composer.json (no artisan) |
PHP | Read references/xcloud-native-php.md |
requirements.txt or pyproject.toml |
Python | Docker path → use dockerfiles/python-fastapi.Dockerfile |
go.mod |
Go | Docker path — generate Dockerfile manually |
docker-compose.yml exists |
Existing Docker | Proceed to Step 1 below |
Dockerfile (no compose) |
Build-from-source | Generate compose → Scenario A below |
See references/xcloud-deploy-paths.md for the Native vs Docker decision guide.
Inspect the provided docker-compose.yml:
| Signal | Scenario |
|---|---|
build: or build: context: . |
A — Build-from-source |
| Caddy / Traefik / nginx-proxy service | B — Proxy conflict |
Multiple ports: across services |
B — Multi-port |
Host port 80 or 443 in any ports: mapping |
B — xCloud reserved port conflict |
./nginx.conf:/etc/nginx/... volume mount |
B — External config |
Multiple services each with build: |
C — Multi-service build |
image: some-public-image, single port |
Already compatible — verify port + env vars |
A compose file can trigger multiple scenarios simultaneously (handle A first, then B).
Read
references/scenario-build-source.mdfor full details.
What to do:
1. Remove build: directive from compose
2. Replace image: with ghcr.io/OWNER/REPO:latest
3. Generate .github/workflows/docker-build.yml using assets/github-actions-build.yml template
4. Generate .env.example from all ${VAR} references
Deliverables:
- Modified docker-compose.yml
- .github/workflows/docker-build.yml
- .env.example
- xCloud Deploy Steps (see Output Format)
Read
references/scenario-proxy-conflict.mdfor full details.
What to do:
1. Remove Caddy/Traefik/nginx-proxy service entirely
2. Remove SSL labels and multi-port ports: from app services (replace with expose:)
3. Add nginx-router service with inline config via configs: block
4. Expose single port (default: 3080) for xCloud to proxy
Deliverables:
- Modified docker-compose.yml with nginx-router + configs: block
- .env.example
- xCloud Deploy Steps
Read
references/scenario-multi-service-build.mdfor full details.
When multiple services have build: directives (separate frontend + backend + worker):
What to do:
1. For each service with build:, create a separate GHCR image path
2. Generate a matrix GitHub Actions workflow that builds all images in parallel
3. Update compose to use all GHCR image references
Deliverables:
- Modified docker-compose.yml (all build: removed)
- .github/workflows/docker-build.yml (matrix strategy)
- .env.example
Always produce complete, copy-paste-ready output:
## Modified docker-compose.yml
[full file]
## .github/workflows/docker-build.yml (Scenario A/C only)
[full file]
## .env.example
[full file]
## xCloud Deploy Steps
1. Push repo to GitHub
2. (Scenario A/C) Wait for GitHub Actions to build image — check Actions tab
3. Server → New Site → Custom Docker → connect repo
4. Exposed port: [PORT]
5. Env vars to add: [list from .env.example]
6. Deploy
7w4.net小葱技能站,你的AI助手技能库。
build: in the final compose — xCloud silently ignores it80 or 443 in final compose — xCloud's Nginx/SSL layer already owns them80, output 3080:80 and tell xCloud to use exposed/primary port 308080:80, treat it as invalid for xCloud and rewrite it to 3080:80"5432:5432" — use expose: internally)environment:, volumes:, healthcheck:, worker/sidecar servicesexpose: (internal) not ports: (host) for services behind nginx-routerconfigs.content: inline syntax requires Docker Compose v2.23+ — use heredoc command: alternative if uncertainxCloud receives public traffic on 80/443 through its own Nginx and SSL layer. Docker compose should expose one high host port for xCloud to proxy into:
User → xCloud Nginx 80/443 → Docker host port >=1024 → container port
Normalize ports before final output:
| Original mapping | Final xCloud mapping | xCloud exposed/primary port |
|---|---|---|
80:80 |
3080:80 |
3080 |
443:443 |
remove | n/a |
8080:80 |
prefer 3080:80 unless user explicitly requires 8080 |
3080 |
3000:3000 |
allowed | 3000 |
8000:8000 |
allowed | 8000 |
Final validation: no ports: mapping may start with 80: or 443:.
See examples/ for ready-made transformations:
- examples/rybbit-analytics.md — Caddy + multi-port app (Scenario B)
- examples/custom-app-dockerfile.md — build-from-source (Scenario A)
- examples/fullstack-monorepo.md — multi-service build (Scenario C)
这是一个质量很高的部署辅助工具,文档写得非常清晰完整,对各种常见项目类型(WordPress、Laravel、Next.js 等)都有对应的处理方案。它特别注重安全,在做任何可能影响项目的事情前都会先征求用户同意。提供的模板和示例很实用,能帮助用户避免在 xCloud 部署时常犯的错误。唯一的不足是某些复杂场景的指引还可以更丰富一些。