Category
VPS deploys, GitHub Actions pipelines, and zero-downtime shipping.
← All articlesA rolling deploy is invisible for a stateless HTTP service. Do the same to a WebSocket service and you have disconnected everyone; do it to an SFU and you have ended everybody call. The orchestrator did exactly what it was told — what it was told assumed requests are short.
cPanel has had built-in Git deployment for years and almost nobody uses it, because the first thing everyone tries — push to GitHub and expect the site to update — is the one thing it does not do on its own. The working setup, the three gotchas that stop people, and an honest comparison against FTP.
No SSH, no shell, no root, no daemons. It is easy to treat that as a broken environment, but a great many real sites live there happily — and they still deserve a deploy that is not a person dragging folders in FileZilla. What a real pipeline looks like when writing a file is the only verb you have.
Zero-downtime deployment is discussed as if it needs an orchestrator and a platform team. On one VPS it needs a directory layout and a symlink, and fits on one screen. The hard part is not the swap — it is the four things that quietly stay broken after it.
You do not need a cloud platform for push-to-deploy. You need a runner that can build, a server that can receive, and a key that can do exactly one thing — and most of the work is making sure that key cannot do anything else.
A deploy pipeline puts code on a server automatically, from the internet, on every push. Building one on a box you have not hardened is a decision to automate access to something you have not secured. This is the hour of work that goes first — and the order matters more than the list.
Every CI/CD tutorial assumes a managed platform. None of my client projects have one — they run on shared hosting with cPanel and no root, or a single VPS somebody has to maintain. What each environment takes away from you, and a pipeline that works inside those limits.
