cPanel Git Version Control: Deploy Your Site Without FTP

If you're still deploying changes by dragging files over FTP or unzipping a fresh export in File Manager, cPanel's Git Version Control feature can save you a lot of that hassle. It lets you push code straight from GitHub, GitLab, or Bitbucket into your hosting account, with an optional deploy script that copies files into your live document root automatically. Here's how to set it up properly, and how to fix it when a deploy silently does nothing.

What cPanel's Git Version Control Feature Actually Does

Under the hood, cPanel just runs a bare Git repository somewhere under your home directory (usually ~/repositories/) and gives you a UI to clone from a remote, pull updates, and run a deploy script. It's not magic — it's a wrapper around commands you could run yourself over SSH, but the UI makes the SSH key setup and the deploy hook a lot less fiddly to get right the first time.

Two things trip people up before they even get to their first deploy: SSH access has to be enabled on the account, and the remote repo needs a key it trusts. Get those two right and the rest is mechanical.

Before You Start: What You Need

• SSH access enabled for the cPanel account (ask your host to turn this on if you don't see a Terminal icon in cPanel).
• A Git repository on GitHub, GitLab, or Bitbucket that you can push to.
• Know which directory should receive the deployed files — usually public_html or an addon domain's document root.
• A local Git client on your machine (or you'll be committing straight from cPanel's Terminal, which also works).

Step 1: Generate and Add an SSH Key in cPanel

Go to cPanel → Security → SSH Access → Manage SSH Keys → Generate a New Key. Leave the key size at 4096 bits and set a passphrase if you want an extra layer of protection (you'll need it every time cPanel authorizes the key, so a blank passphrase is fine for most setups). After generating it, click Manage next to the key and authorize it — this adds it to ~/.ssh/authorized_keys on the server side.

Now copy the public key and add it to your Git host as a deploy key:

• GitHub: Repo → Settings → Deploy keys → Add deploy key. Tick "Allow write access" only if cPanel will be pushing back to the repo, which is rare — read-only is enough for pulling deploys.
• GitLab: Repo → Settings → Repository → Deploy Keys.
• Bitbucket: Repo → Repository settings → Access keys.

Skipping this step is the single most common reason the next step fails with a permission error, so don't rush past it.

Step 2: Create the Repository in cPanel

Go to cPanel → Files → Git Version Control → Create. You've got two options:

1. Clone a Repository — paste your remote's SSH clone URL (e.g. git@github.com:yourname/yoursite.git), and set the repository path, something like /home/yourcpuser/repositories/yoursite.
2. Create a New Repository — useful if you want to start version-controlling an existing site that isn't in Git yet.

Note that the repository path is not your live site — it's a working copy. You still need a way to get files from there into public_html, which is what the next step handles.

Step 3: Set Up .cpanel.yml for Automatic Deployment

When you click "Manage" on a repository, cPanel shows a Pull or Deploy tab. Deploys are driven by a file called .cpanel.yml that lives in the root of your repo. Without it, "Deploy HEAD Commit" just does nothing — this catches a lot of people out on their first attempt.

A minimal example that copies everything into public_html:

---
deployment:
  tasks:
    - export DEPLOYPATH=/home/yourcpuser/public_html/
    - /bin/cp -R * $DEPLOYPATH

For a real project you'll usually want something closer to this, which excludes dev-only files and runs Composer if you're deploying a PHP app:

---
deployment:
  tasks:
    - export DEPLOYPATH=/home/yourcpuser/public_html/
    - /bin/cp -R --parents app/ config/ public/ vendor/ $DEPLOYPATH
    - /usr/local/bin/composer install --no-dev --working-dir=$DEPLOYPATH

Commit .cpanel.yml to your repo's root and push it before you try deploying — cPanel reads it from the branch you're deploying, not from a local copy.

Step 4: Deploy and Verify

Back in Git Version Control → Manage → Pull or Deploy, click Update from Remote to pull the latest commits into the bare repo, then Deploy HEAD Commit to run the tasks in .cpanel.yml. Check the on-screen log — it shows the exact commands that ran and their output, so if something failed you'll usually see why right there instead of having to guess.

Confirm the deploy actually landed by checking a file timestamp:

ls -la ~/public_html/ | head

Common Errors and Fixes

Keeping Secrets Out of Your Repo

Never commit wp-config.php, .env, or any file with live database credentials or API keys. Add them to .gitignore and instead keep a template (wp-config-sample.php or .env.example) in the repo, with the real file created once directly on the server and left untouched by deploys. If you've already committed a secret by accident, rotate that credential — removing it from a later commit doesn't remove it from Git history.

Prevention: Keeping Deploys Boring

• Deploy from a dedicated branch (e.g. main or production) rather than whatever branch you happened to push last.
• Test .cpanel.yml changes on a staging subdomain before pointing them at the live site.
• Keep a cPanel backup or a tagged Git commit before any deploy that changes the database schema or config structure.
• If multiple people deploy, agree on who runs "Deploy HEAD Commit" and when — two people deploying different commits back-to-back is a classic way to lose a fix.

Wrapping Up

Once the SSH key and .cpanel.yml are right, Git deployment in cPanel turns "upload the new files" into a two-click job with a visible log of exactly what happened. It won't replace a full CI/CD pipeline, but for most WordPress or small PHP projects it's a big step up from manual FTP uploads, and it gives you a real commit history to point to when something breaks.