Github-Pages

Right, so you’ve got your site building locally. That’s cute. But the whole point of this exercise is to get it on the actual internet, preferably without you having to manually drag files onto a server like some sort of digital peasant. This is where preview deployments and branch deploys come in—the machinery that turns your Git workflow into a publishing powerhouse. It’s the difference between a static site and a professional-grade deployment pipeline.

Alright, let’s get our hands dirty. You’ve built your Hugo site, and it’s a thing of beauty. But now we need to move it from the cozy confines of your laptop to the cold, hard internet where people can actually see it. The big platforms like Netlify are fantastic, but sometimes you need to roll your own deployment. Maybe you’re deploying to a client’s existing VPS, or you need the fine-grained control of a CDN. This is where the old guard—rsync, scp, and the AWS combo platter of S3 and CloudFront—come into play. It’s a bit more manual, but you’ll know exactly what’s happening, and I’ll be right here to make sure you don’t step on any rakes.

Right, Firebase Hosting. It’s Google’s CDN with a developer-friendly face, and honestly, it’s a fantastic choice for a Hugo site. It’s not quite as dead-simple as Netlify, but it gives you a terrifyingly fast global cache, free SSL, and the sheer might of Google’s infrastructure without having to utter the words “Google Cloud Platform.” Think of it as GCP’s polite, well-dressed cousin who actually shows up to your party on time.

Right, Vercel. You’re probably here because you’ve heard the hype about their “developer experience” and, well, it’s mostly true. They’ve taken the pain out of frontend deployment in a way that feels almost magical. But here’s the thing about magic: it works best when you know the incantation. For Hugo, that incantation is a vercel.json file. Without it, Vercel will politely shrug and try to build your site as a Node.js project, which is about as useful as a screen door on a submarine. We’re going to give it the right spellbook.

Alright, let’s talk about Cloudflare Pages. You’ve probably heard the buzz: it’s free, it’s fast, and it’s got that sweet, sweet global edge network. And for the most part, the hype is real. Deploying a Hugo site here feels like putting a rocket engine on a go-kart—in the best way possible. But, as with all things that seem too good to be true, there are a few quirks you need to understand so you don’t bash your head against a wall later. I’ve been there, so you don’t have to.

Alright, let’s get your Hugo site onto GitHub Pages. This is where we stop treating our repository like a fancy file cabinet and start making it do some real work. The magic wand here is GitHub Actions, which is essentially a robot butler you can instruct with a YAML file. We’re going to write a set of commands that will tell GitHub, “Hey, every time I push new content to the main branch, build the site for me and shove the results into the gh-pages branch.” It’s automation, and it’s glorious.

Alright, let’s get your Hugo site live on Netlify. This is arguably the easiest and most pleasant deployment experience you’ll have, which is why we’re starting here. Netlify’s founders basically looked at the modern web dev workflow, said “this is absurdly painful,” and built a product that does the hard parts for you. We love to see it. The core of this magic is a single file: netlify.toml. This is your deployment configuration, your build command, your redirect rules—your everything. It lives in the root of your repository, and Netlify will automatically find it and obey its every command. You can configure all this through Netlify’s web UI, but that’s a sucker’s game. It’s clicky, it’s fragile, and it’s completely disconnected from your codebase. The file is the source of truth. Always.