Auto-deploy to a Hostinger VPS with GitHub Actions (push to deploy)

How it fits together

The simplest reliable setup has GitHub do nothing clever. On every push to `main`, a workflow opens an SSH connection to your VPS and runs the deploy script that already lives there. The server pulls the code, builds and restarts. If the script works when you run it by hand, it works from CI.

This guide assumes you have a working `deploy.sh`, like the one at the end of our Next.js guide. The same pattern works for Laravel, Django or anything else; only the script changes.

• The Next.js deploy guide, with deploy.sh →

Step 1 — Make a key just for CI

Never reuse your personal SSH key. Make a separate one with no passphrase, so you can revoke CI access without touching your own login.

ssh-keygen -t ed25519 -N "" -C "github-actions" -f ./gha_deploy
# gha_deploy      -> private key, goes into a GitHub secret
# gha_deploy.pub  -> public key, goes onto the server

Step 2 — Allow the key to run one command only

Add the public key to the deploy user's `authorized_keys` with a forced command. Whatever the client asks for, the server runs only `deploy.sh`. If the private key ever leaks, the worst anyone can do is trigger a deploy of your own code.

nano ~/.ssh/authorized_keys

command="/var/www/myapp/deploy.sh",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAA...your-public-key... github-actions

Step 3 — Store the secrets in GitHub

In the repository, open Settings → Secrets and variables → Actions and add three secrets. Pinning the host key matters: without it, the workflow would trust whatever machine answers on that IP.

ssh-keyscan -t ed25519 YOUR_SERVER_IP

Step 4 — The workflow

Commit this file. `concurrency` queues deploys so two quick pushes can't build on top of each other.

name: Deploy

on:
  push:
    branches: [main]
  workflow_dispatch:

concurrency:
  group: production
  cancel-in-progress: false

jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - name: Configure SSH
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_KEY }}" > ~/.ssh/id_ed25519
          chmod 600 ~/.ssh/id_ed25519
          echo "${{ secrets.SSH_KNOWN_HOSTS }}" > ~/.ssh/known_hosts

      - name: Deploy
        run: ssh deploy@${{ secrets.SSH_HOST }}

Step 5 — Make failures visible

Because `deploy.sh` starts with `set -euo pipefail`, a failed build exits non-zero, the SSH command fails, and the workflow goes red. GitHub emails you, and the live app keeps running the previous build because PM2 was never restarted.

• •Run tests in an earlier job and add `needs: test` to the deploy job, so broken code never reaches the server.
• •Keep the build on the server only while builds are quick. If they start eating the VPS's CPU while it serves traffic, build in Actions and rsync the output instead.
• •Add a protected environment in GitHub if you want a manual approval before production deploys.

Troubleshooting

The errors you're most likely to see, and what they mean: