Published February 27, 2026 · 18 min read

GitHub Pages Complete Guide 2026: Free Website Hosting

GitHub Pages is one of the best-kept secrets in web hosting. It provides free, reliable hosting for static websites directly from a GitHub repository. No server to manage, no hosting bill, no complicated setup. Push your code to GitHub and your website is live within minutes.

We use GitHub Pages to host spunk.codes, spunk.bet, and dozens of other sites in our network. It handles millions of page views, serves over HTTPS, supports custom domains, and costs exactly zero dollars. This guide covers everything you need to know to do the same.

Table of Contents

  1. Initial Setup: Your First GitHub Pages Site
  2. Custom Domains and DNS Configuration
  3. HTTPS and SSL Certificates
  4. Jekyll and Static Site Generators
  5. CI/CD with GitHub Actions
  6. Limitations and Workarounds
  7. Pro Tips for Production Sites
  8. FAQ

Initial Setup: Your First GitHub Pages Site

Getting a website live on GitHub Pages takes less than five minutes. Here is the process from start to finish.

Step 1: Create a Repository

Create a new repository on GitHub. For a user site (yourusername.github.io), name the repository exactly yourusername.github.io. For a project site, use any name you want. The repository can be public (free for all users) or private (free for GitHub Pro, Teams, or Enterprise).

Step 2: Add Your Website Files

Push your HTML, CSS, JavaScript, and image files to the repository. At minimum, you need an index.html file in the root directory. This becomes your homepage. You can use any folder structure you want for additional pages.

Step 3: Enable GitHub Pages

Go to your repository's Settings tab, scroll to the Pages section, and select the source branch (usually main) and folder (root or /docs). Click Save. Within a minute or two, your site is live at https://yourusername.github.io (for user sites) or https://yourusername.github.io/repo-name (for project sites).

Step 4: Verify the Deployment

Navigate to the URL in your browser. If you see your website, the setup is complete. If you see a 404 error, check that your index.html is in the correct directory (root or /docs depending on your Pages configuration) and that the correct branch is selected.

Custom Domains and DNS Configuration

GitHub Pages supports custom domains at no extra cost. You can use an apex domain (example.com), a subdomain (www.example.com), or both. Here is how to set it up.

Step 1: Add a CNAME File

Create a file named CNAME (no extension) in the root of your repository. The file should contain only your custom domain, for example: example.com. Commit and push this file.

Step 2: Configure DNS Records

At your domain registrar or DNS provider, add the following records.

Record TypeNameValuePurpose
A@185.199.108.153Apex domain to GitHub Pages
A@185.199.109.153Apex domain to GitHub Pages
A@185.199.110.153Apex domain to GitHub Pages
A@185.199.111.153Apex domain to GitHub Pages
CNAMEwwwyourusername.github.iowww subdomain redirect

Step 3: Verify in GitHub Settings

Go to Settings → Pages and enter your custom domain. GitHub will run a DNS check. Once verified, check the "Enforce HTTPS" box. DNS propagation can take up to 48 hours, but usually completes within 30 minutes.

HTTPS and SSL Certificates

GitHub Pages provides free HTTPS via Let's Encrypt certificates. This is automatic for the default github.io domain and available for custom domains once DNS is properly configured.

How It Works

Troubleshooting HTTPS

If the "Enforce HTTPS" checkbox is grayed out, your DNS is not fully propagated or the CNAME file does not match your domain exactly. Wait a few hours and try again. If it still fails, remove the custom domain in GitHub settings, save, re-add it, and save again. This forces GitHub to re-provision the certificate.

Jekyll and Static Site Generators

GitHub Pages has built-in Jekyll support. Jekyll is a static site generator that converts Markdown files into HTML pages. When you push Markdown files to a Jekyll-enabled repository, GitHub builds the HTML automatically.

Jekyll Benefits

Other Static Site Generators

You are not limited to Jekyll. GitHub Pages can host output from any static site generator. The difference is that non-Jekyll generators require a build step via GitHub Actions.

GeneratorLanguageSpeedBest For
JekyllRubyModerateBlogs, documentation (built-in GitHub support)
HugoGoVery fastLarge sites, fast builds (1000+ pages in seconds)
AstroJavaScriptFastModern web apps, partial hydration
Next.js (static export)JavaScriptModerateReact apps with static export
Eleventy (11ty)JavaScriptFastFlexibility, multiple template languages
Plain HTMLN/AInstantSimple sites, full control, no build step

Our Approach: Plain HTML

At SPUNK.CODES, we use plain HTML files without any static site generator. Every page is a single self-contained HTML file with inline CSS. This means zero build time, zero dependencies, instant deployments, and complete control over every byte of output. For sites with fewer than 500 pages, plain HTML is often faster and simpler than any generator.

CI/CD with GitHub Actions

GitHub Actions allows you to automate builds and deployments for non-Jekyll static site generators. When you push code, an Action runs your build command and deploys the output to GitHub Pages.

Example: Deploy a Hugo Site

Create a file at .github/workflows/deploy.yml in your repository. This workflow installs Hugo, builds your site, and deploys the output to GitHub Pages on every push to the main branch.

name: Deploy to GitHub Pages
on:
  push:
    branches: [main]
jobs:
  build-deploy:
    runs-on: ubuntu-latest
    permissions:
      pages: write
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v3
        with:
          hugo-version: 'latest'
      - name: Build
        run: hugo --minify
      - name: Deploy
        uses: actions/deploy-pages@v4

GitHub Actions Benefits

Limitations and Workarounds

GitHub Pages is powerful but has specific limitations you need to understand before building on it.

LimitationDetailsWorkaround
Static files onlyNo server-side code (PHP, Python, Node.js)Use serverless functions (Cloudflare Workers, Vercel Edge)
Repository sizeRecommended under 1 GBUse Git LFS for large assets or external CDN
Site sizePublished sites should be under 1 GBOptimize images, use external hosting for media
Bandwidth100 GB/month soft limitUse a CDN (Cloudflare free tier) for high-traffic sites
Build frequency10 builds per hour limitBatch commits, use GitHub Actions with caching
No .htaccessCannot configure server-level redirectsUse JavaScript redirects or 404.html for SPA routing
No forms processingNo server to handle form submissionsUse Formspree, Netlify Forms, or Google Forms

The Cloudflare Combo

For production sites, put Cloudflare (free tier) in front of your GitHub Pages site. Cloudflare provides a CDN cache (faster page loads globally), DDoS protection, analytics, and page rules for redirects. This combination of GitHub Pages + Cloudflare gives you enterprise-grade hosting for free.

Pro Tips for Production Sites

Tip 1: Use a 404.html File

GitHub Pages serves a file named 404.html in your repository root for any URL that does not match a file. Use this for custom error pages or for single-page application (SPA) routing. For SPAs, the 404.html can redirect all requests to your index.html with a URL hash that the JavaScript router processes.

Tip 2: Optimize Images Before Committing

Every image you push to the repository counts toward the 1 GB recommendation. Compress images with tools like Squoosh, TinyPNG, or ImageOptim before committing. Use WebP format for the best size-to-quality ratio. A typical blog post image should be under 100 KB.

Tip 3: Use Multiple Repositories

Each GitHub repository can have its own GitHub Pages site. If you manage multiple websites (like our network of 100+ sites), each one gets its own repository, its own custom domain, and its own deployment pipeline. There is no limit on the number of GitHub Pages sites per account.

Tip 4: Cache Busting with Query Strings

When you update CSS or JavaScript files, browsers may serve cached versions. Append a version query string to your file references: style.css?v=2. Update the version number with each change. This forces browsers to download the latest file while still allowing caching between updates.

Tip 5: Monitor with GitHub Actions

Set up a GitHub Action that runs periodically (cron schedule) to check if your site is online and responding correctly. If a deployment breaks your site, you will get notified immediately instead of discovering it hours or days later.

Build Your Landing Page

Use our free Landing Page Builder to create a professional, responsive landing page ready for GitHub Pages deployment.

Get the Free Landing Page Builder

Frequently Asked Questions

Is GitHub Pages really free? What is the catch?

GitHub Pages is genuinely free for public repositories with no hidden costs. For private repositories, you need GitHub Pro ($4/month) or a GitHub Teams/Enterprise plan. The "catch" is that it only hosts static files. You cannot run server-side code, databases, or server processes. For static websites, blogs, documentation sites, portfolios, and landing pages, there is no catch at all. GitHub has offered Pages as a free service since 2008 and it remains one of the most reliable free hosting options available.

Can GitHub Pages handle high traffic?

Yes, with a caveat. GitHub's soft bandwidth limit is 100 GB per month. For a typical web page that is 500 KB including all assets, that is roughly 200,000 page views per month before you approach the limit. For higher traffic, put Cloudflare's free CDN in front of your site. Cloudflare caches your pages at edge locations worldwide and serves most requests without hitting GitHub at all. With Cloudflare, GitHub Pages sites can handle millions of monthly page views without issues. We do this for all of our production sites.

Can I use GitHub Pages for an e-commerce store?

You can build the front-end of an e-commerce site on GitHub Pages, but payment processing and order management require server-side functionality. The most common approach is a static front-end on GitHub Pages combined with Stripe Checkout (hosted payment pages), Snipcart (JavaScript shopping cart), or Shopify's Buy Button (embedded product widgets). These services handle the server-side payment and order logic while your static site handles product display and the shopping experience.

Share on X