Putting this site on the public internet without opening a single port

This site now lives on the public internet. It is served from a small server in my house, and to put it online I did not open a single port on my router. That sentence sounds like a contradiction if you learned networking the way I did, so this build log is about how that works, why I chose it, and the honest reason underneath the technical one: I have the sort of brain that forgets things, and I wanted a setup where forgetting is safe. Unfamiliar words are explained on the back-to-basics page.

Why publishing from home is scarier than it looks

Hosting a website at home used to mean one thing: you opened a door in your router's firewall and pointed it at the machine inside. That door is then open to the entire internet, day and night, whether you are watching or not. Within minutes of opening it, automated scanners will find it. That is not paranoia; it is just what the modern internet is. Every public address gets knocked on constantly by bots looking for an unlocked door.

And the thing behind my door is not a rented server in a data centre that I could shrug about and rebuild. It is my house. The same machine that serves this site sits on the same home network as everything else I own. The nightmare is not someone defacing a web page. The nightmare is a web page being a stepping stone into a home.

The trick: only ever dial out

The approach I used flips the direction of the connection. Instead of the internet reaching in to my server, my server reaches out to a relay service on the internet and holds that connection open. Visitors connect to the relay; the relay passes their requests down the line my server already opened. Cloudflare call theirs a tunnel, and that is the one I used, but several companies offer the same idea.

The difference sounds subtle and is enormous. An outbound connection is like phoning someone: nothing about it requires your own front door to be unlocked. From the outside, my home network looks exactly as closed as it did before the site existed. There is no open port to find, because there isn't one. If the relay is ever down, the site is down, and that is the whole cost.

Assume the worst, then make the worst small

The second half of the work was less visible and mattered more. I spent it on one question: if the site itself is ever compromised, what can the attacker reach from there?

The answer needed to be "almost nothing". So the site runs in its own sealed compartment, and everything is default-deny: rather than writing rules about what it may not talk to, it is forbidden from talking to anything on my network at all, and then given the two or three specific things it genuinely needs. Deny by default, allow by exception. Then I tested it from the inside, trying to reach the things it should not reach, and made sure every attempt failed.

I also switched off the site's cleverer features for the public launch. The AI-assisted tools I have written about in earlier build logs are simply not wired up in the public build. Every feature you expose is a surface someone can push on, and a launch is not the moment to be maximally interesting. They can come back one at a time, deliberately, once things have been boring for a while.

Design for the brain you actually have

Here is the part that belongs on this site rather than a general tech blog.

I have ADHD and I am dyslexic. I know, from decades of evidence, that I will forget things. I will forget that a testing rule was meant to be temporary. I will forget which of six settings I loosened at midnight to debug something. Security advice mostly assumes a diligent person who reviews their setup on a schedule, and I know better than to build anything that depends on me being that person every week, forever.

Default-deny is the safe-to-forget design. If I forget to allow something, a feature breaks, I notice, and I fix it. If I had built it the other way round, allowing everything and blocking known dangers, then forgetting something would mean a hole nobody notices until someone unfriendly does. The system fails in the direction of annoying rather than catastrophic. That is not a security principle I read in a book so much as an honest accommodation of my own memory, applied to infrastructure. It is the same reason my backups restore themselves to prove they work: anything that relies on me remembering is already broken, we just don't know the date yet.

The big red button

The last thing I built before going live was a kill switch: one control, protected behind its own login, that disconnects the site from the internet in a few seconds. Not a graceful shutdown, not a maintenance mode. Off. The server keeps running privately at home; the world just can't reach it.

I have not needed it. I hope I never need it. But I can tell you that the night the site went public, that button was the difference between checking the logs every twenty minutes and actually going to sleep. Anxiety, for me, is mostly the feeling of having no move available. The button is a move, always available, that ends any emergency first and lets me understand it second. Ten minutes of building bought hours of calm, which is the best exchange rate I know of.

What this costs, honestly

Fairness demands the trade-offs. My site now depends on a large company's relay staying up and on their terms staying acceptable; that is a real dependency I did not have before. Big file downloads and some kinds of traffic are a poor fit for these relays, and need their own arrangements. And none of this makes the site unhackable, because nothing does. The software itself can still have bugs, which is why the compartment it lives in matters.

What it does mean is that the failure I feared most, my home standing open to the internet because of something I forgot, is no longer something I have to be vigilant about. I built the vigilance into the walls instead. If your brain also drops things, I recommend it: make the careful choice once, at design time, when you are at your best, so that it keeps working on the days you are not.