Deploying a Python API without babysitting the server

Keep the deployment shape small

A small API does not need a miniature platform team. The useful boundary is a container for the application, Caddy at the public edge, and one repeatable command that moves the server to a known Git revision.

The important part is not making deployment clever. It is making every step visible enough that a failed release can be understood from the terminal without reconstructing hidden state.

• The application image contains the exact runtime and dependencies.
• Caddy owns certificates and the public HTTP boundary.
• Compose describes the running services and their private network.
• The CI job performs the same deployment command every time.

Make the server converge on main

The deploy job should not depend on whatever happens to be checked out on the VPS. Fetch the remote state, select the deployment branch, reset it to the remote revision, and let Compose rebuild only what changed.

git fetch --prune origin
git checkout main
git reset --hard origin/main
docker compose up -d --build --remove-orphans
docker compose ps

Treat health as part of startup

A running process is not necessarily a ready service. The application container should expose a cheap health check, and the proxy should wait for that check before sending traffic upstream.

This keeps an ordinary rebuild boring: the old container serves until it stops, the new one proves it can answer, and the proxy has a clear target. Logs remain the first debugging surface instead of an afterthought.

Keep rollback deliberately plain

Rollback does not require another deployment system. Check out a known-good commit on the server and run the same Compose command. Once the incident is understood, fix forward on main and deploy normally.

The result is not zero downtime under every possible failure. It is something more useful for a personal service: a deployment process whose state fits in your head.