Skip to main content

Automating Hostinger Deployments with GitHub Actions & Webhooks

 Manually uploading files via FTP (File Transfer Protocol) is a workflow bottleneck that introduces significant risk. Dragging and dropping folders leads to missed files, overwritten configurations, and zero accountability regarding what changed and when.

While Hostinger provides a native "Git" feature in its hPanel, it is passively configured by default. It allows you to connect a repository, but it does not automatically synchronize changes when you push code to GitHub. You are left manually clicking "Deploy" in the dashboard, which defeats the purpose of Continuous Deployment (CD).

This guide details how to bridge that gap using GitHub Webhooks and GitHub Actions to create a fully automated deployment pipeline.

The Root Cause: Why Automatic Deployment Fails

To understand the fix, we must understand the architecture of shared hosting environments.

When you push code to GitHub, the transaction happens strictly between your local machine and GitHub’s servers. Your Hostinger server is a third party; it is completely unaware that a push event occurred.

Hostinger's Git implementation works on a Pull Model. The server waits for a command to fetch changes. It does not maintain a persistent socket connection to GitHub to listen for updates.

To automate this, we must convert the workflow into a Push-Trigger Model. We need GitHub to explicitly notify Hostinger that a change has occurred. We achieve this via a Webhook—an HTTP POST request sent from GitHub to a specific endpoint on your Hostinger server, instructing it to execute git pull.

Step 1: Configure Access Control (Deploy Keys)

Before automating the trigger, we must ensure the Hostinger server has permission to read your private GitHub repository without using your personal password. We use SSH Deploy Keys for this.

  1. Log in to Hostinger hPanel.
  2. Navigate to Advanced > Git.
  3. Enter your Repository details (e.g., user/repo-name) and the Branch name (usually main).
  4. Leave the password field empty.
  5. Click Create Repository.

Hostinger will fail to connect initially but will generate an SSH Key.

  1. Copy the SSH Public Key displayed in the Hostinger modal.
  2. Go to your GitHub Repository > Settings > Deploy keys.
  3. Click Add deploy key.
  4. Paste the key, give it a title (e.g., "Hostinger Production"), and ensure "Allow write access" is unchecked.
  5. Save the key.

Back in Hostinger, retry the connection. It should now succeed, and your repository files will be cloned to your server.

Step 2: Acquire the Webhook URL

Once the repository is connected in hPanel, Hostinger exposes a unique URL designed to trigger the deployment script.

  1. In the Advanced > Git section of hPanel, look at your connected repository settings.
  2. Locate the "Auto Deployment" or "Webhook URL" section.
  3. Copy this URL. It will look similar to: https://api.hostinger.com/git/webhook?token=YOUR_UNIQUE_TOKEN&id=YOUR_DEPLOYMENT_ID

Step 3: Implement the Deployment Pipeline

We have two ways to implement the trigger: a direct Webhook or a GitHub Action.

While a direct Webhook is simpler, GitHub Actions are superior because they allow you to add logic (e.g., "Only deploy if tests pass" or "Only deploy if the linter succeeds").

Option A: The Direct Webhook (Fastest)

  1. Go to GitHub Repository > Settings > Webhooks.
  2. Click Add webhook.
  3. Payload URL: Paste the Hostinger URL from Step 2.
  4. Content type: application/json.
  5. Secret: Leave blank (the token is in the URL).
  6. Which events? Select "Just the push event".
  7. Click Add webhook.

Result: Every push to the repo triggers the URL.

Option B: The GitHub Action (Recommended for Stability)

This method ensures deployment only happens within a controlled CI/CD environment.

Create a file in your repository at .github/workflows/deploy.yml.

name: Production Deployment

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Run Tests (Optional)
        run: |
          # Add your test command here, e.g., npm test
          echo "Tests passed - proceeding to deploy"

      - name: Trigger Hostinger Deploy
        run: |
          # Use curl to hit the Hostinger Webhook
          # flags: -s (silent), -o (output to /dev/null), -w (write out HTTP code)
          HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" "${{ secrets.HOSTINGER_WEBHOOK_URL }}")

          if [ "$HTTP_STATUS" -ne 200 ]; then
            echo "Deployment failed with HTTP status: $HTTP_STATUS"
            exit 1
          fi
          echo "Deployment triggered successfully."

Security Note: Do not hardcode the Webhook URL in your YAML file.

  1. Go to GitHub Repo > Settings > Secrets and variables > Actions.
  2. Create a New repository secret named HOSTINGER_WEBHOOK_URL.
  3. Paste your Hostinger URL there.

Deep Dive: What Happens Under the Hood?

When the Action runs, the curl command sends a request to Hostinger's API. Here is the sequence of events on the server side:

  1. Authentication: Hostinger validates the token and id query parameters from the URL.
  2. Context Switching: The server switches context to the directory where your repository is initialized.
  3. Git Fetch: The server executes git fetch origin main to retrieve the latest commit hashes without merging them yet.
  4. Git Reset/Pull: Typically, Hostinger performs a git reset --hard origin/main. This is crucial to understand—it forces the server files to match the repository exactly, discarding any local changes made directly on the server (a best practice for immutability).

Common Pitfalls and Edge Cases

1. The "Build Step" Problem

The most common failure point for React, Vue, or modern PHP developers is assuming git pull is enough.

  • The Issue: Your repository (correctly) ignores node_modules and build/ or dist/ folders via .gitignore.

  • The Result: Hostinger pulls the source code (JSX/TS files), but since shared hosting environments rarely have Node.js or build tools installed/configured automatically, your site breaks or serves raw source code.

  • The Fix:

    • For PHP/Laravel: You must log in via SSH and run composer install manually, or set up a cron job to check for changes.
    • For React/Static: Do not use the Git feature for deployment. Instead, use a GitHub Action to build the project inside the runner, and use FTPS or rsync to upload the dist folder content only.

2. Permission Denied (publickey)

If the deployment fails with permission errors, check the ownership of the files on Hostinger.

  • Fix: SSH into your server and ensure the .git folder is owned by your user, not root.
    chown -R user:group public_html/.git

3. Divergent Branches

If someone modified a file directly on the Hostinger File Manager, the remote git history will diverge from the local file system.

  • Fix: Hostinger's deployment usually handles this by forcing a reset, but if it fails, you must SSH in and run:
    git fetch --all
git reset --hard origin/main

Conclusion

Automating deployment to Hostinger transforms a fragile, manual FTP process into a robust CI/CD pipeline. By leveraging SSH Deploy Keys for security and GitHub Actions for orchestration, you ensure that your production environment is always a predictable reflection of your repository's main branch. This setup reduces deployment time from minutes to seconds and eliminates the risk of human error.

Labels: