Automated Deployment to Hostinger with GitHub Actions

After setting up my static website generator, I wanted to automate the deployment process to my Hostinger hosting. Here’s how I did it using GitHub Actions and FTP deployment.

Prerequisites

• A GitHub repository for your website
• A Hostinger hosting account
• Basic knowledge of GitHub Actions

Setting up FTP Access

First, we need to create FTP credentials in Hostinger:

1. Log in to your Hostinger control panel
2. Go to “Files” > “FTP Accounts”
3. Create a new FTP account or use the existing one
4. Note down the following information:
   • FTP hostname
   • FTP username
   • FTP password

GitHub Repository Setup

1. Add your FTP credentials as secrets in your GitHub repository:
   • Go to your repository settings
   • Navigate to “Secrets and variables” > “Actions”
   • Add the following secrets:
     • FTP_HOST: Your Hostinger FTP hostname
     • FTP_USERNAME: Your FTP username
     • FTP_PASSWORD: Your FTP password
2. Create the GitHub Actions workflow file:

name: Deploy to Hostinger

on:
  push:
    branches:
      - main  # or your default branch name

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Install dependencies
        run: |
          sudo apt-get update
          sudo apt-get install -y pandoc
      
      - name: Build site
        run: |
          chmod +x convert.sh
          ./convert.sh
      
      - name: 📂 Deploy to Hostinger
        uses: SamKirkland/FTP-Deploy-Action@v4.3.4
        with:
          server: ${{ secrets.FTP_HOST }}
          username: ${{ secrets.FTP_USERNAME }}
          password: ${{ secrets.FTP_PASSWORD }}
          local-dir: ./public/
          server-dir: public_html/
          dangerous-clean-slate: true # This will delete files on the server that don't exist locally

Save this file as .github/workflows/deploy.yml in your repository.

How it Works

Every time you push changes to your main branch, GitHub Actions will:

1. Set up a fresh Ubuntu environment
2. Install pandoc (required for our static site generator)
3. Run our convert.sh script to build the site
4. Upload the contents of the public/ directory to Hostinger’s public_html/ directory

The dangerous-clean-slate option ensures that your server directory exactly matches your local build by removing any files that don’t exist locally.

Testing the Deployment

1. Make a change to any of your markdown files
2. Commit and push to GitHub:

git add .
git commit -m "Update content"
git push

3. Go to your repository’s “Actions” tab to watch the deployment progress
4. Once completed, check your website to see the changes

Return to basics

I found this approach too complicated for a simple website, for example I don’t see the point in spinning up a new Ubuntu machine just to install pandoc and build the website. I ended up using a simple deploy.sh script that uploads the public/ directory to the public_html/ directory.

#!/bin/bash

# Load environment variables from .env
source .env

# Build the site
./convert.sh

# Upload using lftp
lftp -c "
set ssl:verify-certificate no
set ftp:ssl-allow no
set mirror:parallel-directories true
set mirror:parallel-transfer-count 10
set mirror:use-pget-n 10
open ftp://$FTP_USER:$FTP_PASS@$FTP_HOST
mirror -R --parallel=10 --delete public/ /
bye
"

echo "🚀 Deployment complete!" 

Save this file as deploy.sh and give it execute permissions:

chmod +x deploy.sh

Now you can deploy your website with:

./deploy.sh

Another lightweight solution

Using the same FTP-Deploy-Action, but without the build step, we can create a simpler workflow:

name: Deploy to Hostinger

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: SamKirkland/FTP-Deploy-Action@v4.3.4
        with:
          server: ${{ secrets.FTP_HOST }}
          username: ${{ secrets.FTP_USERNAME }}
          password: ${{ secrets.FTP_PASSWORD }}
          local-dir: ./public/
          server-dir: /
          dangerous-clean-slate: true

Conclusion

With this setup, we’ve automated our deployment process. No more manual FTP uploads or running build scripts locally. Every push to the main branch automatically triggers a build and deployment to our Hostinger hosting.

This not only saves time but also reduces the chance of human error in the deployment process. Plus, having our website in version control gives us a complete history of changes and makes collaboration easier.

In the end, I went back to the simple deploy.sh script because it caused less overhead and was easier to maintain. If you do that, you need to disable the GitHub Actions workflow.

Update: I ended up using the lightweight action solution for my website.