docker-deploy

Docker Deploy Skill

Detect the target project, build, deploy, and verify. Never guess - confirm project from context or ask.

Projects

Example: Web App (Dev Server)

• Path: ~/my-app/
• Container: my-app
• Ports: 3000->3000

Build and deploy:

cd ~/my-app
docker build -t my-app:latest .
docker stop my-app 2>/dev/null || true
docker rm my-app 2>/dev/null || true
docker run -d --name my-app -p 3000:3000 my-app:latest

Verify:

curl -s -o /dev/null -w "%{http_code}" http://localhost:3000

---

Example: API Service (Remote Server)

• Source: /path/to/api/main.py
• Deploy path (remote): /opt/my-api/
• Container: my-api, port 8090

Deploy flow:

# 1. Copy updated file(s) to remote
scp /path/to/api/main.py remote-server:/opt/my-api/main.py

# 2. Rebuild and restart on remote
ssh remote-server "cd /opt/my-api && docker compose build && docker compose up -d"

Verify:

curl -s -o /dev/null -w "%{http_code}" https://api.example.com/health

Env vars: /opt/my-api/.env on remote (do not overwrite without reading first).

---

Example: Stateful Service (WhatsApp Gateway, DB, etc.)

• Container: my-gateway, port 19000
• Config: /opt/my-gateway/

CRITICAL: NEVER run docker-compose down or docker-compose up on stateful containers. This destroys session state (e.g., WhatsApp linking, DB data).

Restart only:

docker restart my-gateway

---

Workflow

1. Detect project from user input.
2. If ambiguous, ask: "Which project?"
3. Run the build/deploy sequence for that project.
4. Run verification step and show the HTTP status code or container status.
5. Report result. If verification fails, check container logs.

Check logs if something breaks:

# Local containers
docker logs --tail 50 <container-name>

# Remote containers
ssh remote-server "docker logs --tail 50 <container-name>"