When I push a change to my theme on GitHub, it goes live on my Hostinger site on its own. Getting there on a cheap plan took two days, three workarounds, and one decision I later reversed for security.
In short:
- GitHub Actions builds the theme and copies it to Hostinger over FTP on every push to
main. - Hostinger blocks FTP from GitHub’s own servers, so the job runs on my Mac instead.
- I now start that runner by hand, because leaving it on all the time was a security risk.
Why not use Hostinger’s own GitHub connection?
Hostinger has a “Connect with GitHub” option in hPanel. It copies the repository straight onto the server, and that’s all it does.
My theme has custom blocks written in React, and those need a build step: a command that turns the source code into files WordPress can actually run. Hostinger’s connection has no build step, so the unbuilt code would land on the server and the blocks wouldn’t work. It only suits themes with nothing to compile.
What GitHub Actions does
GitHub Actions runs a list of steps for you whenever something happens in a repository. The list is a short text file in the repo, called a workflow. Mine says: every time something is pushed to main,
- get a fresh copy of the code,
- install what the build needs,
- build the theme,
- upload the built theme to Hostinger over FTP.
The FTP login is stored in GitHub as secrets: encrypted values the workflow can use but nobody can read back, and never part of the code. Claude wrote the workflow, and I typed the secrets in myself. A password shouldn’t go through a chat.
Some things never reach the server: the source code, the build tools, the design files and the rules file for Claude. The workflow leaves them out of the upload.
The day it didn’t work
Claude and I wrote the workflow on 14 September. The first run failed.
Hostinger blocks FTP from GitHub’s servers. GitHub runs each job on a machine in a big data centre, and Hostinger refuses FTP connections from data centre addresses. The upload simply couldn’t connect.
The fix was a self-hosted runner: GitHub’s job-running program, installed on my Mac. GitHub still decides when a job runs, but the work happens on my laptop, from my home internet connection, which Hostinger accepts. That went in on 16 September.
Two more snags followed the same evening:
- File ownership. I’d made a separate FTP account that could only reach the themes folder, which is the safer setup. Files it uploaded belonged to that account, and WordPress couldn’t read them. I switched to the main FTP account.
- The path. The main account starts at a different folder, so the upload path had to change to the full one:
/domains/inesmedem.com/public_html/wp-content/themes/inesmedem/.
There was also an FTP hostname that didn’t resolve, before any of this. None of these problems were hard, but each one cost a failed run before it showed up.
Why I now start the runner by hand
For about seven weeks the runner ran in the background all the time. On 4 November I turned that off.
The runner runs as me, on my work laptop, with access to my files and my other projects. If someone broke into my GitHub account, an always-on runner would let them run code on my laptop too. That trade wasn’t worth it for a personal site.
So now a push waits in a queue, and GitHub shows the runner as offline. When I want the change live, I start the runner, watch the job finish in the Actions tab, and stop it. The steps are in my theme’s rules file, so Claude reminds me after every push.
What I’d do differently
The cheapest plan made automation harder in every step. Before picking a host, I’d check two things:
- SSH. A way to log in to the server and run commands. With it, a deploy can use a safer, encrypted copy and doesn’t need FTP at all.
- A Git deploy that can take a built branch. GitHub’s own servers could build the theme and push the result to a separate branch, and the host would pull that branch.
My hosting renews on 21 December, so I need to pick one of those before then: try Hostinger’s Git deploy with a built branch, move to a plan with SSH, or run the runner as a separate, limited user on my Mac.
Skills I used
These are the skills I used for this part. A skill is a set of written steps Claude follows when a job comes up.
wordpress-git-deploy: sets up deploying a theme from GitHub to Hostinger, using GitHub Actions and FTP.
Next in the series: designing pages with Claude Design, and keeping the designs next to the code.
