I was skeptical. Like, genuinely skeptical. When a friend suggested I host my portfolio on GitHub Pages instead of paying ₹3,000–5,000 annually for shared hosting, I thought it sounded like a shortcut that would inevitably bite me. Free hosting usually means compromises, right?
Six months in, I've changed my mind. Not because GitHub Pages is perfect (it has real limitations I'll get to), but because for a specific type of project — static sites, portfolios, documentation, blogs — it's genuinely one of the best decisions I've made. No surprise bills. No vendor lock-in. And honestly? The developer experience is better than most paid platforms I've used.
Here's what actually happened when I set it up, what worked, what frustrated me, and whether you should do this too.
The Setup Was Easier Than Expected (But Not Instant)
First, the good news: GitHub Pages doesn't require you to be a terminal wizard. I'm not one — I can stumble through Git commands, but I'm definitely not a DevOps engineer. And I got this working in under an hour.
Here's the actual process:
Step 1: Create a Repository With the Right Name
This part matters. Your repository must be named exactly yourusername.github.io. GitHub has built automation that looks for this specific naming pattern. Get it wrong, and it won't work. I almost named mine my-portfolio-2024 out of habit before I caught the requirement. That would've been frustrating.
Create the repo as public (required for the free tier — your code will be visible, which some people hate). Add a README if you want, but it's not necessary.
Step 2: Push Your Website Files
Clone the repository to your computer:
git clone https://github.com/yourusername/yourusername.github.io.git
Then add your HTML, CSS, and JavaScript files directly into this folder. Seriously, it can be as simple as an index.html file. GitHub Pages serves whatever you put there as a website.
git add .
git commit -m "Initial commit"
git push origin main
That's it. Within seconds to a couple of minutes, your site goes live at yourusername.github.io.
Step 3: Optional — Add a Custom Domain
If you own a domain (I use Namecheap for mine, costs about ₹400–600 annually in India), connecting it takes maybe 10 minutes. You update your domain's DNS settings to point to GitHub's servers. I was worried this would be the sticking point, but it was straightforward — GitHub's documentation walks you through it.
The certificate for HTTPS? Automatic. GitHub handles that too.
What Works Brilliantly (And What Doesn't)
The Wins
Speed: Your site is served by GitHub's CDN across the globe. I'm in India, and my portfolio loads in under a second from both Indian IPs and international ones. I've never had a shared hosting provider deliver this reliably.
Reliability: GitHub's infrastructure is battle-tested. Uptime is practically guaranteed. I haven't had a single instance of downtime in six months.
Version Control as Backup: Every change you make is tracked in Git. You can revert to any previous version of your site with one command. This is standard for code, but it's a lifesaver if you accidentally break something. Most hosting platforms don't offer this for free.
Static Site Generators: If you use something like Jekyll, Hugo, or Eleventy, GitHub Pages has built-in support (for Jekyll especially). Your static site generator files get automatically compiled into HTML when you push. I didn't go this route, but this is a huge win for bloggers.
The Real Limitations
GitHub Pages only hosts static websites. That means no server-side processing. No databases. No PHP, no Node.js backend, nothing that requires a server to execute code on demand.
Want a contact form that actually sends emails? You'll need to use a third-party service like Formspree or Basin. They're free (usually), but it's an extra step. Contact forms were the first thing that caught me off guard — I built one, tested it locally, pushed it, and then realized the form didn't actually do anything. I had to integrate Formspree, which added maybe 5 minutes of work but was an extra dependency I didn't initially plan for.
No server logs. No analytics built-in. If you want to track visitor behavior, you'll need to add Google Analytics or something similar via a script tag.
Branch deployments are limited. You get one site per repository (unless you use the `gh-pages` branch, which is a workaround for project sites). This isn't a problem for portfolios, but if you're running multiple sites, you'll need multiple repositories.
Large file hosting is discouraged (GitHub recommends files under 100 MB, but really you shouldn't be pushing large assets). Video hosting? Forget it. Use YouTube or Vimeo embeds instead.
| Feature | GitHub Pages | Shared Hosting | Vercel/Netlify |
|---|---|---|---|
| Cost | Free | ₹3,000–5,000/year | Free (with limits) |
| Best For | Static sites, portfolios | Traditional WordPress, PHP apps | Modern frameworks (React, Next.js) |
| Backend/Database | No | Yes | Limited (serverless) |
| Speed | Excellent | Variable | Excellent |
| Version Control | Native | No | Native (via Git) |
| Custom Domain | Yes | Yes | Yes |
The Workflow That Actually Stuck With Me
After six months, here's how I actually use this thing. It's not fancy, but it works.
When I want to update my portfolio (add a project, fix a typo, change the color of a button), I make the change locally on my machine, test it in the browser by opening the HTML file directly, then push to GitHub. Within 30 seconds, it's live.
No FTP credentials to manage. No cPanel dashboard to log into. No wondering if I'm editing the right file on the server. It's just code, Git, and done.
The one thing I had to get used to: I can't edit files directly in a browser-based editor like I could with traditional hosting. Everything goes through Git. For developers, this is obviously better. For non-technical people? This could be a dealbreaker.
I used to think this was a limitation. Now I think it's a feature. It forces you to keep your site organized and to take versioning seriously.
Who This Is Actually For (And Who Should Skip It)
Do This If...
- You're building a portfolio, resume site, or landing page.
- You're comfortable with Git (or willing to learn 10 minutes worth).
- You want the fastest, most reliable hosting possible without paying.
- You're a developer or someone who appreciates version control.
- You want to own your content and avoid vendor lock-in.
- You have a static blog (using Jekyll, Hugo, or similar).
Skip It If...
- You need a database or dynamic functionality (e-commerce, membership sites, anything that changes per user).
- You want a WordPress site (though GitHub Pages + Jekyll can do blogs).
- You're not comfortable with the command line at all.
- You need email hosting tied to your domain (though you can use third-party services).
- You're hosting large files or videos regularly.
My Take
Here's my honest opinion: GitHub Pages surprised me. I expected it to feel like a hack — something technically free but with so many workarounds that you'd eventually regret it. Instead, it's been genuinely pleasant.
What surprised me most was the speed and reliability. My portfolio loads faster than sites I've paid for. Zero downtime, zero maintenance, zero surprise billing. For someone who's used shared hosting before, this feels almost too good to be true.
What disappointed me was the learning curve for non-developers. I could do this in my sleep, but I watched a non-technical friend struggle with Git basics. If you're building a site for a client who doesn't know Git, you'll either need to manage deployments for them or find them a simpler solution.
The real question isn't "Is GitHub Pages good?" (it is, for its use case). It's "Is this right for your specific project?" If you're building a static website and you understand Git even slightly, yes. If you need a database or don't want to touch the command line, absolutely not. There's no shame in that — use something else.
For me? I'm keeping my portfolio here. It's cost me nothing, it's served my visitors faster than any paid host I've used, and I can go back to any version of my site from a year ago in seconds. That's genuinely valuable. Not just because it's free, but because it's better.
Verdict
Use GitHub Pages if: You're building a portfolio, personal website, documentation site, or static blog, and you have at least basic Git knowledge. It's free, fast, reliable, and will save you money while actually improving your workflow.
Skip it if: You need server-side functionality, a database, or you're uncomfortable with the command line. Use Vercel/Netlify (also free for static sites but with easier interfaces), shared hosting (if you need PHP/MySQL), or a website builder like Wix or Squarespace (if you want zero technical setup).
Bottom line: Don't host your portfolio on expensive shared hosting when GitHub Pages exists. But also don't force GitHub Pages into situations where it doesn't belong. Choose the right tool for the job, and GitHub Pages will be a genuinely pleasant surprise.
Published by Dattatray Dagale • 22 June 2026
0 Comments