Deploying to cPanel from GitHub Actions: Automated CI/CD for Shared Hosting

Moving from "upload over FTP when I remember" to "every push to main deploys itself" is one of the best upgrades a small development team can make. This guide builds a GitHub Actions pipeline that tests your code, builds it on GitHub's own machines and ships the finished files to a cPanel or DirectAdmin shared hosting account, with an FTPS route for accounts without SSH.

1. What the pipeline does

When you push to main:

Rolling back means pointing the site at the previous release folder again.

2. Choose your deployment route

3. One-time setup: SSH access and a deploy key

Jailed SSH access is available on every shared hosting plan (cPanel, DirectAdmin, Webuzo). It is off by default; ask support to enable it for your account through live chat or a ticket. Windows (Plesk) hosting has no SSH, so use the FTPS route in section 7 there.

Login is key-only: password authentication is switched off on our cPanel and DirectAdmin servers, and SSH uses port 22. Create a separate key just for GitHub, so you can remove it later without touching your own key:

ssh-keygen -t ed25519 -f ~/.ssh/github-deploy -C "github-actions-deploy" -N ""

A deploy key has no passphrase, because CI can't type one. Protect it by keeping it only in GitHub Secrets.

Your username, server IP and panel address are in the client area: open My Hosting, click Manage and open the Access tab. Full SSH instructions are in Enabling and accessing jailed SSH.

4. Prepare the folders on the server

Over SSH, create a layout that keeps releases, shared files and the live pointer apart:

~/app/
  releases/20260924-1030-a1b2c3d/
  shared/.env
  shared/storage/
  current -> releases/20260924-1030-a1b2c3d

Put your production .env in ~/app/shared/ by hand, once. It never goes through GitHub.

The website must be served from ~/app/current/public. For an addon domain or subdomain, you can set the document root when you create it in your control panel. For your main domain, ask support before you change anything, and never delete public_html yourself. Test the whole pipeline on a subdomain first.

5. The workflow file

Save this as .github/workflows/deploy.yml. It is written for a Laravel app; section 8 shows what to change for other stacks.

name: Deploy to shared hosting

on:
  push:
    branches: [main]
  workflow_dispatch:

concurrency: production-deploy

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          tools: composer
      - run: composer install --prefer-dist --no-interaction --no-progress
      - run: php artisan test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          tools: composer
      - run: composer install --no-dev --optimize-autoloader --no-interaction
      - uses: actions/setup-node@v5
        with:
          node-version: '22'
          cache: npm
      - run: npm ci && npm run build

      - name: Pack the release
        run: tar --exclude-from=.deployignore -czf /tmp/release.tgz .

      - name: Upload and activate
        env:
          SSH_KEY: ${{ secrets.SSH_KEY }}
          SSH_KNOWN_HOSTS: ${{ secrets.SSH_KNOWN_HOSTS }}
          TARGET: ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }}
        run: |
          install -m 700 -d ~/.ssh
          printf '%s\n' "$SSH_KEY" > ~/.ssh/deploy && chmod 600 ~/.ssh/deploy
          printf '%s\n' "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
          RELEASE="$(date -u +%Y%m%d-%H%M)-${GITHUB_SHA::7}"
          scp -i ~/.ssh/deploy -P 22 /tmp/release.tgz "$TARGET:app/release.tgz"
          ssh -i ~/.ssh/deploy -p 22 "$TARGET" "bash -s" -- "$RELEASE" < deploy/activate.sh

Set php-version to the version your hosting account uses. You choose it in your control panel; check there for the versions available.

A .deployignore file in the project root keeps secrets and clutter out of the archive:

./.git
./.github
./node_modules
./tests
./.env
./storage

6. The activation script

Commit this as deploy/activate.sh. It runs on the server, inside your jailed shell:

#!/bin/bash
set -euo pipefail
RELEASE="$1"
APP="$HOME/app"
NEW="$APP/releases/$RELEASE"

mkdir -p "$NEW"
tar -xzf "$APP/release.tgz" -C "$NEW"
rm -f "$APP/release.tgz"
ln -sfn "$APP/shared/.env" "$NEW/.env"
ln -sfn "$APP/shared/storage" "$NEW/storage"

cd "$NEW"
php artisan migrate --force
php artisan optimize

# switch the live pointer in one step
ln -sfn "$NEW" "$APP/current.tmp"
mv -T "$APP/current.tmp" "$APP/current"

# keep the five newest releases
cd "$APP/releases" && ls -1t | tail -n +6 | xargs -r rm -rf

To roll back, SSH in and point current at the previous folder the same way. Migrations are not undone by a rollback, so take a database export before any migration that changes an existing table.

7. No SSH? Deploy over FTPS instead

For a static site, a theme or a simple PHP site, you can skip SSH and let an FTP deploy action upload the built files. Use FTP with explicit TLS on port 21, which works on every Domain India hosting account, and store the FTP login as secrets. Never use plain FTP.

      - name: Upload over FTPS
        uses: SamKirkland/[email protected]
        with:
          server: ${{ secrets.FTP_HOST }}
          username: ${{ secrets.FTP_USER }}
          password: ${{ secrets.FTP_PASSWORD }}
          protocol: ftps
          port: 21
          local-dir: ./dist/
          server-dir: public_html/

Use the server hostname from your Access tab as FTP_HOST, so that the certificate name matches. Create a separate FTP account for CI in your control panel, limited to the folder it deploys to. This route cannot run migrations or other commands, so database changes are done by hand. See How to use FTP with SSL/TLS.

8. Other stacks

• Static sites and single-page apps: skip PHP entirely, run npm run build and deploy the dist/ or build/ folder, usually over FTPS.
• WordPress: deploy your own theme or plugin folder, not the whole site. Content lives in the database, so don't overwrite wp-content/uploads.
• Node.js apps: a small app can run through Setup Node.js App on cPanel; see deploying a Node.js app on shared hosting. For anything larger, the App Platform runs it for you and deploys from CI with a deploy token.

9. Troubleshooting

10. Where this fits on Domain India

Our cPanel and DirectAdmin shared hosting plans suit PHP applications that you build in CI and deploy as finished files, with jailed SSH enabled on request.

Prices on the cards are live and exclude 18% GST. If your app needs a long-running process, WebSockets, Redis or root access, a VPS is the better home; the same workflow idea applies there, with fewer limits.

Ready to automate your deploys? Ask for jailed SSH through a support ticket, compare cPanel hosting and DirectAdmin hosting, or use the App Platform for container deploys from CI.