Putting it somewhere real

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.

Ask for the simplest path

You do not need to research hosting platforms. Ask:

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:

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.

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.

Before you send the link

- 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.

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.