Git-Based Deployment on Shared cPanel Hosting: SSH, Deploy Keys, and Safe Rollbacks

Shared cPanel hosting has a reputation for meaning FTP uploads and crossed fingers. It does not have to. On a recent marketplace build hosted on a South African cPanel plan, the deploy pipeline is git-based, runs over SSH, and has a defined rollback path. Here is how it is put together.

SSH access is usually there, just not on port 22

Many local shared hosts enable SSH but move it off the default port and gate it behind a cPanel setting. On this account it runs on a non-standard high port, which is why early connection attempts failed silently. Once enabled, the account has a real shell: a current PHP version, WP-CLI, git, and a normal home directory. That is enough to treat it like a small server for deployment purposes.

A read-only deploy key, generated on the server

The deploy model is a plain git pull on the server against the GitHub repository. Authentication is an ed25519 key pair generated directly on the hosting account and registered on GitHub as a read-only deploy key for that one repository. The private key never leaves the server, and it cannot push, so a compromise of the hosting account cannot rewrite history in the repo. The working copy on the server tracks a release branch, not main, so an accidental commit to main is never live until it is promoted.

The deploy itself

• Take a timestamped copy of the current deployed build, either a zip or a note of the current git ref.
• Take a database dump before anything changes.
• Run git pull on the release branch.
• Run any pending WP-CLI steps: cache flush, database migrations for the custom plugin.
• Smoke-test the critical paths by hand: log in, load a booking, reach the payment step.

cPanel’s own git feature over HTTPS, and SFTP deploys, are kept documented as fallbacks, but the SSH path is the primary one and has carried real feature work across many deploys in a single day.

Rollback without images or snapshots

Cloud platforms give you an instant rollback by pointing traffic at the previous image. Shared hosting does not. So rollback is manual and prepared in advance: restore the timestamped build copy over the working directory, and if the database schema changed, restore the pre-deploy dump or run the down migration. Because both artefacts are captured on every single deploy, a bad release is a five-minute recovery, not an incident.

What still is not there

There is no managed monitoring service, so uptime checks are an external pinger on a short interval with email alerts, and log retention is whatever the host keeps. Disaster recovery leans on the host’s daily off-site backups, with a weekly database and media dump pushed to separate storage as insurance. It is not a cloud platform. But it is a disciplined pipeline, and "shared hosting" is not an excuse for deploying by drag and drop.

“The hosting tier decides your ceiling. It does not have to decide your process.”

Related