The one idea
Publishing is two separate things: a computer that is always on and holds your files, and an address that points people to it.
Hosting is the computer. A domain is the address. They are rented separately, from different companies, and confusing them is the reason most people find this step mysterious.
Hosting is renting space on a computer that never sleeps. A domain is the name people type to find it. You need both, and you can get the first free.
Static sites are files served as-is — cheap, fast, hard to attack. Dynamic sites run code and need a server that stays running, which costs money and attention.
A domain resolves via DNS to an IP address. A host answers HTTP requests at that address. Static hosting serves files from a CDN; dynamic hosting runs a process that must be monitored, updated and secured.
Static or dynamic decides everything
This one distinction determines your cost, your difficulty, and your risk.
| Static | Dynamic | |
|---|---|---|
| What it is | Files that already exist, sent as-is | Code that runs to build each response |
| Examples | Portfolio, docs, landing page, résumé | Login, dashboard, anything that saves data |
| Hosting cost | Free tiers are common and generous | Costs money, because a process runs continuously |
| Attack surface | Very small — there is no logic to trick | Real — logic, database, authentication |
| Ongoing work | Almost none | Updates, monitoring, backups |
| Breaks when | Rarely | Dependencies age, the server restarts, data grows |
The useful decision rule: if every visitor should see the same thing and nothing needs to be saved, build it static. You will get a free, fast, nearly unbreakable site with no ongoing responsibilities.
People routinely build dynamic sites for static problems, then pay in money and maintenance for a capability they never use.
Publishing a static site free
GitHub Pages publishes a static site directly from a Git repository. If you did
git-and-not-losing-your-work, you already have most of what this needs.
From folder to public URL
1 of 5Get the site into a repository.
Your files —
index.htmland whatever it references — committed to a repository on GitHub. If it opens correctly when you double-clickindex.htmlon your own machine, it will very likely work published.
Two candidates list the same project. One says "I built a portfolio site". The other sends a link that opens instantly on a phone, on a domain with their name.
Nothing about the code differs. One of them is checkable in eight seconds, and that is what gets looked at.
Your college project needs to be shown to an examiner who will not install anything. Static hosting means it opens in their browser on their phone.
The version that needs a database, an environment file and three terminal commands does not get looked at.
What changes the moment it is public
Locally, you were the only user and you were always kind to it. Publicly, three things become true at once.
It can be found. Not just by people you send the link to. Automated crawlers find new sites within hours. Assume anything published is indexed and readable, including files you did not link to but did upload.
It will be probed. Within a day of going live, a public address receives automated requests looking for known weaknesses — old admin panels, exposed configuration files, default passwords. This is not personal and it is not because your project is interesting. It is background noise on the internet.
It has to keep working. Something that runs code depends on other software that ages. A dependency gets a security fix, a platform version is retired, a certificate expires. Static sites are largely immune to this. Dynamic ones are not, and "I'll deal with it later" is a decision to have it break at a bad moment.
Try this
Which of these belong in a static site's published files?
- Your Google Analytics measurement ID
- Your email-sending service's API key
- The contact email address you want people to use
- A database connection string
Your challenge
Level 3 · IndependentPublish something real this week. A one-page site about a project you built, with a description, a screenshot and a link.
You have succeeded when: it opens on someone else's phone on mobile data; the address is HTTPS; you can update it by pushing a commit rather than uploading files; and you can name one thing on the page you deliberately did not include for privacy or security reasons.
That last one is the difference between publishing and understanding publishing.
What people usually get wrong
- Building a dynamic site for a static problem. You buy cost and risk and gain nothing.
- Assuming frontend code is private. Every visitor can read it, including every key in it.
- Testing only in your own browser. Test on a phone, on mobile data, in a private window — you are logged in and cached everywhere else.
- Forgetting case-sensitive filenames. Works on Windows, 404s on the server. A genuinely common first deployment failure.
- Committing the
.envfile to make deployment work. It works and it publishes your credentials. Hosts have a settings page for this. - Publishing then never looking again. Certificates expire, dependencies rot, forms silently stop sending. Check your own site once a month.
How someone experienced does it
Experienced people ask "what is the least this needs to be?" before choosing a host. A contact form does not require a backend if a form service handles it. A blog does not require a database. Every component you remove is one you cannot be attacked through, cannot be billed for, and cannot be woken up by.
They also automate deployment early. Manually uploading files means the live version drifts from what is in Git, and eventually nobody can say what is actually running. Pushing a commit and having the site update means the repository is always the truth.
And they think about the boring failure, not the dramatic one. Most small sites do not get hacked in an interesting way. They quietly stop working because a certificate lapsed or a free tier changed or a dependency broke — and nobody noticed for six weeks because nobody was checking.
When not to use this
Do not publish yet when:
- It holds real personal data and you have not thought about who can reach it. Get the access rules right on your own machine first.
- You cannot explain what every part does. Publishing code you have not read puts someone else's mistakes at a public address with your name on it.
- It is genuinely just for you. A local tool that runs on your laptop is a perfectly good outcome. Not everything needs an audience.
Prove it
Send someone the link and ask them to try it on their phone, without you present and without instructions.
Write down every place they got confused or it failed. That list is worth more than any checklist, because it is the actual difference between working on your machine and working in the world.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned deploying a website and what changes once it is public. Assume I am intelligent but relatively new to this — treat me as intermediate level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood deploying a website and what changes once it is public. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at publishing something on the internet — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.