I recently set up a full CI/CD pipeline using GitHub Actions to build and deploy an Astro project to cPanel shared hosting.

This matters because a large portion of real client work still lives on cPanel. In practice, that usually translates to slow FTP uploads, manual builds, and brittle deployment steps that do not survive handoffs or scale beyond one developer. I wanted a repeatable, repo-owned deployment pipeline that works where clients already are.

The final setup is simple on the surface: every push to the main branch triggers a GitHub Actions workflow that builds the Astro project and deploys the static output to the server over SSH. No local builds, no FTP, no manual syncing.

Getting there was not simple.

I failed multiple times before it worked end-to-end. Builds passed locally but failed in CI. Deployments succeeded but landed in the wrong directories. SSH keys worked on my machine but not inside GitHub Actions. Path resolution, permissions, environment differences, and silent cPanel quirks caused avoidable breakages.

What made the difference was systematic debugging. I leaned heavily on AI for hypothesis generation, deep Google searches for edge cases, and careful log inspection to isolate each failure. In hindsight, most of the issues were avoidable. At the time, none of them were obvious. Solving them forced me to understand CI environments, SSH authentication, build artifacts, and shared-hosting constraints at a much deeper level.

Why this setup is valuable for client work.

Deployments become predictable. Rollouts become consistent. Handoffs become easier. The risk of “it works on my laptop” drops sharply because the build runs in a controlled environment on every push. This eliminates the need for FTP entirely. FTP is slow, stateful, and error-prone. CI-driven SSH or rsync deployments are faster, deterministic, and auditable.

it also avoids platform lock-in. Netlify, Vercel, and similar platforms are excellent, but they introduce pricing cliffs, usage limits, and long-term dependency on vendor-specific build systems. This pipeline keeps the build logic in the repository and treats hosting as an interchangeable deployment target. It upgrades “cheap hosting” into a modern delivery workflow. cPanel is often dismissed as legacy infrastructure, but when paired with GitHub Actions, it becomes a viable target for modern static and hybrid frontends like Astro.

Most importantly, it gives me a repeatable deployment pattern I can apply across multiple client projects regardless of where they are hosted.

Next iteration.

My next step is to keep hardening the pipeline: introduce an explicit deploy branch strategy when needed, add a lightweight rollback plan, and tighten the workflow with better diff-based uploads (where applicable) to minimize deployment time on large sites.