I’ll write a bit in hopes to make self hosting a bit less arcane. By no means is this a guide on what you need to do, but hoping you can follow along to understand what it is that’s required.
From an absolute beginner approach, I think its easier to know that a server is just another computer. For now, let’s ignore that and think about your computer by itself. You interact through it with programs, usually through a mouse and visual interaction (graphical user interface, or GUI). Basic operating system management you can do like this: look at files in folders, delete them etc. However, you can do all of this through the terminal/command line/shell, where you enter text to do the same command. Some applications are built just for the terminal, and these are known as text user interfaces (TUIs). Try editing text through nano if you are on Linux or Mac!
A good first step as mentioned would be to test some really basic file management in whatever you are using know. Create a folder, create an empty text file, delete that text file. Just search how to create files in command line for (MY OPERATING SYSTEM). Same thing as with point-and-click, but you do the same thing with text commands. You can do pretty much every operating system thing as a text command (get creative, try connecting to wifi via the command line! open up an application that you’d normally double click!).
A server is merely a computer that you generally are running 24/7, generally running applications you don’t want your day-to-day computer to use. You actually could have a dedicated monitor and keyboard to your server and interact with it like you would your normal computer. Install Ubuntu with a desktop GUI, and it feels like like a regular computer.
Let’s say you only ever access the server from 1 computer, and its only ever running things that matter from your main computer (i.e. lets say you are running searxng locally). You might not even need a server! Just run searxng whenever you want to use it on your machine (if you are making the jump, I do recommend getting used to Docker, as its the easiest way to manage applications you plan on running on a server). This is also a good first step - can you manage to run this application on your computer. It will end up being a mini-website running your computer that only your computer talks to! You will talk to this application through a browser, and instead of www.foobar.com, you will likely enter something like localhost:8080. localhost is a fancy way to say “your own computer”, and 8080 is the port number the application is listening to (every application can choose to listen to a different port, and it can be configured). By default, most servers listen to HTTP at 80, or if its HTTPS its port 443. You can actually try this out, visit discuss.privacyguides.net:443 and it just works! The computer at the destination of discuss.privacyguides.net is listening on port 443, and you made a request to it, and it talked back. Your browser hides 80 and 443 by default as its the default. Think of it like this: discuss.privacyguides.net is the address of an apartment building and the port is which home in the apartment building you want to get to. HTTP is just how you make the destination to that apartment building - you could get their through HTTP, HTTPS, gRPC, UDP, …, but the port may only be accepting HTTP or HTTPS traffic. I’m going to glance over how a server can server you multiple different applications through a single port (i.e. how privacy guides serves both a forum and their main site through ports 80/443).
Why all the talk about HTTP? That is a protocol for two computers to talk to each other. The others I mentioned are also protocols for talking to each other, all with different capabilities and reasons to use them. Nearly every web you are accessing through HTTP/HTTPS mostly. Other things like video streaming may use UDP, but no need to worry about those for now.
However, running an application on your computer like this gets impractical for extending beyond the previous basic use case, for example
- you want to run the application once and access it on multiple devices
- you can’t run the application on your device (i.e. mobile phone)
- you can’t turn it off (i.e. running PiHole, if you turned it off, would block all internet traffic)
So instead of running it on your personal machine, you put it on a dedicated second computer which you configured to your same WiFi on the same router. Now instead of localhost, you need to find the IP address of this machine on your local area network (LAN). This is just a way to say all of the devices on your router. So let’s say your server is at 192.168.1.100, from what your router said, you now talk to the server running that application through 192.168.1.100:8080 in your web browser! Your router will see you want to talk to that IP address, forward your request to that machine, and if the application is running on port 8080 (and is setup to allow traffic to come in), it will be the same as if the machine was on your computer.
Now to manage this server you probably have tucked away, you could walk over and plug a keyboard and monitor into it and start working on it. However that gets annoying fast. Rather, you can also remotely manage this computer. To do this, most people opt for using a secure shell (SSH). This basically opens a terminal on the remote machine, but you can can access it on the same network and its prevents others from snooping on the commands you send to it (people used telnet before this, but people on the network can see the commands and snoop!). Its also possible to access a remote desktop (RDP) but that is a different setup, and most admins find the terminal just faster. Now if the application has a problem, you SSH into your server, edit the files you need, restart the application, and then test its working.
Viola - this you are now a self hosting server admin! As you access this site, its nothing more than an application running on someone else’s computer 
There are lots of way’s you can improve and keep building on it, but the key is to keep building on it rather than do it all at once. Even in this ad-hoc guide, we started with running the application on your machine, then we moved it to the second machine with a monitor and keyboard, then we removed the monitor and keyboard for SSH, then [… so on so forth to make your admin life easier]. Don’t solve everything at once, start small, get it working, then make it better. Sometimes you’ll throw away solutions and restart - that’s ok, that’s part of the learning process. Start small, test it, get it working, iterate.
I.e., I didn’t talk about reverse proxies, which solves the problem of multiple HTTP applications able to talk to the same port, which privacy guides utilize in some capacity, or configuring this in a domain registrar.
CAVEAT: I spoke NOTHING on making this secure, and just wrote this as a teaching exercise. I’ve glanced over a lot of details here, but I’m hoping this demystifies the whole process. Do NOT expose services to the world wide web unless you are prepared to handle that.