Guide
How to host a website from home
You can run a web server on your own machine. Here's how it works, what goes wrong, and an honest look at whether it's worth doing.
- Yes, you can. A Raspberry Pi or a spare laptop is enough.
- You’ll need a static IP or dynamic DNS, ports opened on your router, and your own SSL certificate.
- Many home internet plans block port 80 and 443, which stops this before you start. Check first.
- It’s a great way to learn. It’s a poor way to run a site people rely on.
Hosting from home is a real thing people do, and it teaches you more about how the web works than any tutorial. It’s also the option most likely to end with a site nobody can reach.
Both of those are true at once, so let’s go through it properly.
What you’re actually setting up
A web host is a computer that stays on and answers requests. Your laptop is a computer. The gap between the two is smaller than it looks and larger than it sounds.
You need five things:
- A machine that stays on. A Raspberry Pi draws about 5 watts and is ideal. An old laptop works too.
- Web server software. Apache, nginx or Caddy. All free.
- A way for the internet to find you. Your home IP address usually changes, so you need dynamic DNS.
- Your router forwarding traffic to that machine.
- An SSL certificate, which you now maintain yourself.
Items 3 and 4 are where most attempts stop.
Check this before you start
Does your internet provider block incoming web traffic?
Many residential plans block ports 80 and 443 — the ports websites use. It’s deliberate: home connections aren’t sold for running servers. If yours does, nothing on this page will work, and no configuration changes it.
Find out before you spend an evening on setup. Search your provider’s name plus “port 80 blocked”, or ask their support directly. Some will unblock on request, some offer it on a business plan, and some just say no.
Is your upload speed enough?
Home connections are asymmetric — fast down, slow up. Your visitors download what your server uploads, so your upload speed is your site’s speed. 10 Mbps up is fine for a small site with light traffic. It is not fine for images or video.
Setting it up
If a hosted site would suit you better, the static site guide covers the five-minute version.
Install a web server. Caddy is the easiest choice because it gets HTTPS certificates automatically:
sudo apt install caddy
A minimal /etc/caddy/Caddyfile:
example.com {
root * /var/www/html
file_server
}
That’s a working HTTPS site in four lines, assuming the rest works.
Set up dynamic DNS. Your home IP changes when your router reconnects. A dynamic DNS service gives you a hostname that follows it. DuckDNS is free; Cloudflare works too if you script the API. Install their updater so it runs every few minutes.
Forward the ports. In your router settings, forward external ports 80 and 443 to your server machine’s local address. Give that machine a fixed local IP first, or the forward will point at the wrong device after a reboot.
Test from outside your network. This is the step people skip. Your site loading on your own wifi proves nothing — many routers handle internal requests without touching the internet at all. Turn wifi off on your phone and load it over mobile data. That’s the real test.
What goes wrong
The power goes out. Your site is down until you’re home.
Your IP changes and DNS lags. Even with dynamic DNS there’s a gap where visitors reach nothing. You can check what the world currently sees with the DNS propagation checker.
If nothing loads at all from outside, that usually shows up as DNS_PROBE_FINISHED_NXDOMAIN or a connection timeout rather than an error page.
Your home network is now exposed. You’ve opened a door from the internet into your house. If the server is compromised, whatever else is on your network is reachable from it. Put the server on a guest network or a separate VLAN, keep it patched, and don’t run anything on it you care about.
Your provider notices. Some residential terms of service prohibit running servers. Enforcement is rare but it exists.
It’s slower than you expect. A Pi on home broadband will not feel like a hosted site, particularly for visitors on another continent.
What it’s genuinely good for
None of that means don’t do it. It means be clear about what you’re doing it for.
Learning. You will understand DNS, ports, certificates and web servers far better after a weekend of this than after any amount of reading. That’s real value.
Things only you use. A media server, a personal dashboard, a file share, a home automation panel. No public audience, no uptime expectation.
Development and testing. A machine that mirrors your production setup, running on your desk.
Projects where downtime is free. A hobby site, an experiment, something you’d shrug about if it vanished for a day.
The honest comparison
| Home server | Shared hosting | |
|---|---|---|
| Cost | Hardware, plus electricity | Free to a few dollars |
| Setup time | An evening, if your provider allows it | Ten minutes |
| Uptime | Your power and internet | Someone else’s problem |
| Speed for visitors | Your upload bandwidth | A datacentre’s |
| Security | Yours to maintain | Mostly handled |
| What you learn | A great deal | Not much |
If the point is learning, the left column wins and nothing else matters.
If the point is a website other people use, the right column wins on every line, and free plans mean cost isn’t the deciding factor either. You can have a free subdomain running in a minute with none of the router configuration.
Host from home and somewhere else too
Run the home server. Learn how it works, break it, fix it, understand what a reverse proxy actually does.
And put the site people rely on somewhere that stays up when your power doesn’t. Those aren’t competing choices — most people who host from home do exactly this, and the main hosting guide covers the second half.