Set Up Git Auto-Deployment for WordPress in Hostinger

Uploading theme updates over SFTP or dragging ZIP files into hPanel is slow, messy, and one accidental overwrite away from breaking your live site. Hooking up Git auto-deployment lets you type git push origin main from your local terminal and see your changes live on Hostinger in a couple of seconds.

I set this up across four client production sites on Hostinger’s Business plan last month. The built-in Git deployment tool in hPanel works fine once it is running, but if you point it at the wrong directory or botch your SSH key permissions, it fails silently or wipes out your assets. Here is the exact setup process I use to get it working cleanly.

The Deployment Strategy: Theme Directory vs Entire WordPress Root

Do not point your Git repository at public_html. That is the single biggest trap developers hit on shared and cloud hosting.

Tracking public_html means Git tries to track core files, your wp-config.php, random plugins updated from the dashboard, and whatever files your client uploaded to wp-content/uploads/. You’ll run into merge conflicts every single time WordPress runs a background update or someone uploads a media file.

Instead, scope your repository strictly to the folder where you actually write custom code:

• Custom theme or child theme: public_html/wp-content/themes/your-theme-name
• Custom plugin: public_html/wp-content/plugins/your-plugin-name

If you’re already migrating an existing site to this architecture, check out our guide on how to migrate WordPress to Hostinger without downtime first so your production databases and files are stable before wiring up your repository.

Step 1: Prep Your Theme Repo and Configure .gitignore

Before touching hPanel, clean up your local repository. If you’re building a custom theme based on the WordPress Theme Developer Handbook, you likely have local build configs, node modules, and system clutter that have no business living on your production server.

Here is the .gitignore I drop into custom themes before initializing Git:

# OS files
.DS_Store
Thumbs.db # Node and build dependencies
node_modules/
npm-debug.log
yarn-error.log # Local environment and tooling
.env
.vscode/
.idea/
*.log # Bundler temp files
.cache/
.sass-cache/

Commit your clean theme files locally and verify your production branch is main:

git init
git add .
git commit -m "feat: initial clean theme commit"
git branch -M main
git remote add origin git@github.com:yourusername/custom-wp-theme.git
git push -u origin main

Push your repository to GitHub or GitLab. I’ll use GitHub here, but the exact same webhook mechanics apply to GitLab or Bitbucket.

Step 2: Generate and Add Deploy Keys in Hostinger

Hostinger needs read access to your GitHub repo. Don’t make the repo public just to dodge authentication—production themes usually have custom API endpoints or logic you don’t want exposed. You need an SSH deploy key.

Log in to hPanel, select your hosting plan, and search for SSH Access in the left sidebar. Make sure SSH is set to Enabled. Note down the SSH port, IP address, and username shown there.

Next, navigate to Advanced > Git in hPanel. You’ll see the repository configuration screen. Hostinger can generate a public SSH key for you, but I prefer generating a dedicated key via terminal so I know exactly where it lives:

ssh-keygen -t ed25519 -C "hpanel-deploy@hostinger" -f ~/.ssh/github_deploy

Hit Enter to accept an empty passphrase. Then print the public key:

cat ~/.ssh/github_deploy.pub

Copy the output string starting with ssh-ed25519. In your GitHub repository, open Settings > Deploy keys > Add deploy key. Paste the key, title it “Hostinger Production”, and leave “Allow write access” unchecked. Hostinger only ever needs read permissions to pull commits.

Step 3: Initialize the Repository Inside Hostinger hPanel

Head back to Advanced > Git in hPanel and fill out the fields:

1. Repository: Enter your SSH repo URL (like git@github.com:yourusername/custom-wp-theme.git). Don’t use HTTPS on private repos.
2. Branch: Enter main (or whatever release branch you use).
3. Install Path: This is where people trip up. hPanel automatically prepends public_html/. Don’t re-type it—just enter wp-content/themes/your-theme-name.

Here is what the path looks like on a standard WordPress setup:

# The final path on Hostinger's filesystem:
/home/u123456789/domains/yourdomain.com/public_html/wp-content/themes/custom-wp-theme

Click Create. Hostinger connects to GitHub, clones the repository into that destination folder, and lists the deployment under “Manage Repositories” at the bottom of the screen.

If you have subdomains on the same account, watch out for path routing issues. Misconfigured inheritance can trigger weird rewrite behavior; read our guide on how to fix root .htaccess inheritance on Hostinger subdomains if your staging setup clashes with your main domain.

Step 4: Wire Up the GitHub Webhook for Instant Push-to-Deploy

Right now, your deployment is manual. You’d have to log into hPanel and click “Deploy” every single time you push code. Let’s automate it.

Under Manage Repositories, find your newly linked theme. Look for the Auto Deployment Webhook column and copy your unique webhook URL:

https://cpanel.hostinger.com/api/git/deploy?id=123456&hash=a1b2c3d4e5f6g7h8

Copy that URL, then go to your GitHub repository:

1. Click Settings > Webhooks > Add webhook.
2. Paste your Hostinger deployment URL into Payload URL.
3. Set Content type to application/json.
4. Leave “Secret” blank (Hostinger validates the push using the query parameters in the URL itself).
5. Under “Which events would you like to trigger this webhook?”, select Just the push event.
6. Make sure Active is checked, then click Add webhook.

GitHub will fire a test ping immediately. If everything connected, you’ll see a green checkmark next to the webhook. For more details on payload responses, check the GitHub Webhooks documentation.

Step 5: Handle Build Steps for Modern Themes (Tailwind or Vite)

Hostinger’s native Git tool just runs a shallow fetch and pull. It does not run npm install, npm run build, or Composer commands on the server. If your theme uses Tailwind CSS, Vite, or TypeScript, pushing source files won’t generate your production bundles.

You have two ways to solve this:

Approach A: Commit Compiled Assets to the Theme

For solo devs or simpler setups, the fastest fix is removing your production build folder from .gitignore. Track dist/ or assets/css/style.min.css in Git. Run your build locally, commit the compiled files, and push:

npm run build
git add assets/dist/
git commit -m "chore: compile production assets"
git push origin main

The webhook fires, Hostinger pulls the commit, and your updated styles go live right away.

Approach B: Use a GitHub Action to Build and Ping Hostinger

If you don’t want compiled assets cluttering your Git history, let GitHub Actions compile everything and trigger the deploy. Here is a minimal workflow file to place in .github/workflows/deploy.yml:

{ "name": "Build and Trigger Hostinger Deploy", "on": { "push": { "branches": [ "main" ] } }, "jobs": { "build": { "runs-on": "ubuntu-latest", "steps": [ { "name": "Checkout", "uses": "actions/checkout@v4" }, { "name": "Set up Node", "uses": "actions/setup-node@v4", "with": { "node-version": "20" } }, { "name": "Install & Build", "run": "npm ci && npm run build" }, { "name": "Trigger Hostinger Webhook", "run": "curl -X POST '${{ secrets.HOSTINGER_WEBHOOK_URL }}'" } ] } }
}

Add your Hostinger webhook URL in GitHub under Settings > Secrets and variables > Actions as HOSTINGER_WEBHOOK_URL. That way, the deploy hook only fires after your CSS and JS build cleanly.

The Gotcha: Fixing Non-Empty Directory and Permission Errors

Here’s the error that caught me off guard the first time: Hostinger won’t clone into a folder that already exists on disk.

If you installed the theme earlier via the WordPress dashboard or uploaded a ZIP file, wp-content/themes/custom-wp-theme is already occupied. hPanel will throw this error:

fatal: destination path 'public_html/wp-content/themes/custom-wp-theme' already exists and is not an empty directory.

To fix this, log in over SSH or use hPanel’s File Manager to rename the folder before creating the Git repository:

cd ~/domains/yourdomain.com/public_html/wp-content/themes
mv custom-wp-theme custom-wp-theme-backup

Once renamed, head back to hPanel and click Create. It’ll clone cleanly. Afterwards, delete the temporary folder once you verify the theme works:

rm -rf custom-wp-theme-backup

Another common snag is file permissions. WordPress runs under the server’s web user, while SSH commands run under your specific account user. If Git creates files with locked-down permissions, WordPress won’t be able to read stylesheet headers. Ensure standard permissions across the theme:

find ~/domains/yourdomain.com/public_html/wp-content/themes/custom-wp-theme -type d -exec chmod 755 {} ;
find ~/domains/yourdomain.com/public_html/wp-content/themes/custom-wp-theme -type f -exec chmod 644 {} ;

Verifying Deploys and Testing Cache Purging

Let’s verify the pipeline end-to-end. Make an obvious, harmless CSS tweak locally:

/* Test Auto-Deployment */
body.logged-in { border-top: 3px solid #22c55e;
}

Commit and push the change to main:

git commit -am "test: verify auto deployment pipeline"
git push origin main

Go to your GitHub repository and check Settings > Webhooks. Click your Hostinger webhook and look at Recent Deliveries. You should see a 200 OK response code in well under a second.

If the delivery shows 200 OK but you don’t see the changes on your live site, LiteSpeed Cache is serving old assets.

Check your HTTP response headers directly in the terminal:

curl -I https://yourdomain.com/wp-content/themes/custom-wp-theme/style.css

Look for the x-litespeed-cache or cf-cache-status headers. If the file is cached, purge LiteSpeed Cache from the WordPress admin bar or bust the cache by tying your theme’s version string in functions.php to your Git commit hash via wp_enqueue_style().

For sites handling high traffic alongside frequent frontend deploys, pairing this with object caching keeps the database responsive. Follow our walkthrough to enable Redis Object Cache in Hostinger hPanel to avoid database bottlenecks while pushing updates.

Frequently Asked Questions

Can I deploy both a theme and a custom plugin via Git on the same site?

Yes. Hostinger lets you link multiple repositories to the same domain. Just configure the first repository with the path wp-content/themes/my-theme and the second with wp-content/plugins/my-plugin. Each repository gets its own unique webhook URL that you add to the respective GitHub repos.

What happens if someone edits a theme file directly in the WordPress Theme File Editor?

If someone edits a deployed file directly on the server, Git detects changes in the remote working tree. The next time your webhook triggers a git pull, the deploy will abort due to local modifications. Lock down the built-in file editor entirely by adding define( 'DISALLOW_FILE_EDIT', true ); to your wp-config.php file.

Can I roll back a broken deployment quickly?

Yes. Because the server is just running a standard Git repo under the hood, you can roll back right from your local machine. Run git revert HEAD, push to main, and GitHub fires the webhook to pull the reverted commit. You can also SSH into Hostinger and run git reset --hard HEAD~1 directly inside the theme directory.

Does Hostinger’s Git tool support Git LFS?

No. Hostinger’s shared hosting environment doesn’t include the Git Large File Storage (Git LFS) client. If you store heavy video files, PSDs, or large datasets in your repo using LFS, Hostinger will only download the small pointer text files instead of actual binaries. Keep large media files in cloud storage or upload them directly to the WordPress Media Library.

Next Steps

Your theme code is now under version control and automatically deploys the second you push to your default branch. To keep server background tasks from interfering with heavy deployment jobs or causing timeouts, learn how to replace WP-Cron with a Linux system cron on Hostinger next.