Putting it on the internet

This is the payoff. You’re going to take the project that runs on your laptop and put it at a real web address — one you can send to a friend, who opens it on their phone, anywhere in the world. It’s more achievable than it sounds, because we’ll let a free service do the heavy lifting.

This is also the part of the journey that feels the most mysterious before you’ve done it — “how does a thing on my computer become a thing on the internet?” So we’ll go slowly here, building the picture one piece at a time with some everyday comparisons, and we won’t skip anything. By the end it’ll feel like what it actually is: a handful of clicks you do once.

Start here: what “putting it online” really means

Right now, your project lives in a folder on your laptop. When you run it (Module 6), your computer is doing the work of showing it, and only you can see it — because it’s only running on your machine. The page exists in exactly one place: in front of you.

“Putting it on the internet” means putting a copy of your finished page onto a computer that’s always on, always connected, and that anyone can reach. That’s the whole idea. Let’s unpack it with a comparison.

That “always-on computer in the town square” has a name: a server An always-on computer, run by a company, whose job is to hold your website's files and hand a copy to anyone who visits. You rent a little space on one rather than owning it. . You don’t own one or manage it — big companies run whole buildings full of them and let you put your site on one, free at the size you’re working at. Renting that little spot is called web hosting Letting a company keep your website's files on their always-on computer so the public can reach it. Free at the size you're building. , and the act of sending your finished site up to that computer so it goes live is called deploying Publishing your finished site onto a hosting company's always-on computer, giving it a real web address anyone can visit. Also called shipping or publishing. (you’ll also hear shipping or publishing — all the same thing).

Next: what’s a “build”?

One more small idea before we publish. While you’re working, your project sits in a comfortable, messy state — lots of files, arranged the way you need them to build. Before it goes public, your tools quietly tidy and shrink all of that into a small, neat set of final files made for visitors rather than for building. That packaging step is called a build The step that packages your project into final, optimized files ready for the web. Usually lands in a folder called dist. The hosting service runs it for you. , and those finished files are what actually get put online.

The good news: you almost never run the build yourself. The hosting service runs it for you, automatically, every single time. You just need to recognize the word — because in a minute a screen will ask you for your “build command,” and now that won’t be a mystery.

The service we’ll use: Cloudflare Pages

To host your site we’ll use a free service called Cloudflare Pages. Cloudflare is a large, well-known company that, among many other things, will hold your website on its always-on computers and serve it to the world — at no cost for the kind of site you’re building. It’s the same service hosting this very guide you’re reading right now.

You’ll make a free Cloudflare account in a moment, the same way you made your Claude and GitHub accounts back in Module 1. Nothing to install — it all happens in your browser.

The trick that makes this easy: connect GitHub to Cloudflare

Here’s the clever part, and it’s worth understanding before you click anything, because once it clicks it makes the whole module make sense.

Remember that your code already lives on GitHub (Module 5) — that’s your online backup. We’re going to introduce Cloudflare to your GitHub, and let them talk to each other directly. Once they’re connected, the whole thing runs on autopilot:

1. You finish some work and push it to GitHub (your normal save — “commit and push”).
2. Cloudflare notices the moment your GitHub updates.
3. It automatically builds your site (that tidying step from above) and puts the new version online.

So the rest of this module is really just wiring up that bell once. Three steps: tell Cloudflare a couple of facts about your project, connect it to your GitHub, and click go. Let’s do it.

Step 1 — Ask Claude for your two build settings

Cloudflare will need two small facts about your project: the build command and the output folder. Don’t worry about what they mean — your assistant knows them exactly. In Claude Code, inside your project, ask:

What are the build command and output folder for this project,
for deploying to Cloudflare Pages? Give me the exact values.

Write down the two answers — they’re usually a build command of npm run build and an output folder of dist, though your project may differ. These are just the two things you’ll type into Cloudflare in Step 3, so keep them handy.

Step 2 — Create the Pages project

First, make your free account: go to dash.cloudflare.com↗ (opens in a new tab) and sign up (or log in if you somehow already have one). This drops you into the Cloudflare dashboard — and here’s an honest heads-up: that dashboard is packed. It does a hundred things, most of which you’ll never touch, and hunting through its menus for the right page is genuinely frustrating, even for experienced people. So let’s not hunt.

Once you’re on the Workers & Pages screen, you’re looking to do these things, in order. The exact button labels move around over time, so the goal matters more than the precise wording:

• Start creating something new — look for a Create button, then choose the Pages option (as opposed to “Workers”).
• Choose to connect to Git — this is the “introduce Cloudflare to your GitHub” step from above.
• Authorize Cloudflare to see your GitHub (a permission pop-up; you’re allowing the two services to talk). Then pick your project’s repo from the list it shows you.

Step 3 — Fill in the build settings, then deploy

Now Cloudflare asks how to build your site. This is where those two values from Step 1 go — type them into the matching boxes:

• Build command — what you wrote down (often npm run build)
• Build output directory — what you wrote down (often dist)

Then find the Save and Deploy button and click it. Cloudflare now pulls your code from GitHub, runs the build, and publishes the result. This takes a minute or two — you’ll see a log of text scrolling by as it works, which is perfectly normal to watch (or ignore).

When it finishes, you get a live web address ending in .pages.dev The free web address Cloudflare gives your site, like my-project.pages.dev. It's real, permanent, and you can share it with anyone. — something like about-me-7k2.pages.dev. That is your site, on the internet. Click it. Open it on your phone. Text it to someone. You just published a thing the whole world can reach.

Your own web address (optional): custom domains

Your free .pages.dev address is real, permanent, and totally shareable — plenty of real projects live happily on one forever. But you might want your site to have your own name instead of about-me-7k2.pages.dev. That’s called a custom domain Your own personal web address, like yourname.com, that you rent yearly and point at your site instead of using the free .pages.dev address. , and this section explains what that actually is and how it works. It’s an extra, not a requirement — feel free to skip it and come back later.

First, what is a domain?

A domain The human-friendly name people type to reach a website, like google.com or yourname.com. You rent it yearly from a registrar; it points visitors to wherever your site is hosted. is simply the human-friendly name people type to reach a website — google.com, wikipedia.org, or yourname.com. Here’s the key thing to understand about how it relates to everything above:

Unlike hosting (which is free here), a domain has a small yearly rent — usually around the cost of a coffee or two per year, depending on the name. You don’t own it forever; you keep it as long as you renew it each year.

How it looks in Cloudflare when you have no domains yet

When you first go looking — in your Cloudflare dashboard, search for Domain Registration or Registrar in that same top search box — you’ll simply see an empty list, because you haven’t registered any domains yet. That’s completely normal and exactly what it should look like at this stage; it’s not a sign anything’s missing. There’s usually an option there to register a new domain: you type the name you want, and Cloudflare tells you whether it’s available and what the yearly price is. (Popular short names are often taken or pricey; adding a word or two usually finds something nice and cheap.)

Registering one and linking it to your project

The friendly part: because Cloudflare does both the hosting and the domain selling, the two hook together with very little fuss. The shape of it is:

1. Register the domain with Cloudflare (search Domain Registration, pick a name, pay the yearly fee). Now it’s yours.
2. Link it to your site: go back to your Pages project, find Custom domains, and add the domain you just registered. Because Cloudflare manages both sides, it wires them together for you — usually just a click or two of confirmation.
3. A short wait while it takes effect, and then typing your domain into any browser brings up your site.

From now on, shipping is automatic

Here’s the part worth savoring: you only set all this up once. From now on, your publish step is the exact same gesture as your save step. You ask your assistant to commit and push (Module 5), Cloudflare’s little “bell” rings, and a minute later your live site has updated itself. No dashboards to revisit, no files to drag. Saving your work and shipping it to the world have become the same simple act.