Welcome to the NZRT Wiki Podcast. Today we’re looking at Git Deployment — cPanel.

If you’re working with NZRT’s hosting setup on Hoopla — that’s our cPanel server — you’ll want to know how code gets from GitHub onto the server. There are a few ways cPanel supports this. You can connect via SSH and run git commands directly on the server. You can clone private GitHub repositories using a deploy key. And there’s also an optional graphical interface inside cPanel called Git Version Control. But the primary method NZRT uses is GitHub Actions — an automated workflow that SSHes into cPanel and runs a git pull whenever code is pushed to the main branch.

Before we get into the automation, let’s talk about what’s actually being deployed. There’s one main repository deployed to the cPanel server: it’s called NZRT-Scripts, and it lives in a folder called scripts inside the server’s home directory. This repo contains scripts for deployment, backups, health checks, and a product sync script. Worth noting — WordPress itself isn’t git-deployed. That’s handled separately via WP-CLI and WebDAV. And Dolibarr doesn’t live on cPanel at all.

So let’s say you’re setting this up for the first time. You SSH into the server, then clone the NZRT-Scripts repository from GitHub into that scripts folder. After that, you verify it worked by checking the last few commit messages in the git log. Because the repo is private, the server needs a way to authenticate with GitHub. You do this with a deploy key. You generate a new SSH key pair on the server specifically for deployment, then take the public half of that key pair and add it to the repository’s settings on GitHub, under Deploy Keys, set to read-only. Finally, you add a small configuration entry on the server that tells SSH to use that deploy key whenever it connects to GitHub.

There’s also an optional GUI path through cPanel itself. You go to Files, then Git Version Control, and create a new entry pointing to your scripts folder and the GitHub clone URL. This gives you a dashboard to pull updates and check repo status. It also enables a special deployment configuration file you place in the root of your repository. When cPanel pulls new code through its Git Version Control interface, it automatically runs whatever tasks are listed in that file. In NZRT’s case, it runs a post-deploy shell script that flushes the WordPress cache, fixes file permissions on any shell scripts so they’re executable, and logs the date and time the deployment finished.

Now for the main event — the GitHub Actions workflow. This is triggered whenever someone pushes to the main branch of NZRT-Scripts. When that happens, GitHub spins up a temporary Linux environment and runs a series of steps. It sets up an SSH connection by writing the private deploy key to a file, locking down its permissions, and adding the server to a list of trusted hosts. Then it SSHes into the cPanel server, navigates to the scripts folder, pulls the latest code from main, and makes sure all shell scripts are executable. After a short pause, it runs a health check by SSHing back in and printing the most recent commit — just to confirm the deployment landed.

To make all this work, you need three secrets stored at the GitHub organisation level so they’re available across all repos. You need the SSH private key, the cPanel username, and the SSH port number. Set these once and they’re inherited automatically by any workflow that needs them.

Once your scripts are live on the server, you wire them up to cPanel’s cron job scheduler. You find that under Advanced, then Cron Jobs. There are three jobs configured. The first is a daily backup that runs at two in the morning, covering the database and file backups. The second is a health check that runs every fifteen minutes. The third is an hourly sync — a Python script that keeps WordPress products and Dolibarr in alignment.

Finally, how do you verify everything is working end to end? You can SSH in and check the git log to confirm the latest commits are present on the server. You can manually trigger one of the scripts to test it in isolation. And for the full end-to-end test, you push a commit to the main branch, watch the GitHub Actions run complete successfully, and then confirm that same commit appears in the server’s git log.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.