By the end of this guide you'll have a live website with free hosting, free HTTPS, and optionally your own domain name, with no monthly bill. This is exactly how I run my own sites, including distributedrepublic.xyz: the whole thing is a GitHub repository, and every time I push a change, the site rebuilds and redeploys itself automatically.
The hosting service is GitHub Pages, which serves static websites directly from a repository. It is genuinely free for public repositories, with generous limits: sites up to 1GB and a soft bandwidth limit of 100GB per month, which is far more than most small business sites or personal projects will ever touch.
The twist in this guide is that you won't do most of the work. At each step I'll give you a prompt to paste into Claude (ideally Claude Code, which can run the commands for you, but the chat interface works too if you're happy to copy commands across yourself).
A free GitHub account
Access to Claude (Claude Code is best for this, since it can execute the steps)
Around 30 to 60 minutes
Optional: a custom domain from any registrar (roughly £10 a year). Without one, your site lives at yourusername.github.io for free.
One honest caveat before we start: GitHub Pages serves static sites. HTML, CSS, JavaScript, images. That covers portfolios, landing pages, documentation, event pages, and most small business sites. It does not cover anything that needs a server-side database or user logins.
If you already have a folder of HTML files, skip ahead. If not, let Claude build one. Paste this into Claude and edit the bracketed part:
Build me a simple, fast, mobile-friendly one-page website for [describe your project, business, or idea in two or three sentences]. Use plain HTML and CSS in a folder called my-site, with no frameworks and no build step. Include a hero section, an about section, and a contact section.
You should now have a folder containing at least an index.html. Open it in a browser to check you're happy with it. Iterate with Claude until you are; changes are cheap at this stage.
If you'd rather use a framework like Astro or Vite (I use Astro for Distributed Republic), ask for that instead. Just tell Claude "this will be deployed to GitHub Pages" so it configures the build correctly.
Paste this into Claude Code from inside your site folder:
Initialise this folder as a git repository, create a new public GitHub repository called my-site under my account using the gh CLI, and push the code to the main branch. If the gh CLI isn't installed or authenticated, walk me through setting that up first.
Checkpoint: visit github.com/yourusername/my-site and you should see your files.
If you're using the chat interface rather than Claude Code, ask Claude for the exact commands instead and run them in your own terminal.
This is the piece that makes the site deploy itself on every change. GitHub Actions is GitHub's free automation service, and it has an official pair of actions for publishing to Pages.
Prompt:
Add a GitHub Actions workflow at .github/workflows/deploy.yml that deploys this site to GitHub Pages on every push to main, using actions/upload-pages-artifact and actions/deploy-pages. If the site has a build step, run it first and upload the build output folder; if it's plain HTML, upload the folder as-is. Then tell me exactly what to change in the repository settings to enable it.
For reference, here's what that workflow looks like for a plain HTML site:
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: true
jobs:
deploy:
runs-on: ubuntu-latest
environment:
name: github-pages
url: $
steps:
- uses: actions/checkout@v5
- uses: actions/upload-pages-artifact@v4
with:
path: .
- id: deployment
uses: actions/deploy-pages@v4
For a framework site, the workflow gains a build job (install Node, run npm ci and npm run build, upload the dist folder). Claude will handle that variation if you told it what framework you're using.
This is the one step you must do by hand in the browser, and it's the step most people miss.
Go to your repository on GitHub
Settings, then Pages in the left sidebar
Under "Build and deployment", set Source to GitHub Actions
Until you do this, GitHub either serves nothing or serves files from a branch directly, and your workflow's deployments go nowhere.
Commit and push any small change (or re-run the workflow from the Actions tab). Checkpoint: the Actions tab shows a green tick, and your site is live at https://yourusername.github.io/my-site/.
From now on, this is your entire publishing process: change a file, push, wait about a minute. That's it. No FTP, no hosting dashboard, no invoices.
A github.io address is fine for a project, but a real domain looks better and costs about the price of two coffees a year. Prompt:
I own the domain example.com and my GitHub Pages site is in the repository yourusername/my-site. Walk me through connecting the domain: the CNAME file the repo needs, the exact DNS records to add at my registrar for both the apex domain and www, and how to enforce HTTPS once it's verified.
The short version of what Claude will tell you:
In Settings, then Pages, enter your domain under "Custom domain" (this creates a CNAME file; if your site has a build step, the file needs to live in your static assets folder so it survives the build)
At your registrar, point the apex domain at GitHub Pages' four A record IP addresses, and point www at yourusername.github.io with a CNAME record
Wait for DNS to propagate (minutes to a few hours), then tick Enforce HTTPS
GitHub provisions a free SSL certificate automatically via Let's Encrypt, so your padlock costs nothing too.
The workflow ran but the site is a 404. Almost always Step 4: the Pages source isn't set to GitHub Actions. Fix the setting and re-run the workflow.
The site loads but CSS and images are broken. Project sites live under a subpath (/my-site/), and absolute paths like /style.css break there. Tell Claude: "my site is deployed at username.github.io/my-site and the assets 404, fix the paths or set the correct base path in my build config." A custom domain at the apex makes this problem disappear entirely.
The custom domain shows a certificate warning. HTTPS certificates take a little while to issue after DNS verifies. Wait an hour, then check the Pages settings for errors. If it persists, ask Claude to check your DNS records with dig.
The site didn't update after a push. Check the Actions tab first; a red cross means the build failed, and you can paste the log straight into Claude to diagnose. If it's green, it's usually your browser cache, so hard-refresh.
The repository must be public for free Pages hosting (private repos need a paid plan). Don't put anything in it you wouldn't publish, including API keys in code. Everything in the repo is visible to the world.
You now have professional hosting infrastructure that large companies use for their documentation sites, for the price of nothing. The same pattern scales from a one-page site to a full multi-page site built with a framework, and the workflow never changes: edit, push, live.
A good next step is asking Claude to add the things that make a site feel finished: a favicon, social sharing previews, and a sitemap. And if you're curious what else AI can take off your plate beyond building websites, the free resources at bykovbrett.net/resources are a good place to start.