How To Self-Host a Public Website Part 1: Internet Basics

I'm not a pro, but I'm going to do my best to explain the things you should know before hosting a public-facing website. In part 2 of this post, I will explain exactly how I configured things so that the websites hosted on my personal server are accessible from the internet. This post here is more of a primer of basic internet concepts that will make things in post 2 easier to understand.

I'm also trying to explain things as basic as humanly possible, so if it still doesn't make sense or if you're smart and I've said something dumb/wrong somewhere, please comment below or contact me.

Assumption: you have set up something that you want to access from the internet, outside your local network. Maybe it's a website like this blog, or it's a web application (app) like Plex or Jellyfin. Anything you want. And I assume you want a fancy domain name URL for it, like... blog.justintavares.com.

Just be warned... anything that connects to the internet is a potential attack vector for hackers and threats. So make sure you keep your software up to date, use the recommended security configurations, enable logins, and maybe consider adding additional layers of protection (server-wide 2-factor authentication, basic authentication logins, strict firewall rules, etc) if possible.

Optimally, you would also use a network configuration with a DMZ and place your server in the DMZ area. Even between two firewalls, if you want an extra layer of protection for your local network. Note that this is a different thing than the "DMZ" option in your router's configuration pages - don't ever enable that for your server. For the purpose of this article, I'm going to also assume that you have a basic home network configuration without a DMZ - because you did have one, you probably wouldn't need this article.

How Will Users Reach Your Server?

This is an incredibly basic diagram of how the internet works that I'll be breaking down soon

Okay so you probably already know that your Internet Service Provider (ISP) gives you a connection to the internet by running a cable into your house that ultimately ends in a device called a router. Everything outside your router is considered the Wide Area Network (WAN aka The Internet). Every device, every computer or phone or smart fridge or TV or whatever, on the inside of your router is considered part of your Local Area Network (LAN). Usually the router your ISP gave you has a WIFI Access Point built in. The thing that makes WIFI. Yeah.

Your ISP will assign a Public IP address to your house (specifically, to your router). This address is how other computers on the internet find your server, or more specifically, how they find your network. If you set up a domain name (a friendly URL that points to your site) then there are servers out there on the internet that are like internet phone books that translate friendly domain names into IP Addresses. These servers are called Nameservers and the domain-to-IP translations are called DNS records. That's important knowledge for later.

A few things to note: Sometimes you don't get a Public IP, which makes this all way more complicated. I'm not going to dive into that here, though. Sometimes, your ISP will block traffic incoming on certain ports entirely, like port 80 or 443 specifically, which will make it harder for devices outside your network to reach your home server. Also, typically your ISP will give you a dynamic IP, meaning your IP changes every so often. I will tell you how to account for that when we set everything up in my next post.

Example home network setup. Similar to mine, actually.

A router does a few things. Generally they have a firewall built in - firewalls block or allow incoming (or sometimes outgoing) internet traffic based on where the traffic is coming from and/or where it's trying to go. Your router is probably also acting as your local network's DHCP server, which is the thing that assigns IP addresses to all the devices connected to your router. Every device on your LAN gets assigned a Local IP.

If you are hosting your own server in your house, you can directly access it without ever going out to the wider internet by going straight to its local IP. If your website is running on a server with a local IP address of 192.168.1.3 you can literally open up your web browser and type in 192.168.1.3 and it will connect to the website on your server. Certain blocks of IP addresses are reserved for private networks (like your LAN) and when you try to connect to 192.168.1.3 in this example, your router will understand that address is on your LAN and send you to that device instead of sending you out onto the internet.

Your router will also need to be told where to send incoming traffic. You do this using a configuration called Port Forwarding. In a nutshell, you will have to tell your router to which device it should send incoming website requests. It is best practice currently to send all incoming traffic to a particular kind of software running on your server called a Reverse Proxy. You will forward all incoming website requests through your router to your reverse proxy, and the reverse proxy will send the traffic to the specific device on your LAN that is hosting the website that the incoming traffic is looking for.

Wait what's a port?

This is what the internet looks like. Not really, just use your imagination.

So, internet traffic has a target port associated with the IP address. Ports are attached to IP addresses (or domain names) with a colon, and are used by the server to determine which software service on the server the incoming connection is trying to reach. You may have seen websites that use specific port numbers before - like companywebsite.com:1234 - but they're literally used for every connection. Your browser just doesn't show them to you because...

There are two main methods of communication used by your web browser and web servers - HTTP and HTTPS. HTTP (Hypertext Transfer Protocol) connections happen when you attempt to access a url that starts with http - for example, http://website.com. HTTP uses port 80 to communicate. There's a problem though - HTTP is insecure. It doesn't protect or hide the data being transferred back and forth between your web browser and the website you're accessing. That's where HTTPS comes in. HTTPS (Hypertext Transfer Protocol Secure) connections use port 443 and do protect your data. Your web browser just assumes all HTTP and HTTPS traffic are going to ports 80 and 443, and that's why it doesn't make you enter the port number.

HTTPS is more complicated to set up, but it's still super easy and there is absolutely no reason to use regular HTTP for any public websites in 2021. If you're running some web app that can only use HTTP... stop. Just shut it down. Don't let the internet access it.

Computers and servers establish and secure HTTPS connections using SSL certificates. I won't get into how this works mechanically because you dont need to know that to get this all working, but your website/server will need to be configured to use an SSL certificate in order to make HTTPS connections.

Oh also, while your server can run multiple sites on the same port, different web apps may use different ports. It's pretty common for websites to have their own webservers built in, and expect incoming traffic on port 8080 for example. It just depends on how they're each individually written or configured.

Thanks for reading, I hope this helped you understand something a little better - look out for part 2 of this post where I will go over exactly how to set things up so that going to yourwebsite.com from anywhere on the internet will take you to your self-hosted website.