xcloud-docker-deploy
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.
Install via CLI (Recommended)
clawhub install openclaw/skills/skills/asif2bd/xcloud-docker-deployxCloud Docker Deploy
Adapt any docker-compose.yml to work with xCloud — a git-push Docker deployment platform.
How xCloud Works
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.
Phase 0 — Detect Project Type First
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.
Step 1 — Detect Which Scenarios Apply
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).
Scenario A — Build-from-Source
Read
references/scenario-build-source.mdfor full details.
What to do:
- Remove
build:directive from compose - Replace
image:withghcr.io/OWNER/REPO:latest - Generate
.github/workflows/docker-build.ymlusingassets/github-actions-build.ymltemplate - Generate
.env.examplefrom all${VAR}references
Deliverables:
- Modified
docker-compose.yml .github/workflows/docker-build.yml.env.example- xCloud Deploy Steps (see Output Format)
Scenario B — Proxy Conflict / Multi-Port / External Config
Read
references/scenario-proxy-conflict.mdfor full details.
Metadata
Not sure this is the right skill?
Describe what you want to build — we'll match you to the best skill from 16,000+ options.
Find the right skillPaste this into your clawhub.json to enable this plugin.
{
"plugins": {
"official-asif2bd-xcloud-docker-deploy": {
"enabled": true,
"auto_update": true
}
}
}Tags
Related Skills
host-experience
Host virtual experiences for AI agents on drifts.bot. Create multi-step journeys with narrative, soul prompts, and time-locked progression. Design worlds other agents can travel through. Full hosting API with draft/publish workflow, step management, and scheduled releases.
doctorbot-ci-validator
Stop failing in production. Validate your GitHub Actions, GitLab CI & Keep workflows offline with surgical precision. Born from Keep bounty research, perfected for agents.
codex-review
Three-tier code quality defense: L1 quick scan, L2 deep audit (via bug-audit), L3 cross-validation with adversarial testing. 三级代码质量防线。
afrexai-observability-engine
Complete observability & reliability engineering system. Use when designing monitoring, implementing structured logging, setting up distributed tracing, building alerting systems, creating SLO/SLI frameworks, running incident response, conducting post-mortems, or auditing system reliability. Covers all three pillars (logs/metrics/traces), alert design, dashboard architecture, on-call operations, chaos engineering, and cost optimization.
qa-check
Mandatory quality assurance for all dev work before publishing. Use BEFORE deploying any project to production. Validates build, tests browser functionality, checks mobile responsiveness, and ensures no broken links/images.