the great virtue is dead

hi timbre here for the response since i did most of the work on the server lol

so as much as i hate to say it the first thing you should absolutely do is make sure you understand networking fundamentals. (ESPECIALLY if youre planning on setting up a bare metal server like we did) ive been watching this series on youtube (or invidious if you prefer) and it is phenomenally well explained and visualized, so definitely take a look at it. btw please be aware the difference between LAN and WAN. for most all home networks, every device connected to your router will have a local ip address that looks somethin like "192.168.0.167". this only is used for communicating between devices connected to the same router. then the ROUTER has a public IP address that is assigned based on where you live. every device on your network shares that public ip address since they all can only communicate to the WAN through the router.

after that you gotta make some personal choices; namely, what webserver software do you want to use. there are dozens of different webserver softwares that everyone prefers to use for all sorts of different reasons so i couldnt really recommend you one it good faith. i can say though that it is a fact that Apache 2 and NginX are by far the most prolific/widely used ones, so you should probably use them as a jumping off point. this video from IBM does a pretty decent job of explaining what a webserver software is, what it does, and what the difference between apache and nginx is.

id also advise you make sure you understand what a reverse proxy is and how it works. reverse proxies are kind of the other half to webservers and theyre basically essential if youre planning on doing anything beyond a simple http server. the IBM video from the last paragraph will get into reverse proxies in the context of multiple server devices, but thats more of like, enterprise level stuff. this probably wont make much sense if you havent learned networking fundamentals and the IBM video, but here; reverse proxies can be used to pull information from other devices on the LAN to be served to the internet by whatever device hosts the reverse proxy, without the other devices needing to directly connect to the internet. thats what they describe in the IBM video, but that is only a layer 3 use of reverse proxies. you can also do a layer 4 version (this is what i do) where you reverse proxy to a specific port on your single webserver's localhost instead of a specific IP on your local network. that way, you can host an https webserver on port 443 and an invidious instance with docker on port 8080 and have the webserver reverse proxy all attempts to connect to "invidious.website.com" to "localhost:8080" and that way the information will be funneled out of port 8080 and delivered to the internet through port 443 without you needing to port forward. this application of reverse proxies is extremely important if you want to experiment with other server softwares besides just the http server.

so if youve decided what webserver software to use (apache, nginx, caddy, etc.) you want to use, here's the steps you want to follow to actually get this dang thing up and running.

1: get the actual device that youre hosting this on. for you and most people that is probaly a VPS / cloud server that you pay for; if its a cloud server you probably just have some interface that will let you boot up a linux server off the bat, so do that. if youre doing bare metal, you just have to install the operating system like you would with any other. (burn the installation iso to a disc or a usb, put that storage device in the server and to the bios to tell it to boot off that portable storage device instead of the internal storage, and follow the OS instructions from there) i use debian personally, and would recommend it if you dont know or care about how to configure an operating system, but everyone will have different preferences so ultimately it doesnt matter much as long as you get a working device in the end. also, no, seriously just use linux. its obv up to you if you wanna use linux for your desktop computer, but christ do not use windows server. linux is so much better for servers that even microsoft themselves uses linux for their own servers. though yeah youre going to need to learn how to use a terminal probably? if thats difficult for you, thats fair. distrotube does some pretty helpful quickstart guides that should help you learn how to use the basic terminal commands. for this, youll basically only need to use "cd", "ls", "ssh", and "nano". youll get the hang of it.

2: install apache or nginx or whatever the fuck you decided on and read some random tutorial on how to do the basic configuration. to be clear, you should be working through ssh from here on out. this is just a software thing that lets you remotely issue commands to your server from another device, because nobody actually plugs a keyboard into their server and works on it like that unless theyre insane like me. anyways, i personally mostly followed the guidelines provided in this article on digital ocean for setting up apache on debian 11. regardless what you picked, youll do some basic settings and stuff and eventually find where you can specify the http server's root directory. it barely matters at all where you put it, but basically this is just the highest hierarchical folder in your website, the one where the index.html file goes. the other important thing that happens here is youll have to tell the webserver software what and where your ssl certificates are. exactly how to do this depends entirely on who issued your certificate and how you got it. in my case i got 3 files from my domain issuer called a "private key", "public key", and "chain file". i just had to add like 4 lines to my apache config that tell it ssl is on and where each of those files are on my server as well as what they are. this is for the most part all you need to get your ssl certification working. this whole process is basically completely different depending on the million variables that lead up to it, so you'll likely just have to do some cursory google searching yourself. try shit like "how to set up ssl on apache2 debian", shouldn't be too hard to find a helpful guide.

3: actually start making the frontend stuff for your website probably? wherever you set the root folder (i think most webservers have it default to /var/www/somedefaultfolder) just set up a file called "index.html" to be your home page. you can write it right in the terminal if you want, or you can just write it in some random IDE of your choice like notepad++ and then upload the file straight to your server either through ssh or through the web portal that your cloud server host provides. doesnt matter because at this point you now have A WEBSITE.

4: restart the website and make sure you configured everything right. if youre using a bare metal server in your home, you can now just fetch the server's local ip address and put that into your web browser and it will connect to you to the http site that you have hosted. depending on how your particular configuration works, this might not work because of the ssl not allowing that direct http connection, but it doesnt really matter ig.

5: the last thing youve gotta do is port forwarding and dns management. to be entirely honest, i have no fucking clue how this step works with cloud servers since ive never used one. for me, i port forward connection attempts to the public ip address through port 443 to my server's local ip address then go to my domain restristry and tell them to point "*.virtueisdead.xyz" and "virtuisdead.xyz" to my router's public ip. thats all for me. but yeah if youre using a cloud server it probably is completely different depending on your cloud service provider's interface. thats on you ig.

thats basically it for getting a basic web server up and public. though keep in mind that the dns servers all around the world will take upwards of 8-10 minutes to update the register your listing so you probably wont be able to use the domain for a few minutes, but it'll get there eventually.

basically all of the difficulty you'll have doing this is going to be that whatever webserver software you use will have some obnoxiously specific syntax for the configuration, like you put a / at the end of the server alias by default and that will permanently prevent any connections from going through the domain. (actually happened to me btw) so the best thing to have is just somebody who actually knows what the fuck theyre doing to ask "hey do you know why this isnt working" because, in my experience, typically for friends who are in the industry, being able to answer an extremely simple/low level question for a friend is actually a brief respite in the storm of hyperspecific bullshit they have to deal with at work every day.