Hosting a website from home

The machine is rarely the problem

People assume hosting a website from home is a hardware question. It isn't. A ten-year-old laptop can serve a personal site to more visitors than it will ever have. What stops it is that residential internet is designed for fetching things, not for being found.

There are four obstacles, and they are independent of each other. Fixing three of them still leaves you offline, which is why this so often turns into a weekend of changing settings at random. Work out which ones apply to you first.

Find out which problem you actually have

Four checks, in this order. Each takes under a minute, and each one rules something in or out.

1. Compare the address your router thinks it has with the address the internet sees. If they disagree, your provider is translating your traffic and the address you see is not yours.
2. Check whether that address is a shared-carrier one. Anything from 100.64. to 100.127. is the range reserved for carrier-grade NAT. A 10., 172.16. to 172.31., or 192.168. address on the WAN side means the same thing.
3. Test the port from outside your own network, using mobile data with Wi-Fi off or an online port checker. Testing from inside the house proves nothing: your router will often loop the request back to you and it looks like it works.
4. Read how it fails, because the two failures mean opposite things.

curl -s https://api.ipify.org; echo

nc -vz your-public-address 443

You may not have a public address

Many providers put customers behind carrier-grade NAT, where one public address is shared between many households. Mobile broadband is almost always like this, and newer fibre networks increasingly are. Nothing on the internet can open a connection to you, because there is no address that means you.

This is not a setting you can change. Port forwarding maps a port on your public address to a machine inside the house, and behind CGNAT you have no public address to map from. The router will accept the rule and it will simply never fire.

Ask your provider before you design around it

Some providers will move you to a real address on request, sometimes free, sometimes on a business tariff. It is worth one phone call before you architect around it. Ask for "a public IPv4 address" specifically; "static IP" is a different thing and they may quote you for it.

IPv6 is a genuine way out where it exists, because there are enough addresses for everyone and CGNAT is unnecessary. The catch is the visitor's side: anyone on an IPv4-only connection cannot reach an IPv6-only site, and that is still a meaningful share of the internet.

The useful ports are often blocked

Plenty of residential providers block inbound traffic on ports 80 and 443 outright, partly as an anti-abuse measure and partly because home lines are not sold as hosting. Some will unblock on request. Many will not, or only on a business plan.

Port 25 is blocked outbound almost everywhere, so a mail server at home is a separate and harder problem. Residential address ranges also sit on blocklists such as Spamhaus PBL by default, which means mail you do manage to send is likely to be rejected anyway. If your site needs to send email, use a mail provider and do not fight this.

Moving the site to a high port is the usual workaround, and it is not one. Visitors expect a site at https://example.com, not https://example.com:8443, and a certificate issued over HTTP validation needs port 80 reachable regardless of where the site itself listens.

Your address keeps changing

Even with a public address, most home connections lease it dynamically. It changes after a reboot, an outage, or on the provider's own schedule.

Dynamic DNS papers over this by updating a DNS record whenever the address moves. It mostly works. Two things go wrong. The first is the gap: between the address changing and the new record being believed everywhere, your site is down, and how long that lasts depends on the record's TTL and on resolvers that ignore it. Set the TTL low, 60 to 300 seconds, before you need it, because lowering it afterwards does nothing for the caches that already have the old value.

The second is that dynamic DNS fails silently. The updater runs on the machine, and the machine going down is exactly when the address is most likely to change. You find out from a visitor. If you rely on this, monitor the site from somewhere else, not from the network it lives on.

HTTPS certificates have to keep renewing

Browsers treat plain HTTP as unsafe, so you need a certificate. Getting one means proving you control the domain, and how you prove it decides whether any of this works behind a blocked port.

There are three ways. The HTTP-01 challenge answers a request on port 80, so it needs port 80 reachable from the internet. TLS-ALPN-01 does the same on port 443. DNS-01 proves control by writing a TXT record instead, and needs no inbound connection at all, which makes it the only option behind CGNAT, and the one worth knowing about before you give up.

Free certificates last 90 days, and renewal is meant to run unattended from about day 60. That job has to keep working forever, on a machine that sleeps, reboots and occasionally moves house. A certificate that expires on a Sunday takes the site down as completely as a power cut.

Upload speed is the number that matters

Home connections are sold on download speed and are usually asymmetric: a 500 Mbps line might upload at 50, and older cable or DSL far less. Serving is uploading, so your advertised headline speed is not the one your visitors experience.

For a text-and-images site this rarely bites. A page weighing 1 MB served to ten simultaneous visitors needs about 80 Mbps for a second, and most visits are not simultaneous. It bites immediately for video, large downloads and backups.

It also competes with your household. Saturating your upload makes video calls in the same house stutter, which is a more common reason people stop hosting at home than any of the four obstacles above.

What your provider's terms actually say

Most residential contracts prohibit running servers. Enforcement varies from never to a letter, and a personal site attracting a few hundred visits a month is not what those clauses are aimed at. It is still worth reading yours, because discovering it after a traffic spike is the expensive order to find out.

Separately, publishing from home publishes something about your home. Your public address is a rough physical location, and a certificate's transparency log makes any hostname you request permanently searchable. Neither is a reason not to do it; both are reasons not to point your own name at your own house casually.

The three ways around all of it

Each of these solves a different subset of the four obstacles, and it is worth knowing which before you spend a weekend on one.

• Port forwardingFree and direct. Needs a real public address and unblocked ports, so it fixes nothing about CGNAT and nothing about a blocked 80/443. It also exposes a machine on your home network to the internet, which means its patching is now your job. Solves: none of the four on its own.
• A private network such as Tailscale or WireGuardExcellent for reaching your own machines from anywhere, and it works through CGNAT because both ends connect outwards. It does not make a site public: a visitor would have to join your network, which is not what a website is. Solves: your access, not the public's.
• An outbound tunnel to a relayThe machine opens a connection outwards to a server that already has a public address, and that server forwards visitors back down it. Because the connection starts from your side, CGNAT, blocked inbound ports and a changing address all stop mattering, and the certificate lives where the public address does. Solves: all four.

What the relay option costs you

A relay puts someone else's server in the path of your traffic. That is a real trade. You are trusting it to stay up, to forward honestly, and to still be there next year. It also terminates HTTPS, which means the traffic is decrypted at the relay before it is passed to you.

In exchange your router keeps every inbound port shut, your address can change as often as it likes, certificates are handled where the public address lives, and nothing on your home network is reachable from outside. This is what MacServe does. Your Mac holds an outbound tunnel open, and the relay forwards visitors back down it.

If that trade is wrong for you, the honest alternative is not port forwarding. It is renting a small server and serving from there. What you lose is the hardware you already own; what you gain is a public address that is yours.

The short version

If your router's WAN address starts with 100.64. you are behind CGNAT, and only a tunnel or a rented server will work. If you have a real address but the port test times out, ask your provider to unblock 80 and 443 before doing anything else. If it works today and breaks intermittently, you have a dynamic address and no monitoring.

And if you got a certificate but cannot renew it, switch the challenge to DNS-01 before you rebuild anything. That is usually the whole fix.