I started this week thinking of GitHub as a place to store code. I ended it realising it is infrastructure.

Over 48 hours of building a self-hosted scraping engine, deploying a portfolio site to AWS, and recovering from a broken WireGuard tunnel, GitHub quietly became the thread that held everything together. Here is what I did not expect.

Emergency Deployment

My VPS went offline mid-project. No warning, no graceful shutdown, just gone. At that point, my portfolio site at anthonyapierre.com was running as a Hugo container on that same server.

It did not go down with it. Well not for too long…

In my previous posts I spoke about how the site going down pushed me to move everything to Cloudflare and if you haven’t looked at their ‘free’ tier, it is genuinely remarkable. Shout out to Cloudflare.

But the outage forced a more immediate problem: I needed to get the site off the VPS before the next connection drop. In the brief moments that connectivity held, I installed the Git runtime on the server and cloned the entire site to a private GitHub repository. It was the first time I had done this, and it took about ten minutes. What I hadn’t expected was what happened next. I already had GitHub Desktop installed on my Windows machine, so I pulled the repository straight down to my desktop. The site is entirely static files, Hugo output, images, configuration and comes in at around 10MB. Having it local meant I could open pages directly in Visual Studio Code, make changes, and push them back to GitHub with a couple of clicks.

That push triggered everything else automatically.

GitHub Actions picked up the commit and ran a build pipeline: Hugo compiled the site, static assets synced to S3 with long cache headers, HTML files synced with no-cache headers so visitors always see the latest content, and CloudFront invalidated automatically. I initially deployed to Cloudflare Pages before migrating to AWS S3 and CloudFront but the workflow was identical in both cases. Push to master, and after set-up everything else happens without me. What started as an emergency measure became the foundation of how I manage the site going forward.

That is the value of decoupling your application from your infrastructure. When the server dies, the deployment pipeline does not.

File Transfer Without SSH

In the same session, I found myself partially locked out of my homelab remotely. My server location had a static IP for almost two years, so when it changed without warning it caught me completely off guard. I had files I needed to transfer to my Proxmox host, and although I still had browser access via a Cloudflare DNS connection, I could not work out how to get the files across without direct SSH.

The solution turned out to be straightforward. I pushed the files I needed from my local machine to a private GitHub repository, then pulled them down from the Proxmox web console using the Git runtime that I installed in the remote container I was working on.

No SCP. No SFTP. No workarounds. Just git clone and everything was exactly where it needed to be.

When your code lives in version control, it is always reachable, regardless of what your VPN is doing.

Version Control as a Safety Net

Building and debugging across multiple machines and sessions means things go wrong. Docker caches the wrong image. A config change breaks a pipeline. A dependency update introduces a regression.

Every time something broke during this build, the first question was: what changed? Git answered that question instantly. Every fix, every configuration edit, every debugging session was committed with a message that described what was done and why. Rolling back was a single command. Understanding the history of a problem was a matter of reading the log.

This is not a new idea. But experiencing it in practice under pressure, mid-debugging, with a live system misbehaving makes the value of disciplined committing genuinely concrete.

Collaboration With AI

Working with Claude to build and iterate on code introduced an interesting workflow challenge. The model has no persistent memory of the codebase between sessions. Every new session starts fresh.

GitHub solved this completely. The canonical version of the code was always in the repository. At the start of each session, the current state was clear. Changes made in one session were committed before closing. The next session picked up exactly where the last one left off.

Version control becomes even more important when you are working collaboratively, whether that collaborator is a human engineer or an AI model. The repository is the shared source of truth.

What I Learned

GitHub is not just a backup. It is not just a place to publish open source projects. Used properly, it is the connective tissue of a modern development workflow.

  • It is your deployment pipeline via GitHub Actions
  • It is your disaster recovery when infrastructure fails
  • It is your file transfer mechanism when direct access is blocked
  • It is your audit trail when things go wrong
  • It is your shared context when working across sessions or with collaborators

If you are building anything a homelab, a side project, a portfolio and you are not committing regularly, you are one bad deploy away from starting over. And it has taken me almost two years to get to this realisation.

Commit often. Write meaningful messages. Push before you close the session.

The ten seconds it takes is never wasted.