Guide CyberPanel Git Deployment: Deploy from GitHub (and the Option That Deleted Our Site)

**JAY** · (This post was last modified: 10-28-2026, 04:59 AM by JAY.)

CyberPanel Git Deployment: Deploy from GitHub (and the Option That Deleted Our Site)

Deploying from Git means your website's files come from a repository (GitHub, GitLab, Bitbucket) instead of FTP uploads. You push a change, the server pulls it, done. CyberPanel has a Manage Git page for this. We tested it on our test subdomain

Code:

blog.cyber.adminslab.com

with a small public demo repo (

Code:

octocat/Spoon-Knife

on GitHub, three files:

Code:

index.html

,

Code:

styles.css

,

Code:

README.md

). It worked in the end, but one option deleted the whole site folder on the way. Read the warning in Step 2 before you click anything.

Step 1: Open Manage Git
Websites > List Websites > Manage (or List Child Domains > Manage for a subdomain), then Manage Git at the top. The address is

Code:

https://YOUR-SERVER-IP:8090/websites/yourdomain.com/manageGIT

.

Pick the folder (for us

Code:

/home/cyber.adminslab.com/blog

, the subdomain's document root). Without a repository in it you get two buttons: Init Repo (start a new, empty repo here) and Attach Existing Repo (clone one from GitHub/GitLab). We wanted the second.

Step 2: Attach Existing Repo, and what went wrong
The dialog asks for Git Host, Username (the repo owner) and Repo Name, and shows a Deployment Key (an SSH public key CyberPanel generates for the site user).
In the dialog we filled in github.com, the owner and the repo name, and clicked Attach:
[Image: attachment.php?aid=567]

First try:

Code:

fatal: destination path '/home/cyber.adminslab.com/blog' already exists and is not an empty directory.

The folder only had CyberPanel's default

Code:

index.html

, but Git can only clone into an empty folder.

With Override Data ticked we tried again:
[Image: attachment.php?aid=568]

Second try:

Code:

[email protected]: Permission denied (publickey).

CyberPanel always clones over SSH (

Code:

[email protected]:owner/repo.git

), and GitHub only accepts SSH from a key it knows, even for a public repo. The deployment key in the dialog has to be added to the repository first (see Step 4).

And then we looked at the server:
[Image: attachment.php?aid=569]

The folder was gone. Override Data deleted the site's document root before cloning; the clone then failed, and nothing was put back. The subdomain answered 404 until we fixed it.

So, before you use Attach Existing Repo:

Add the deployment key to the repo first (Step 4), so the clone actually succeeds.
Take a backup of the folder, or better, don't tick Override Data at all. Move the old files away yourself.
Never try this on the main document root of a live site without a backup (CyberPanel backups).

Step 3: The simple way that worked: git clone over HTTPS
For a public repo you don't need any key: clone over HTTPS from SSH. The target folder must not exist yet (or be empty), so move the old document root away first:

Code:

cd /home/yourdomain.com
mv public_html public_html.old
sudo -u SITEUSER git clone https://github.com/owner/repo.git public_html

Run it as the site user (

Code:

sudo -u SITEUSER

, ours is

Code:

cyber2602

), not as root. Then the files belong to the site user and OpenLiteSpeed can serve them without a permission fix.
As the site user, from the parent folder of the document root:
[Image: attachment.php?aid=570]

The site came back right away with the repo's

Code:

index.html

(

Code:

<title>Spoon-Knife</title>

).

Two things we checked afterwards:

Is
Code:
.git
reachable from the web? No:
Code:
/.git/config
and
Code:
/.git/HEAD
answered 403,
Code:
/README.md
200. The 403 came from OpenLiteSpeed itself, not from our ModSecurity rules (nothing in the audit log). Test your own site anyway:
Code:
curl -I https://yourdomain.com/.git/config
must not return 200. An exposed
Code:
.git
folder gives away your whole source code.
Root can't use the repo. Running
Code:
git log
as root in the site user's repo gave
Code:
fatal: detected dubious ownership in repository
. That's a Git safety check. Don't "fix" it with
Code:
safe.directory
; just always run Git as the site user.

Step 4: Private repositories: the deploy key
For a private repo, HTTPS needs a token. The cleaner way is the deploy key CyberPanel already made. It's the site user's SSH key:

Code:

cat /home/yourdomain.com/.ssh/SITEUSER.pub

(on our server

Code:

/home/cyber.adminslab.com/.ssh/cyber2602.pub

, created the moment we opened the Attach dialog). On GitHub open the repository's Settings > Deploy keys > Add deploy key, paste it, and leave Allow write access off. A deploy key gives access to that one repository only, read-only, which is exactly what a web server needs. After that, Attach Existing Repo or a clone over SSH as the site user works:

Code:

sudo -u SITEUSER git clone [email protected]:owner/private-repo.git public_html

(We tested with a public repo and didn't add the key to a GitHub account, so we saw the "Permission denied" side of this, not the success.)

Step 5: Deploy updates
Once the folder is a Git repo, Manage Git recognises it no matter how it was cloned: our HTTPS clone showed up with its 3 commits and the buttons Pull, Push, Commit, Create New Branch, Edit .gitignore, Git Logs and Remove.

To test an update we pushed a new commit with one new file,

Code:

hello.txt

.
Then Pull in Manage Git:
[Image: attachment.php?aid=571]

Changes applied: a fast-forward to the new commit. On the server the new file belonged to the site user (

Code:

-rw-r--r-- cyber2602 cyber2602 hello.txt

), so the panel runs the pull as the site user, not as root. The file was live at once.

One oddity: when there's nothing new, the panel shows it as a failure:
[Image: attachment.php?aid=572]

Operation Failed! Pull not required. with

Code:

Already up to date.

underneath. Nothing is wrong; there was just nothing to pull.

From SSH the same update is one line:

Code:

cd /home/yourdomain.com/public_html && sudo -u SITEUSER git pull --ff-only

Code:

--ff-only

refuses to merge if someone edited files on the server, instead of creating a mess. If you want updates to arrive on their own, you can put that line in the site user's crontab (cron guide), for example every 5 minutes. For PHP projects, run your build steps after the pull (

Code:

composer install --no-dev

,

Code:

php artisan migrate --force

for Laravel).

Good habits

Keep secrets out of the repo:
Code:
.env
,
Code:
wp-config.php
and uploads belong in
Code:
.gitignore
, and stay only on the server.
Don't edit files on the server in a deployed folder. The next pull will refuse or overwrite them. Change the repo instead.
For a framework with a
Code:
public/
folder, clone the repo one level up and point the document root at
Code:
public
, like in our Laravel guide. Then
Code:
.git
,
Code:
.env
and the source code are outside the web root anyway.
Test a deployment on a subdomain or a staging copy first.

More CyberPanel guides

Tested on CyberPanel 3.0 (build 8, OpenLiteSpeed edition) on Ubuntu 24.04, October 2026. Menu names can change slightly between versions.

Possibly Related Threads…matched by title
Guide Switch CyberPanel to LiteSpeed Enterprise: Free Trial, Results and What Breaks JAY	Replies:0Views:7	23 minutes agoJAY
Guide How to Change a Website's Domain in CyberPanel (Files, WordPress, 301) JAY	Replies:0Views:13	1 hour agoJAY
Guide CyberPanel Website Logs: Why PHP Errors Are Missing and How to See Them (Tested) JAY	Replies:0Views:16	8 hours agoJAY
Guide CyberPanel LiteSpeed and PHP Tuning: What Each Setting Does (and a Bug) JAY	Replies:0Views:13	Today, 07:05 AMJAY
Guide CyberPanel Behind Cloudflare: Real Visitor IPs and the Setting That Allows Fake IPs JAY	Replies:0Views:103	10-26-2026, 06:48 PMJAY

Guide CyberPanel Git Deployment: Deploy from GitHub (and the Option That Deleted Our Site)

Attached Files