/SKILL.md
Deploy any project to xCloud hosting — auto-detects stack (WordPress, Laravel, PHP, Node.js, Next.js, NestJS, Python, Go, Rust), routes to native or Docker deployment, generates production-ready Dockerfile, docker-compose.yml, GitHub Actions CI/CD, and .env.example. Works from zero Docker setup.
npx skillsauth add asif2bd/xcloud-docker-deploy-skill xcloud-docker-deployInstall 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.
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.
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 |
| ./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:
build: directive from composeimage: with ghcr.io/OWNER/REPO:latest.github/workflows/docker-build.yml using assets/github-actions-build.yml template.env.example from all ${VAR} referencesDeliverables:
docker-compose.yml.github/workflows/docker-build.yml.env.exampleRead
references/scenario-proxy-conflict.mdfor full details.
What to do:
ports: from app services (replace with expose:)nginx-router service with inline config via configs: block3080) for xCloud to proxyDeliverables:
docker-compose.yml with nginx-router + configs: block.env.exampleRead
references/scenario-multi-service-build.mdfor full details.
When multiple services have build: directives (separate frontend + backend + worker):
What to do:
build:, create a separate GHCR image pathDeliverables:
docker-compose.yml (all build: removed).github/workflows/docker-build.yml (matrix strategy).env.exampleAlways 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
build: in the final compose — xCloud silently ignores it"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 uncertainSee 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)development
Maintainer-only workflow for handling GitHub Secret Scanning alerts on OpenClaw. Use when Codex needs to triage, redact, clean up, and resolve secret leakage found in issue comments, issue bodies, PR comments, or other GitHub content.
development
Maintainer workflow for OpenClaw releases, prereleases, changelog release notes, and publish validation. Use when Codex needs to prepare or verify stable or beta release steps, align version naming, assemble release notes, check release auth requirements, or validate publish-time commands and artifacts.
development
Run, watch, debug, and extend OpenClaw QA testing with qa-lab and qa-channel. Use when Codex needs to execute the repo-backed QA suite, inspect live QA artifacts, debug failing scenarios, add new QA scenarios, or explain the OpenClaw QA workflow. Prefer the live OpenAI lane with regular openai/gpt-5.4 in fast mode; do not use gpt-5.4-pro or gpt-5.4-mini unless the user explicitly overrides that policy.
development
End-to-end Parallels smoke, upgrade, and rerun workflow for OpenClaw across macOS, Windows, and Linux guests. Use when Codex needs to run, rerun, debug, or interpret VM-based install, onboarding, gateway smoke tests, latest-release-to-main upgrade checks, fresh snapshot retests, or optional Discord roundtrip verification under Parallels.