If you're still updating your live site by dragging files into FileZilla, there's a faster and safer way. cPanel's built-in Git™ Version Control feature lets you push code straight from your local machine (or GitHub) to your hosting account, with a deploy step that runs automatically. No more overwriting the wrong file, no more "did I upload that change?" moments. Here's how to set it up properly, plus the gotchas that trip people up the first time.
Why bother with Git deployment on shared or VPS hosting?
FTP works fine when you're the only one touching a site and changes are rare. It falls apart the moment you have more than one person editing code, or you want to roll back a bad change quickly. With Git deployment you get:
- A full history of every change, with who made it and why (assuming decent commit messages)
- One command to push a release instead of manually re-uploading a folder
- An easy rollback — checkout an older commit and redeploy
- No risk of a half-finished FTP transfer leaving your site in a broken state
This isn't just for developers with big teams. Even a solo site owner running a custom theme or a small PHP app benefits from having version history instead of a folder full of theme-old, theme-old2, theme-final.
What you need before you start
- A cPanel hosting account with the Git™ Version Control feature enabled (standard on SkyServer's Business and VPS cPanel plans)
- SSH access, or at least the ability to run Git commands from your local terminal
- Git installed locally
- Basic comfort with the command line — this isn't a GUI-only workflow, though cPanel does have a UI for the repository setup itself
If SSH isn't enabled on your account yet, turn it on in cPanel > Security > SSH Access first, or ask support to flip it on.
Step 1: Create the repository in cPanel
- Log in to cPanel and open Files > Git™ Version Control
- Click Create
- Set the repository path — something like
/home/username/repos/mysitekeeps it outsidepublic_html, which is what you want (more on why below) - Set the repository name and, if you're starting fresh, leave "Clone a Repository" unchecked to create a blank repo
- Click Create
cPanel will show you a clone URL that looks like:
ssh://username@yourdomain.com:22/home/username/repos/mysite
Cloning from an existing GitHub/GitLab repo instead
If your code already lives on GitHub, check "Clone a Repository" during creation and paste the HTTPS or SSH clone URL. For private repos you'll need to add a deploy key — cPanel generates an SSH public key for the repo under the Manage screen that you can paste into your GitHub repo's Deploy Keys settings (read-only is enough).
Step 2: Set the deployment path — this is the part people get wrong
Here's the mistake we see most often: people point the repository directly at public_html. That means your entire .git folder, commit history, and possibly your .env or config files sit inside the web root, publicly reachable if directory listing or a misconfigured rule ever exposes it.
The correct pattern is:
- Keep the actual Git repository outside
public_html— e.g.~/repos/mysite - Use cPanel's deployment feature to copy only the built/deployed files into
public_htmlon push
In the repository's Manage screen, go to the Pull or Deploy tab and set your deployment path to public_html (or a subdirectory for an addon domain). Then define what gets deployed using a .cpanel.yml file at the root of your repo:
---
deployment:
tasks:
- export DEPLOYPATH=/home/username/public_html/
- /bin/cp -R app/* $DEPLOYPATH
- /bin/cp -R public/* $DEPLOYPATH
- /bin/rm -rf $DEPLOYPATH/cache/*
Every push to the tracked branch (usually main) triggers these tasks automatically. You control exactly which files land in the web root — build artifacts only, never your source config, tests, or CI files.
Step 3: Push and confirm it deploys
Clone the repo locally using the SSH URL cPanel gave you:
git clone ssh://username@yourdomain.com:22/home/username/repos/mysite
cd mysite
# make a change
git add .
git commit -m "Update homepage copy"
git push origin main
Back in cPanel, the Pull or Deploy tab shows a deploy log for every push. If .cpanel.yml is missing or malformed, cPanel just pulls the latest commit into the repo directory without running any deployment tasks — check that file first if nothing shows up in public_html.
Common problems and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| "Permission denied (publickey)" on push | Your local SSH key isn't added to the cPanel account | Add your public key in cPanel > SSH Access > Manage SSH Keys, then Authorize it |
| Push succeeds but site doesn't change | No .cpanel.yml, or deployment path is wrong | Add/fix .cpanel.yml at the repo root; verify the deployment path in Manage > Pull or Deploy |
| Deploy log shows "Task failed" on a cp/rm command | File path in .cpanel.yml doesn't exist, or a permissions issue | SSH in and run the same command manually to see the real error; check ownership with ls -la |
| Repository won't clone from GitHub — "Repository not found" | Private repo without a deploy key, or wrong URL format | Add the cPanel-generated public key to the GitHub repo's Deploy Keys, use the SSH clone URL not HTTPS |
| .git folder is publicly accessible at yourdomain.com/.git | Repository was created directly inside public_html | Move the repo outside public_html and redo the deployment path setup above |
Prevention: keep it clean going forward
- Never point a live repository straight at
public_html— always deploy through.cpanel.yml - Add a
.gitignorefor anything environment-specific —wp-config.php,.env, cache directories, uploads - Use a staging subdomain with its own repository branch before deploying to production; SkyServer's cPanel plans support this with Softaculous staging clones alongside Git
- If you're on a VPS, consider a post-receive hook that also restarts PHP-FPM or clears OPcache after deploy, since code changes sometimes get served from a stale opcode cache otherwise
- Tag releases (
git tag v1.2.0) before major changes so a rollback is a one-linegit checkoutinstead of digging through commit history under pressure
Frequently Asked Questions
Does Git Version Control work on shared hosting, or only VPS?
It works on any cPanel account with the feature enabled and SSH access, which includes most of SkyServer's Business shared hosting tier and all VPS plans. Check under Files > Git™ Version Control — if you don't see it, ask support to enable it.
Can I use this with WordPress?
Yes, though most people only put their theme or a custom plugin under version control rather than WordPress core. Keep wp-config.php, wp-content/uploads, and the database out of the repo — those change independently of your code and don't belong in Git history.
What happens if a deploy task fails halfway through?
cPanel stops at the failed task and shows it in the deploy log; earlier tasks that already ran are not rolled back automatically. This is why it's worth keeping .cpanel.yml tasks simple and idempotent — a re-run should be safe to execute again from scratch.
Can multiple developers push to the same repository?
Yes. Each developer adds their own SSH public key under SSH Access > Manage SSH Keys and gets it authorized. Everyone pushes to the same remote; cPanel deploys whatever lands on the tracked branch, same as any normal Git remote.
Is this the same as using GitHub Actions to deploy?
Conceptually similar but simpler — cPanel's deployment runs locally on the server the moment it receives a push, with no external CI runner involved. For more complex pipelines (running tests before deploy, building assets), pairing GitHub Actions with an SSH deploy step is a common next move once you outgrow the basic .cpanel.yml workflow.
