How to Host a Website for Free with GitHub Pages (2026 Guide)
You do not need to pay for web hosting. Not a dollar. Not a cent. GitHub Pages gives you free, production-grade static site hosting backed by GitHub's global CDN, with free HTTPS, custom domain support, and seamless Git-based deployments. Whether you're launching a personal portfolio, a documentation site, or an entire business, GitHub Pages is the fastest way to go from zero to live on the internet.
This is the definitive 2026 guide. We'll cover everything from your first deploy to advanced GitHub Actions automation, custom domains, performance tuning, and how GitHub Pages compares to alternatives like Netlify, Vercel, and Cloudflare Pages. If you follow along, you'll have a live website in under 15 minutes.
What Is GitHub Pages?
GitHub Pages is a free static site hosting service built directly into GitHub. It takes HTML, CSS, and JavaScript files from a repository, optionally runs them through a build process, and publishes the result as a website. Your site gets a default URL like username.github.io, or you can point any custom domain at it for free.
Here's what makes it compelling in 2026:
- Completely free — No credit card required, no hidden fees, no bandwidth charges
- Free HTTPS — Automatic SSL certificates via Let's Encrypt for every site, including custom domains
- Global CDN — Your site is served from GitHub's content delivery network worldwide
- Git-based workflow — Push to
mainand your changes go live automatically - Custom domains — Connect any domain with a simple DNS change
- GitHub Actions — Automate builds, testing, and deployment with CI/CD workflows
- Works with free GitHub accounts — Public repositories get GitHub Pages at no cost
GitHub Pages is not a gimmick or a limited trial. Thousands of production websites run on it, from developer portfolios to open-source project documentation to full business sites. SpunkArt runs multiple sites on GitHub Pages infrastructure, including Spunk.Bet — a live casino platform serving real users.
Why GitHub Pages Is Perfect for Beginners
Most hosting providers overwhelm beginners with server configuration, control panels, database setup, and pricing tiers. GitHub Pages strips all of that away. There are no servers to manage, no databases to configure, no billing surprises.
If you can create a file called index.html and push it to a GitHub repository, you have a live website. That's the entire mental model. There's no deployment step to learn, no SSH keys to manage, no cPanel to navigate. The learning curve is essentially the learning curve of Git itself, and with GitHub's web interface, even that barrier is optional.
For anyone who read How I Built 120+ Websites in 7 Days Using AI, you already know the power of free infrastructure at scale. GitHub Pages was central to that process.
Step-by-Step: Set Up Your First GitHub Pages Site
Let's go from nothing to a live website. This works whether you've used Git before or not.
Create a GitHub Account
Go to github.com and sign up for a free account if you don't already have one. All you need is an email address. A free account gives you unlimited public repositories with GitHub Pages.
Create a New Repository
Click the green "New" button on your dashboard (or go to github.com/new). Name the repository username.github.io, replacing "username" with your actual GitHub username. This naming convention tells GitHub to treat this as your personal site. Make it public, check "Add a README file", and click "Create repository".
You'll see your new repository with a single README.md file. The repository name matters: username.github.io is the special naming pattern for user sites. For project sites, you can use any repository name and your site will be available at username.github.io/repo-name.
Create Your index.html File
Click "Add file" then "Create new file" in the GitHub web interface. Name the file index.html and paste in your HTML. Here's a minimal starting point:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>My Free Website</title>
<style>
body {
font-family: system-ui, sans-serif;
max-width: 600px;
margin: 80px auto;
padding: 0 20px;
background: #0a0a0a;
color: #e8e8e8;
}
h1 { color: #ff5f1f; }
a { color: #ff5f1f; }
</style>
</head>
<body>
<h1>Hello, World</h1>
<p>This website is hosted for free on GitHub Pages.</p>
<p>Edit this file and push to deploy.</p>
</body>
</html>Click "Commit changes" at the bottom of the page. Write a commit message like "Add index.html" and commit directly to the main branch.
Enable GitHub Pages
Go to your repository's Settings tab. In the left sidebar, click Pages under "Code and automation". Under "Source", select Deploy from a branch. Choose the main branch and the / (root) folder. Click Save.
GitHub will build and deploy your site within 1-2 minutes. Once complete, you'll see a green banner with the URL: https://username.github.io. Click it. Your site is live.
Make Changes and Redeploy
Every time you push a change to the main branch, GitHub Pages automatically rebuilds and redeploys your site. Edit a file in the web interface, or push from your local machine with Git. Changes typically go live within 30-60 seconds.
That's it. Five steps, zero cost, no server management. You now have a live website with HTTPS, a CDN, and automatic deployments.
Setting Up a Custom Domain
Your free username.github.io URL works, but you probably want your own domain. GitHub Pages supports custom domains at no extra charge, and configuring one takes about 5 minutes.
For Apex Domains (example.com)
If you want your site at example.com (no "www"), you need A records pointing to GitHub's IP addresses. Log into your domain registrar's DNS settings and create four A records:
Type Host Value
A @ 185.199.108.153
A @ 185.199.109.153
A @ 185.199.110.153
A @ 185.199.111.153For IPv6 support, also add four AAAA records:
Type Host Value
AAAA @ 2606:50c0:8000::153
AAAA @ 2606:50c0:8001::153
AAAA @ 2606:50c0:8002::153
AAAA @ 2606:50c0:8003::153For Subdomains (www.example.com)
If you want www.example.com or any subdomain, create a CNAME record:
Type Host Value
CNAME www username.github.ioTell GitHub About Your Domain
After setting up DNS, go to your repository's Settings, then Pages, and type your custom domain in the "Custom domain" field. Click Save. GitHub creates a CNAME file in your repository root automatically.
DNS propagation usually takes 5-60 minutes, though it can take up to 24 hours in rare cases. Once propagation completes, GitHub will automatically issue a free SSL certificate through Let's Encrypt.
Pro tip: Verify your custom domain in your GitHub account settings (Settings > Pages > "Add a verified domain"). This prevents other GitHub users from taking over your domain if you ever remove the custom domain from your repository. It's an important security step that many tutorials skip.
Free HTTPS with GitHub Pages
Every GitHub Pages site gets free HTTPS automatically. There's no configuration needed. GitHub partners with Let's Encrypt to provision and renew SSL certificates for all Pages sites, including those using custom domains.
Once your custom domain's DNS is pointing to GitHub, check the "Enforce HTTPS" box in your Pages settings. This redirects all HTTP traffic to HTTPS, which is both a security best practice and an SEO requirement. Google has used HTTPS as a ranking signal since 2014, and in 2026 browsers actively warn users about non-HTTPS sites.
The certificate renewal process is fully automated. You never need to manually renew, install, or configure certificates. Compare this to traditional hosting where SSL certificates cost $10-100/year or require manual Let's Encrypt setup with certbot scripts.
Deploying a Static Site
GitHub Pages is designed for static sites. That means HTML, CSS, JavaScript, images, and any other files that don't require server-side processing. Despite that constraint, you can build surprisingly complex applications.
Plain HTML/CSS/JS
The simplest approach. Drop your files into the repository, push, and they're live. No build step, no configuration, no dependencies. This is how most of the sites in the SpunkArt Store are structured — pure static files that load instantly.
Jekyll (Built-in Support)
GitHub Pages has native Jekyll support. Jekyll is a static site generator written in Ruby that transforms Markdown files into HTML. If you put Markdown files in your repository with specific front matter, GitHub Pages builds them into a full website automatically. No local tooling required.
# _config.yml
title: My Blog
description: A blog built with Jekyll on GitHub Pages
theme: minima
baseurl: ""
url: "https://yourdomain.com"Create posts as Markdown files in a _posts directory using the naming convention YYYY-MM-DD-title.md. GitHub builds the site on every push using Jekyll's engine, which means you write Markdown and get a fully themed HTML site.
Static Site Generators (Hugo, Eleventy, Astro, etc.)
For generators other than Jekyll, you build locally and push the output, or you use GitHub Actions to build on GitHub's servers. Hugo, Eleventy, Astro, Next.js (static export), Gatsby, and dozens of other generators all work with GitHub Pages. We'll cover the GitHub Actions approach in the next section.
Single-Page Applications
React, Vue, Svelte, and Angular apps can all be deployed to GitHub Pages after building. The key is configuring your router to work with GitHub Pages' URL structure. For React Router, you'll need a 404.html redirect hack or use HashRouter. For Vue Router, set the base path to match your repository name.
Using GitHub Actions for Automated Deployment
GitHub Actions is the game-changer. Instead of deploying from a branch, you can set up a CI/CD pipeline that builds your site automatically on every push. This is essential if you use any build tool, bundler, or static site generator beyond Jekyll.
Setting Up the Workflow
First, go to Settings > Pages and change the source to "GitHub Actions" instead of "Deploy from a branch". Then create a workflow file.
Here's a production-ready workflow for a static HTML site:
# .github/workflows/deploy.yml
name: Deploy to GitHub Pages
on:
push:
branches: ["main"]
workflow_dispatch:
permissions:
contents: read
pages: write
id-token: write
concurrency:
group: "pages"
cancel-in-progress: false
jobs:
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Pages
uses: actions/configure-pages@v5
- name: Upload artifact
uses: actions/upload-pages-artifact@v4
with:
path: '.'
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4This workflow triggers on every push to main. It uploads the repository contents as a Pages artifact and deploys it. The workflow_dispatch trigger lets you manually redeploy from the Actions tab.
Hugo Build + Deploy Workflow
For Hugo or other generators, add a build step:
# .github/workflows/hugo-deploy.yml
name: Deploy Hugo Site
on:
push:
branches: ["main"]
workflow_dispatch:
permissions:
contents: read
pages: write
id-token: write
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
submodules: recursive
- name: Setup Hugo
uses: peaceiris/actions-hugo@v3
with:
hugo-version: 'latest'
extended: true
- name: Build
run: hugo --minify
- name: Upload artifact
uses: actions/upload-pages-artifact@v4
with:
path: './public'
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
needs: build
steps:
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4Replace the Hugo-specific steps with whatever build process your generator uses. The pattern is always the same: checkout, build, upload artifact, deploy.
Node.js Build Workflow (React, Next.js static, Astro, etc.)
# .github/workflows/node-deploy.yml
name: Deploy Node.js Site
on:
push:
branches: ["main"]
permissions:
contents: read
pages: write
id-token: write
jobs:
build-and-deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 20
cache: 'npm'
- run: npm ci
- run: npm run build
- name: Upload artifact
uses: actions/upload-pages-artifact@v4
with:
path: './dist'
- name: Deploy
id: deployment
uses: actions/deploy-pages@v4Adjust the path value to match your build output directory (dist, build, out, or public depending on your framework). The important thing to remember: the 10 builds per hour soft limit does not apply when deploying via GitHub Actions, which makes it the preferred method for active development.
If you want to learn more about automating edge deployments, read our Cloudflare Workers Tutorial for Beginners. The principles of CI/CD carry over directly.
Want Production-Ready Sites? Skip the Setup.
SpunkArt's digital product collection includes pre-built websites, tools, and templates ready to deploy to GitHub Pages or any static host. Production-tested code, instant download.
Browse the StorePerformance Optimization Tips
GitHub Pages is fast by default, but you can make it significantly faster with these optimizations. Site speed directly impacts SEO rankings, user retention, and conversion rates. For a deep dive, see our How to Speed Up Your Website guide.
1. Minify Everything
Minify HTML, CSS, and JavaScript before deploying. Remove whitespace, comments, and unnecessary characters. Tools like html-minifier, cssnano, and terser handle this automatically. If you're using a build tool, add minification to your pipeline. If you're deploying raw HTML files, use an online minifier or add a GitHub Actions step.
2. Optimize Images
Images are the single biggest payload on most websites. Use modern formats like WebP or AVIF. Compress aggressively. Specify width and height attributes to prevent layout shift. Lazy-load below-the-fold images with loading="lazy". For hero images that must load immediately, use fetchpriority="high".
<!-- Lazy load below-the-fold images -->
<img src="photo.webp" alt="Description"
width="800" height="600"
loading="lazy" decoding="async">
<!-- Priority load hero images -->
<img src="hero.webp" alt="Hero"
width="1200" height="630"
fetchpriority="high">3. Inline Critical CSS
Instead of loading an external stylesheet, inline your critical CSS directly in the <head>. This eliminates a render-blocking network request and lets the browser start painting immediately. For sites under 14KB of CSS, inline all of it. For larger stylesheets, inline above-the-fold styles and defer the rest.
4. Preconnect to External Origins
If you load fonts from Google Fonts, analytics from Google, or scripts from a CDN, add preconnect hints:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="dns-prefetch" href="https://www.googletagmanager.com">5. Use a CDN for Large Assets
GitHub Pages has a soft bandwidth limit of 100 GB per month and a 1 GB repository size limit. If you're serving large media files (videos, high-resolution images, PDFs), host them on a dedicated CDN like Cloudflare R2 (which has zero egress fees) or a service like BunnyCDN. Keep your GitHub repository lean and focused on code.
6. Cache Headers and Service Workers
GitHub Pages sets reasonable cache headers, but you can't customize them directly. To get more control over caching, add a service worker that caches static assets locally. This makes repeat visits nearly instant and enables offline access.
7. Reduce JavaScript
Every kilobyte of JavaScript must be downloaded, parsed, compiled, and executed. Audit your dependencies ruthlessly. Do you really need that 90KB animation library for one hover effect? Use native CSS animations where possible. Load third-party scripts with async or defer attributes.
GitHub Pages Limitations (and When to Upgrade)
GitHub Pages is powerful, but it has clear boundaries. Understanding these limitations helps you decide if it's the right fit or if you need something more.
Hard Limitations
- Static only — No server-side code (PHP, Python, Node.js, Ruby). No databases. No server-side rendering at request time.
- 1 GB repository size limit — Your published site can't exceed 1 GB. This is generous for HTML/CSS/JS but tight if you're storing lots of media.
- 100 GB/month bandwidth — Soft limit. Enough for most sites, but a viral post with heavy images could push past it.
- 10 builds per hour (branch deploys) — Doesn't apply to GitHub Actions deploys. But if you're using the simple branch-based deployment, rapid pushes may queue up.
- No server-side redirects — You can't configure 301/302 redirects at the server level. You'll need JavaScript redirects or meta refresh tags.
- No custom headers — You can't set custom HTTP headers like Cache-Control, Content-Security-Policy, or CORS headers.
- No form processing — Static sites can't process form submissions server-side. Use a third-party service like Formspree, Getform, or a Cloudflare Worker.
When to Upgrade
Consider moving beyond GitHub Pages if:
- You need server-side rendering (SSR) for dynamic content or SEO
- Your site exceeds 100 GB/month in bandwidth consistently
- You need custom HTTP headers for security policies or CORS
- You need server-side form processing, authentication, or database access
- You need edge functions or serverless compute alongside your static assets
- You need A/B testing, branch previews, or split testing built into the platform
For most of these cases, Cloudflare Pages or Netlify are the natural next step — both free tiers are generous and add server-side capabilities. For serverless edge computing specifically, read our Cloudflare Workers tutorial.
GitHub Pages vs. Other Free Hosts (2026 Comparison)
There are several excellent free static hosting platforms in 2026. Here's how they compare across the features that matter most.
| Feature | GitHub Pages | Cloudflare Pages | Netlify | Vercel |
|---|---|---|---|---|
| Price | Free | Free | Free tier | Free tier (Hobby) |
| Bandwidth | 100 GB/mo (soft) | Unlimited | 100 GB/mo | 100 GB/mo |
| Build Minutes | Unlimited (Actions) | 500/mo | 300/mo | 6000/mo |
| Sites | Unlimited | Unlimited | Unlimited (but shared limits) | Unlimited (Hobby) |
| Custom Domains | Yes (free) | Yes (free) | Yes (free) | Yes (free) |
| HTTPS | Auto (Let's Encrypt) | Auto (Cloudflare) | Auto (Let's Encrypt) | Auto (Let's Encrypt) |
| Edge Network | GitHub CDN | 300+ locations | CDN included | 100+ locations |
| Serverless Functions | No | Yes (Workers) | Yes (Functions) | Yes (Functions) |
| Branch Previews | No | Yes | Yes | Yes |
| Custom Headers | No | Yes | Yes | Yes |
| Form Handling | No | No (use Workers) | Yes (built-in) | No |
| SSG Support | Jekyll (native), others via Actions | All major SSGs | All major SSGs | All (Next.js optimized) |
| Ease of Setup | Easiest | Easy | Easy | Easy |
| Best For | Simple sites, portfolios, docs | Performance-critical sites | JAMstack, forms, identity | Next.js, React apps |
The Bottom Line
Choose GitHub Pages if you want the simplest possible setup, your site is purely static, and you're already using GitHub. Zero configuration, zero cost, and it just works.
Choose Cloudflare Pages if you need unlimited bandwidth, custom headers, edge functions, or the fastest global performance. Cloudflare's network of 300+ data centers is unmatched.
Choose Netlify if you need built-in form handling, identity management, or a mature plugin ecosystem. Netlify's developer experience is polished and well-documented.
Choose Vercel if you're building with Next.js. Vercel created Next.js and their platform is optimized specifically for it, with features like Incremental Static Regeneration and Edge Middleware.
None of these are bad choices. All four platforms are free for static sites and all four are production-ready. The best host is the one that matches your specific needs. For most beginners and most static sites, GitHub Pages is the right starting point because it has the lowest barrier to entry.
Real Examples of Successful GitHub Pages Sites
GitHub Pages isn't just for hobby projects. Here are categories of real production sites running on it:
Open Source Project Documentation
Many of the world's most important open-source projects host their documentation on GitHub Pages. Bootstrap, React (legacy docs), TensorFlow.js, and hundreds of other projects use GitHub Pages for their public documentation sites. The workflow is natural: documentation lives alongside the code in the same repository.
Developer Portfolios
Thousands of developers use username.github.io as their portfolio site. It's the most common first website for anyone learning web development. The direct connection to your GitHub profile gives potential employers or clients immediate credibility.
Business and Product Sites
Startups and solo founders regularly run business sites on GitHub Pages. Landing pages, product documentation, company blogs, and marketing sites all work perfectly as static sites. SpunkArt runs an entire ecosystem of sites across GitHub Pages and similar free hosting, proving that you don't need to spend money on infrastructure to run a real business. Read the full story in How I Built 120+ Websites in 7 Days.
Blogs and Content Sites
Jekyll's native integration makes GitHub Pages a natural home for blogs. Many technical writers and developers run their blogs on GitHub Pages with Jekyll, Hugo, or Eleventy. The Git-based workflow means every post is version-controlled, and you can accept contributions via pull requests.
Educational Resources
University courses, coding bootcamps, and technical training programs frequently use GitHub Pages to host course materials, syllabi, and interactive tutorials. The free hosting and simple deployment make it accessible to educational institutions with tight budgets.
Advanced Tips and Tricks
Custom 404 Page
Create a file called 404.html in your repository root. GitHub Pages will serve this page for any URL that doesn't match a file. Use it to guide lost visitors back to your site instead of showing a generic error.
Redirects with JavaScript
Since GitHub Pages doesn't support server-side redirects, use a simple HTML file with a meta refresh and JavaScript redirect:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="refresh" content="0;url=/new-page">
<script>window.location.href="/new-page";</script>
</head>
<body>
<p>Redirecting to <a href="/new-page">/new-page</a>...</p>
</body>
</html>Environment Variables with GitHub Actions
Use GitHub Actions secrets to inject environment variables at build time. This lets you keep API keys, tracking IDs, and configuration values out of your source code. Reference them in your workflow with ${{ secrets.YOUR_SECRET }}.
Automatic Sitemap Generation
If you're using Jekyll, add jekyll-sitemap to your _config.yml plugins list. GitHub Pages supports this plugin natively. For other generators, most have sitemap plugins available. For plain HTML sites, create a sitemap.xml manually and submit it to Google Search Console.
Multiple Sites from One Account
You get one user site (username.github.io), but unlimited project sites. Every repository can have its own GitHub Pages site at username.github.io/repo-name. Each can have its own custom domain. This means you can host dozens of sites from a single free GitHub account. SpunkArt uses exactly this pattern to run an entire network of sites at zero cost.
Private Repos (GitHub Pro/Teams/Enterprise)
With GitHub Pro ($4/month), Teams, or Enterprise plans, you can deploy GitHub Pages from private repositories. This keeps your source code private while your site is public. Useful for businesses that don't want their source code visible.
Common Mistakes to Avoid
- Forgetting the CNAME file — When you set a custom domain in GitHub's UI, it creates a
CNAMEfile in your repo. If your build process overwrites this file, your custom domain will stop working after each deploy. Always include the CNAME file in your build output. - Wrong repository name — Your user site must be named exactly
username.github.io. Capitalization matters. - Not verifying your domain — Without domain verification, another GitHub user could potentially claim your domain if you remove it temporarily.
- Storing secrets in the repo — Never commit API keys, passwords, or tokens to a public repository. Use GitHub Actions secrets for anything sensitive.
- Ignoring the 1 GB limit — Large video files, uncompressed images, or heavy assets will quickly hit the repo size limit. Use external CDNs for large media.
- Not setting up HTTPS enforcement — After your custom domain propagates, always enable "Enforce HTTPS" in Pages settings. There's no reason to serve anything over plain HTTP in 2026.
Build Faster with Pre-Made Templates
Stop building from scratch. The SpunkArt Store has production-ready website templates, tools, and digital products designed to deploy in minutes. Built for speed, optimized for SEO.
Browse the StoreConclusion
GitHub Pages remains one of the best free hosting solutions available in 2026. For static sites, portfolios, documentation, blogs, and landing pages, it offers everything you need: free hosting, free HTTPS, custom domains, automated deployments, and a global CDN. The learning curve is minimal, and the Git-based workflow means your deployments are version-controlled and reversible.
Start with GitHub Pages for your first project. As your needs grow, you can layer on GitHub Actions for advanced CI/CD, add Cloudflare Workers for serverless functionality, or migrate to a platform like Cloudflare Pages or Netlify when you need features like custom headers or edge functions.
The key insight is that you don't need to spend money to ship real websites to real users. The infrastructure is free. The tools are free. The only investment required is your time and effort. Stop configuring servers and start building.
For the full strategy behind building an entire portfolio of sites on free infrastructure, read How I Built 120+ Websites in 7 Days Using AI. And follow @SpunkArt13 on X for new tutorials, tool launches, and behind-the-scenes updates.