How to Deploy Your Site with Git on cPanel

Deploying a website by dragging files over FTP works until it does not: a half-uploaded change breaks the live site, you cannot tell what changed, and rolling back means digging through a backup. Deploying with Git fixes all of that. This Ultra Web Hosting guide shows you how to push your code to a repository and pull it onto your cPanel account, both through the cPanel Git Version Control interface and straight from the SSH terminal, including a working .cpanel.yml that copies your build into public_html on every deploy.

01. Why Deploy with Git Instead of FTP

FTP moves whole files with no memory of what came before. Git tracks every change as a commit, so your site's history lives in the repository and deploying becomes a single, atomic action rather than a slow trickle of uploaded files. On a shared cPanel account that difference matters more than it sounds.

02. Before You Start

You need a handful of things in place before the first clone:

• A Git repository for your site, hosted on GitHub, GitLab, Bitbucket, or any Git host you can reach over HTTPS or SSH. This guide assumes your code already lives in one.
• SSH access enabled on your Ultra Web Hosting account. The cPanel Git interface works without it, but private repositories and Method B need SSH. If it is not on yet, see our SSH access guide to request and use it.
• cPanel login for the account, so you can open Git Version Control and the Terminal.
• Your account username and home path. Files live under /home/youruser/ and your live site is usually /home/youruser/public_html. For a map of where things sit, see our server paths guide.

03. Method A: The cPanel Git Version Control Interface

cPanel ships a Git Version Control tool that handles cloning and deploying without touching a terminal. This is the friendliest path and the one to start with.

1. In cPanel, open Git Version Control (under the Files section).
2. Click Create.
3. Turn on Clone a Repository.
4. In Clone URL, paste your repository's URL. For a private repo over SSH this looks like [email protected]:youruser/yourrepo.git; for a public repo you can use the HTTPS URL.
5. Set Repository Path to where the clone should live. Keep it out of the web root, for example repositories/yoursite, which resolves to /home/youruser/repositories/yoursite.
6. Give it a Repository Name you will recognize, then click Create.

cPanel clones the repo into that path. It does not put files in public_html yet: that is the job of the .cpanel.yml deployment file in Section 05. The clone directory is your working copy on the server, and the live site is wherever your deploy steps copy the files.

04. Set Up a Read-Only Deploy Key for a Private Repo

To clone a private repository, cPanel authenticates to your Git host with an SSH key. The clean way to do this is a deploy key: an SSH key that grants read-only access to one repository and nothing else. Generate the key on the server, then register its public half with the repo.

Generate the key in cPanel

1. In cPanel, open SSH Access, then Manage SSH Keys.
2. Click Generate a New Key. Give it a name like deploy_yoursite, leave the type at ED25519 or RSA 4096, and create it.
3. Back on the key list, click View/Download next to the public key and copy the full ssh-ed25519 ... (or ssh-rsa ...) line.
4. You do not need to authorize this key for logging in to your own account. It is only used to read from your Git host.

Add it as a deploy key on your Git host

1. GitHub: open the repository, go to Settings > Deploy keys > Add deploy key. Paste the public key, leave Allow write access unchecked, and save.
2. GitLab: Settings > Repository > Deploy keys, paste the key, keep it read-only, and add it.
3. Bitbucket: Repository settings > Access keys > Add key, paste, save.

Now the clone URL in Section 03 can use the SSH form ([email protected]:youruser/yourrepo.git) and cPanel will authenticate with that deploy key.

05. The .cpanel.yml Deployment File

The .cpanel.yml file is a small YAML script that lives in the root of your repository and tells cPanel what to do after it pulls new code. Without it, deploying does nothing but update the clone. With it, cPanel runs each command under the deployment: tasks: list, which is where you copy your files into public_html.

Here is a working example for a repository whose deployable files sit in the project root. It copies everything into the account's public web directory:

---
deployment:
  tasks:
    - export DEPLOYPATH=/home/youruser/public_html/
    - /bin/cp -R index.html DEPLOYPATH
    - /bin/cp -R assets DEPLOYPATH
    - /bin/cp -R app DEPLOYPATH

If your site builds into a subfolder such as dist/ or public/, point the copy at that folder instead so only the built output goes live:

---
deployment:
  tasks:
    - export DEPLOYPATH=/home/youruser/public_html/
    - /bin/cp -R dist/. DEPLOYPATH

A few rules that save a lot of confusion:

• The file must be named exactly .cpanel.yml (note the leading dot) and sit in the repository root, not a subdirectory.
• Use two-space indentation and no tabs. YAML rejects tabs, and a stray tab is a common reason the deploy silently fails.
• Reference DEPLOYPATH after exporting it, and use full paths for the cp binary as shown.
• Replace youruser with your actual cPanel account username.

06. The Pull-to-Deploy Workflow

With the clone in place and a valid .cpanel.yml committed, your day-to-day loop is short. You work locally, push, and then tell cPanel to fetch and deploy.

1. Work locally. Make your changes, commit them, and push to your Git host as usual: git add -A, git commit -m "your message", git push.
2. Pull onto the server. In cPanel Git Version Control, click Manage next to the repository, then the Pull or Deploy tab, and click Update from Remote. This fetches your latest commit into the clone.
3. Deploy. Click Deploy HEAD Commit. cPanel runs the tasks in .cpanel.yml, copying your files into public_html. The page shows the deploy log and a timestamp when it finishes.
4. Verify. Load your site in a browser and confirm the change is live.

That is the entire cycle: push, Update from Remote, Deploy HEAD Commit. There is no file dragging and no risk of a half-finished upload, because the deploy either completes or it does not run.

07. Method B: Deploy Entirely Over SSH

If you would rather live in the terminal, you can do the whole thing over SSH without the cPanel interface. This is often faster once you are comfortable, and it is the only option for scripting deploys.

1. Connect. SSH into your account: ssh [email protected] -p 22. Adjust the port if we gave you a non-standard one.
2. Clone once. From your home directory, clone the repo into a directory above the web root:

   cd ~
   git clone [email protected]:youruser/yourrepo.git repositories/yoursite

3. Deploy the first time. Copy the files into public_html, either by running the same commands your .cpanel.yml uses or with a direct copy:

   cd ~/repositories/yoursite
   /bin/cp -R dist/. ~/public_html/

4. Update later. Each time you want to publish new commits, pull and copy again:

   cd ~/repositories/yoursite
   git pull
   /bin/cp -R dist/. ~/public_html/

You can wrap those last two commands in a one-line shell script in your home directory so a deploy is a single command. Combine that with a cron job and you have a hands-off pull-to-deploy pipeline.

08. Deploying a Built App (Node and Next)

Static sites and PHP apps deploy the files as they are. A Node app is different: what goes live is the built output, not your source and node_modules. You have two sane options.

For a framework like Next.js exported to static files, build locally, commit the out/ directory, and copy it live:

---
deployment:
  tasks:
    - export DEPLOYPATH=/home/youruser/public_html/
    - /bin/cp -R out/. DEPLOYPATH

09. Keep Secrets and node_modules Out of the Repo

A deployment repo should hold your code and nothing that is either huge or secret. Two files do most of the work here: a good .gitignore, and environment variables for anything sensitive.

A minimal .gitignore for a typical web project:

node_modules/
.env
.env.local
*.log
wp-config.php
/vendor/

• node_modules is rebuilt from package-lock.json with npm ci. Committing it bloats the repo and slows every clone. Ignore it.
• Secrets go in environment variables or an ignored .env file, never in tracked source. Load them at runtime rather than baking them into committed code.
• Config files with credentials such as wp-config.php stay out of the repo. Keep the live copy on the server and ignore it, or template a version without real values.

10. Common Issues

Deploy HEAD Commit does nothing. There is no .cpanel.yml in the repository root, or its YAML is invalid (usually a tab instead of spaces, or wrong indentation). Add a valid file at the root, commit, push, Update from Remote, then deploy again.

Files land in the wrong place or nothing appears on the site. The DEPLOYPATH in .cpanel.yml is wrong. Confirm your username and that the path is /home/youruser/public_html/ with a trailing slash, and that the cp source matches your actual build folder (dist/., out/., and so on).

Cloning a private repo fails with a permission or authentication error. The deploy key is missing or not attached to the repository. Re-check Section 04: the public key from cPanel must be added as a deploy key on your Git host, and the clone URL must use the SSH form (git@host:user/repo.git), not HTTPS.

Permission denied writing to public_html. The copy is trying to overwrite files owned by another process, or a directory has restrictive permissions. Standard cPanel deploys run as your account user, so make sure nothing under public_html is owned by a different user, and that directories are 755 and files 644.

The pull works over SSH but the cPanel interface looks out of date. They are reading the same clone, so refresh the Git Version Control page. If you truly cloned twice into two directories, delete the extra one and standardize on a single clone path.

The site shows old content after deploy. A caching layer is serving the previous version. Clear your application or CDN cache and hard-refresh the browser. For anything this guide does not cover, open a ticket and we will look at the account with you.

Quick Recap: Git Deployment in Six Steps

If you only do six things from this guide, do these:

1. Enable SSH access on your account so private repos and terminal deploys work.
2. Clone the repository outside the web root, into something like repositories/yoursite, using Git Version Control or the SSH terminal.
3. Add a read-only deploy key from cPanel to your Git host if the repository is private.
4. Commit a valid .cpanel.yml at the repo root that copies your files or build output into public_html.
5. Push, then Update from Remote and Deploy HEAD Commit (or git pull and copy over SSH) to publish.
6. Keep secrets and node_modules out of the repo with a good .gitignore and environment variables.

Last updated July 2026 · Browse all Getting Started articles