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.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
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.
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.yml work on xCloud. Fix anything xCloud does not support, especially Docker build steps, proxy services, and host ports 80/443.
The agent should then:
Ask whether to perform read-only analysis or generate files.
Detect the stack after the user confirms project inspection.
Choose native xCloud deployment or Custom Docker.
Generate or fix Docker files only after explicit confirmation.
Explain the exact xCloud UI/API steps in simple language.
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 or . If an app listens on container port , use and set xCloud's exposed/primary port to .
80
443
80
3080:80
3080
Adapt any docker-compose.yml to work with xCloud — a git-push Docker deployment platform.
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.
Current xCloud API + Agent Skills Context
xCloud now publishes API-backed agent skills for operational work:
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.
API Token Flow
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:
Ask whether the user wants live xCloud API help.
State the exact live operation before requesting a token, such as "list servers" or "read deployment logs".
Ask for a least-privilege, short-lived token where possible.
If no token is available, ask the user to provide or configure a private XCLOUD_API_TOKEN.
Never print, store, log, reuse, or commit the token. Use it only for the approved action.
Use the official xCloud API skills for live operations:
xcloud:servers for server capacity, PHP, databases, cron, firewall, sudo users, WordPress provisioning
xcloud:sites for site status, domains, backups, cache, SSH, git, deployment logs
Always use expose: (internal) not ports: (host) for services behind nginx-router
Always report the xCloud exposed/primary port as the host-side port from the single allowed web mapping
WebSockets? Add upgrade headers to nginx config (see proxy-conflict reference)
configs.content: inline syntax requires Docker Compose v2.23+ — use heredoc command: alternative if uncertain
Port Normalization
xCloud 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:.
Examples
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)
