How to Deploy a Website With Git Version Control in cPanel

Uploading a website by hand works until the day a file is missed, an old version stays on the server, or a fix made in production never reaches the code you keep. cPanel’s Git Version Control feature solves that. You clone a repository into your account, and a short file named .cpanel.yml tells cPanel which files to copy into the site folder each time you pull a new version. This guide sets it up, shows how to deploy and roll back, and keeps the secrets out of the repository.

The feature is part of cPanel on SiteHarbour’s cPanel hosting plans. Use it for a theme, a static site or a PHP application whose code lives in a repository you control.

Before you start#

• A Git repository that holds the site’s code, reachable from the server. Use a read-only deploy key, not your personal password.
• The site folder you want to deploy to, usually public_html or a subfolder such as public_html/shop.
• A backup of the current site, as described in how to back up and restore a cPanel account.

Step 1: Keep secrets and build output out of the repository#

Add a .gitignore file that excludes the files that hold secrets, such as a wp-config.php or a .env file, and the folders the build creates. Commit it first, so no secret enters the history. A repository that has ever held a password should be treated as exposed, and the password should be changed.

git check-ignore -v .env

Expected: a line that names the ignore rule. If the command prints nothing, the file is not ignored and must not be committed.

Step 2: Create the repository on the server#

In cPanel, open Git™ Version Control under Files. Select Create, choose the option to clone a repository, then enter the repository address and the repository path. Set the path to a folder outside public_html, such as repositories/site, so the Git metadata is not served to visitors.

Expected: the repository appears in the list with its branch and the latest commit. If the clone fails, the error names the cause, usually a deploy key that the server cannot read or an address that cannot be reached from the server.

Step 3: Write the deployment file#

Create a file named .cpanel.yml in the root of the repository. cPanel reads it on each deploy and runs the tasks in order. This example copies everything except the Git folder into the site folder:

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

Replace cpuser with the cPanel account name, and keep the trailing slash on the deploy path. Commit the file to the repository, then pull the change on the server. Copying with cp -R * does not remove files you deleted from the repository, so a removed file stays on the site until you delete it by hand. For a site that removes files, use a separate task that cleans the target folder, and test it on a copy first.

Step 4: Deploy and check the result#

In Git™ Version Control, select the repository and choose Update from Remote to pull the latest commit. Then choose Deploy HEAD Commit. Expected: the task output shows each copy, and no error appears.

Check the site in a browser, and check the page that changed in this release. For a PHP site, look at the error log in cPanel as well, because a bad copy can break a page without a visible error on the home page.

Step 5: Roll back when a deploy goes wrong#

Rolling back is safer than fixing forward on a live site. In the repository’s commit list, find the last good commit, and deploy it. The same .cpanel.yml copies that commit’s files over the site. Confirm the site works, then fix the change in a new commit, and deploy that when it is ready.

A rollback does not undo database changes. If the release changed the database, restore the database from the backup taken before the deploy.

Step 6: Keep the live secrets on the server#

A database password or an API key belongs on the server, not in the repository. Keep the production wp-config.php or .env file in place on the server, and make sure the deploy never copies over it. Exclude it from the copy step, or keep it outside the folder the deploy writes to.

Step 7: Test the deploy on a copy before production#

If the site earns money, create a second repository branch or a staging subfolder, and deploy there first. A staging copy catches a broken theme or a missing file before visitors do. The staging steps are in how to set up a WordPress staging site.

Common mistakes#

• Putting the repository inside public_html. The Git metadata can be downloaded by anyone who requests it.
• Committing secrets. Ignore the production settings file before the first commit.
• A deploy path without the trailing slash. Files can land in the wrong folder.
• Expecting deletes to happen. A plain copy does not remove files that were deleted from the repository.
• Rolling back the code and not the database. A release that changed the data needs both.

Frequently asked questions#

Can I deploy a WordPress theme this way?#

Yes. Keep the theme folder in the repository, and deploy it into wp-content/themes. Do not put WordPress core or uploaded media in the repository.

Does this work with a private repository?#

Yes, with a read-only deploy key the server can use. Give that key read access to the one repository only.

Can the deploy run an install step, such as Composer?#

Only if the account supports the command you need. Test it in the repository first, and keep the install step short.

Is there a limit on deploys?#

There is no fixed limit, but each deploy copies files, so a large site takes longer. Deploy only the folders that changed where that is practical.

cPanel’s Git Version Control turns a manual upload into one repeatable deploy. Keep the repository outside the web root, write a short .cpanel.yml, deploy a known commit, and keep the secrets on the server. Roll back to the last good commit when a release goes wrong, and restore the database too if the release changed it. For the account-level security steps that go with this setup, read how to keep your cPanel account and sites secure.