# Putting it somewhere real

Course: Vibe Coding 101 — https://zero2vibecode.com/learn/vibe-coding-101
Canonical URL: https://zero2vibecode.com/learn/vibe-coding-101/4-2-putting-it-somewhere-real

What deploying actually means, why a static page is the easiest thing in the world to host, and the checklist you run before you send anyone the link.

A project on your laptop is a private hobby. A project with a link is a thing that exists.

The gap between those two is smaller than it looks, especially for the kind of project this course builds.

## What deploying actually means

Deploying means putting your code somewhere that answers requests from the internet.

There are two kinds, and knowing which you have determines everything else.

**Static.** Your project is files — HTML, CSS, JavaScript, images. A server hands them over unchanged and the visitor's browser does the rest. Readlist is exactly this: one file, and all the saving happens in the visitor's own browser.

Static hosting is the easy mode of the internet. It is usually free at small scale, nearly impossible to break, and has almost no security surface, because there is no code of yours running on a server for someone to attack.

**Server-side.** Your code runs on a machine somewhere, for every request. You need this when there is a shared database, accounts, private data, or anything that must not live in the visitor's browser.

It is more capable and it drags in a whole tail: a place to run, environment settings, secrets management, a database, logs, and a bill that grows with traffic.

If you can build version one as a static page, do. You can add a server later when you actually need one, and by then you will know what for. Starting with a server "in case we need it" is how a weekend project acquires a monthly bill.

## Ask for the simplest path

You do not need to research hosting platforms. Ask:

```text
Readlist is a single HTML file with no build step and no server.
What is the simplest way to put it on the internet at a real URL?
Give me the steps, and tell me what it costs.
```

You will get concrete steps. Follow them one at a time and check after each — the same loop, applied to shipping.

Two things to insist on in the answer:

- **Cost.** "Free at this size" is an acceptable answer. "It depends" is not — ask what it depends on.
- **How to undo it.** Deleting a deployment, taking a site offline, cancelling. Know the exit before you take the entrance.

## Step one is a repository

Whatever host you land on, the steps almost always begin in the same place: put the project in a repository and point the host at it.

The word is heavier than the thing. A repository is your project folder plus a memory of every version you saved. One command makes it, and it stays on your machine until you decide otherwise.

Here is the part that matters for shipping: **the host does not copy your folder. It copies your last commit.** A file that sits in the folder and never got staged is a file the server never sees.

Four commands, and only one of them requires a decision:

```text
git init                        # start recording this folder
git status                      # what is here, what is tracked
git add readlist.html           # choose what goes in
git commit -m "first version"   # save the snapshot
```

The decision is the third line. Your folder holds things that are not the project: the copy you made before a risky change, scratch files, notes only you should read. `git add .` sweeps up every one of them — and on a static host, everything you ship is reachable at a URL, including the old copy you forgot about.

So you read `git status` first, every time. It is the shipping manifest.

**Your turn.** Run `git init`, then `git status`, and read the untracked list before you stage anything. Not everything in that folder belongs on the internet — decide which paths are the project and which one is only useful on your own machine.

Stage the ones you chose, by name, then commit. If git answers `2 files changed`, you shipped what you meant to ship. If it says three, look again at what you just published.

Git here is simulated, and `git add .` is a perfectly good habit once a folder contains only the project. The habit worth building is the `git status` in front of it — reading the list of what is about to travel, before it travels.

## Why "it works on my machine" stops being true

The classic first deployment: everything works locally, the deployed version is blank.

Almost always the same cause. Your machine has things the server does not:

- **Files you created by hand** and never committed — they are in your folder, not in the snapshot the host copied.
- **Installed tools** that are simply not there.
- **Environment values** — those keys you correctly kept out of the code now have to be set on the hosting platform too.
- **Data** sitting in your browser or a local database, which the server has never seen.
- **Different paths.** A file reference that works locally and is wrong on a case-sensitive server, which many are.

The test is the one from the previous lesson: a fresh copy, from scratch, following your own instructions. If you cannot get it running from a clean folder, the server cannot either.

Environment values are the number one first-deploy failure. Your local setup has them; the server does not until you add them there. Anything the code reads from the environment has to be configured in the hosting platform separately.

## Before you send the link

```text
- Open the URL in a private window — no cached login, no saved data
- Open it on your phone, on mobile data, not your home network
- Check the empty state: what a brand-new visitor sees
- View the page source and search for anything secret
- Confirm nothing private is reachable by editing the URL
- Try the main action once, on the live version, exactly as a user would
```

That last one matters more than it looks. Deployed is not the same as working. Check the live version, not the local one you were staring at ten minutes ago.

On a static page, everything is visible to anyone who looks — the code, the comments, any key you left in there. "View source" is a right, not a hack. Search yours before you share it.

## Then tell someone

Send it to one person. A friend, a group chat, a forum, the person you built it for.

This is the part people skip, and it is where projects become real. A link that nobody has opened is still a private hobby, just with better hosting.

You will get feedback that is uncomfortable and useful, in that order. Add it to the Later list. Do not fix it all tonight.