Still unsure if helpful or if stupid. Agent skill that allows docker deployments directly from a GitHub repo. Agent writes code. Human sets up infra. Automation deploys services.
https://github.com/linksawakening/docker-git-deploy#how-it-works1. **Install the skill.** The human asks the agent to install this skill.
2. **State the goal.** The human asks the agent to deploy services X, Y, Z to a server.
3. **Scope it.** The agent asks about the current server, explains the minimum requirements for install, and explains the git access involved — the **agent needs write** access to create and push the deployment repo, while the **server only needs read-only** access to pull it. Any Git host works (GitHub, GitLab, Bitbucket, self-hosted).
4. **Create the deployment repo.** The agent generates a pure-config repo from the starter (compose files, service definitions, `.env.example`) and pushes it to the git remote.
5. **Bootstrap the server.** The agent hands the human a one-line install command to run as root on the server; it clones the repo and installs the systemd timer. The agent also explains **which secrets and environment values each service needs** (derived from the repo's `.env.example`) and **how to create the `.env`** on the host — e.g. `cp .env.example .env` and then fill in real values. The deploy is skipped until `.env` exists, and secrets never live in the repo. The agent helps troubleshoot but never needs access to the server itself.
6. **Ongoing adjustments and new services.** From then on, the human asks the agent to add a service or change config, and the agent commits it to the repo and merges to `main` — from any location, with no server access. The server polls `origin/main` on its timer and applies the change automatically, reconciling with `docker compose up -d --wait` and rolling back if a new version fails to become healthy. The human's **only** manual step is updating `.env` on the server — and only when the agent says a new or changed service needs a new secret.
