Building a website is one project. Keeping it dependable after the excitement wears off is another.
I wanted TedJohnsonWorks.com to be something I could keep improving without turning every change into a production-night event. The goal was not zero maintenance. The goal was a workflow simple enough that I could understand what happened when something went wrong.
GitHub is the source of truth.
The approved site lives in the main branch. That matters because I do not want several different copies of the website quietly becoming “the real one.”
If a change is not in the approved source, I do not want to treat it as permanent production work.
The live site gets a separate deployment branch.
Hostinger watches a dedicated hostinger branch. A GitHub Actions workflow takes approved work from main and prepares the production branch for hosting.
Approved source on main → GitHub Actions → hostinger production branch → Hostinger auto-deploy → live site.
That separation gives me two useful things at once: a clean source branch for the work, and a production branch that contains what the host actually needs.
Do not “fix” the wrong layer.
One of the easiest mistakes in technology is to see a broken result and start changing everything around it. Hosting settings, DNS, deployment configuration, file locations — suddenly a small problem becomes four problems.
When the site stopped receiving new changes, the hosting connection itself was not the thing that needed rebuilding. The missing piece was the GitHub-side bridge feeding the production branch. Fix the failed layer, verify the path, and leave the pieces that are already working alone.
Production secrets stay out of the public site.
Mail credentials and other private configuration do not belong in a public repository or public web directory. The public site can call the server-side pieces it needs without exposing the private configuration that makes them work.
This is not glamorous. It is simply good housekeeping — and good housekeeping is what keeps a small system from turning into a mess later.
Verification beats assumption.
After a deployment I want evidence: the production branch advanced, Hostinger received the new commit, and the public page shows the intended change after a refresh.
A green light in one place is useful. Following the change all the way to the live site is better.
The broader lesson is K.I.S.S.
I spent decades around technology. The systems that survive are not always the fanciest ones. They are the ones somebody can still understand six months later.
- One approved source.
- One predictable deployment path.
- Private configuration kept private.
- Change the layer that is actually broken.
- Verify the result where the customer sees it.
That is enough sophistication for a site like mine. The technology is supposed to support the work — not become the work.
PRACTICAL TECHNOLOGY
Need one technology problem made clearer?
I offer a focused Technology Clarity Call, and Ted’s Picks is where I keep tools and services that have earned an honest recommendation.