thienanblog/awesome-ai-agent-skills/vps-docker-traefik-deploy

VPS Docker Traefik Deploy

Deliver the requested deployment work using the project's operating contract. Distinguish planning and file preparation from changing a live environment.

Delegation

Run in the main conversation by default. Delegation can increase usage: obtain explicit approval for the proposed agent count and scope before using subagents. Reuse that approval within its bounds; ask again before expanding the approved count or scope.

Establish the target

Read existing runbooks, Compose and Traefik configuration, release scripts, and available host evidence. Establish the target host, OS, domains, ingress, registry, persistent data, backup/restore expectations, and deployment authorization. Discover facts before asking; for a routine release the existing runbook and configuration usually answer them.

For an existing deployment, preserve supported topology and required release gates. For a new one, prefer a supported Ubuntu LTS or Debian stable host, an operator account with appropriate privileges, registry-built immutable images, and Traefik ingress. Verify current official installation guidance when provisioning; reference commands are examples, not a reason to reinstall a working host.

Keep production boundaries explicit

• Use authorization already granted for the named environment and action. Prepare configuration, diffs, checks, and rollback before asking for any missing live-operation approval. Ask about a new destructive migration or exposure outside that scope.
• Keep databases, caches, registry/admin dashboards, and internal app ports private by default. Expose only needed ingress and operator access, commonly SSH, HTTP/ACME, and HTTPS. Use loopback bindings and SSH tunnels for private operator tools when suitable.
• Keep credentials out of images, source, logs, and reports. Preserve persistent state outside container writable layers.
• Use immutable image tags or digests and retain the prior release. Avoid server-side rebuilds and mutable latest references for releases unless the established operating contract provides equivalent reproducibility.
• Address backup and rollback for affected persistent state. A container rollback cannot undo an incompatible database migration; establish the recovery path before applying it.

Prepare, deploy, verify

Choose only the references needed for the work:

Validate the effective configuration without exposing secrets, confirm image availability and recovery readiness, then execute the authorized rollout. Verify container health, public routes/TLS, logs, and affected application flows. Test restore in an isolated target when required; never restore over live data as a casual verification step.

Reuse valid evidence for unchanged responsibilities, while completing the project's production release gate. Pruning, retention changes, DNS changes, and host hardening belong in a release only when needed and authorized.

Handoff

Report what was prepared or deployed, the target and immutable release identifier, checks and results, and rollback readiness. For new infrastructure, include topology, public exposure, state ownership, and recovery commands. Keep a routine release report to what changed. Say a restore was tested only when it actually ran, not when its configuration was inspected.