How to host websites
It took me years to get it right, how to do the hosting. This is what I wished someone would have told me at the beginning.
How do I host this blog?
You don't have to pay for every hosting. For this personal blog, the only thing that I am paying for is the domain. I pay 5 € per year for the domain. I use a next.js / react template from tailwindui.com. I use the free hosting version of vercel.com. At vercel, I just link to the GIT repository. For every commit on the repository, vercal automatically builds my website and deploys it. Meaning, I have no hosting setup or costs at all for this blog. My articles are written in markdown syntax and compiled during CI/CD automatically by vercal.
How to host other websites?
When hosting a professional websites with clients and traffic, it probably makes sense to start paying for a server.
Most server come with a preinstalled Ubuntu/Linux version. Thus, it usually makes great sense to get familiar with the file permission system at Ubuntu. It is also recommended to disable SSH access for the root user for security reasons. When writing my math PhD thesis with LaTEX, or when running my local docker containers for web-developent, I experienced that it's much faster on Linux. Thus, it may be a good idea to have Linux as an OS to learn how to manage it. If you still need Windows, read my article how to install both OS in parallel.
There are tons of articles how to setup DNS records on a VPS, how to upgrade to PHP on a plain server using SSH and terminal only. However, it is usually not needed to do this on terminal by yourself. It is much easier, to a use a tool for it.
I host my websites on a virtual private machine with a Plesk licence. I find it very convenient to use such a manager. I also don't use cloud hosting, as it is much easier for me as a single developer and administrator, then having to deal with AWS or Digital Ocean. It's also a lot cheaper.
For example, my VPS has 4 vCPU, 8 GB RAM, 250 GB NVMe SSD and unlimited traffic and 99.9 guaranteed uptime. Including the Plesk licence for unlimited websites, the costs for that are 20€ a month. Because of Plesk, its very easy to setup domains or subdomains, managing DNS records, deploy with GIT, PHP and Node.js versions handling, creating databases, external scheduled backups, cronjobs, SSH users, free SSL certificates, and recently even a Laravel hosting helper was added to Plesk.
In comparison, a VPS with a similar power but without Plesk certificate at Digital Ocean, would cost me about 50€ per month. In addition, you would probably need some software to make your life easier, like Laravel Forge which would cost between 20 - 40€ a month. Of course, the VPS on Digital Ocean will scale better then my single VPS with a licence. It's really great for setting up multiple VPS and handling them behind a load balancer. This makes especially sense, if you need multiple server across different regions. But of course, you would need to pay those 50€ per additional server and then pay for the load-balancer.
If you want to have a queue running using supervisor, having Redis or Meilisearch for full-text search, then you probably need to SSH into your VPS and install it. Those services will then be available to all applications you run at that VPS. Redis itself has some settings, so you can distinguish which app is using it and don't have to rely on different keys for example.
Another way would be to have multiple docker containers for your app, nginx, and one for every service you want to use and then managing them with Kubernetes. But it's requires a lot of effort to setup and mainting this infrastructure. I wonder if this makes really sense for single developer to go into that kind of stuff.
There are many popular CDN services out there. They cost about 20€ a month for your website. It will protect your websites from attacks and also speed up the loading time by a lot if you can use their caching. Using CDN with caching can be a much cheaper and simpler way then setting up multiple VPS on DO with a load balancer. This works best for static pages of course.
How to deploy?
Deployment is a big topic. I think everyone should use GIT to automatically deploy. When you push something to GIT, your website should update automatically. If you use Plesk, this is very easy to setup. You can also add a couple of deployment actions aswell. It would be nice to have automatic tests in your CI/CD, but that is an advanced topic. Also you probably have a build step for your composer packages, database migrations and scaffolding. An important thing is to make the deployment a zero-down-time deployment. On a single VPS, this can be done buy first installing and compiling everything in a new directory and then switching to the new version of the website using a symlink. A great tool that helps you with this task is deployer. A short article about the symlink can be found here, but I really would recommend you to read this in-depth tutorial from Loris.
If you using cloud services and have multiple VPS behind a load balancer, then you could also deploy a new VPS instance, and after the build process, update the load balancer. In this setup, its usually the best if you have a docker image that will be build on every deployment on a new VPS. But this is a very advanced devOps setup, and probably not what you looking for when you are still reading this. :)
Be prepared for the future
One thing to note is, you probably have to move all 5-10 years from your VPS. The OS on the server gets outdated, the Plesk panel gets outdated, and probably the hardware as well (in the last deceades, there was a shift from HDD to SDD for example).
Even though Plesk offers the possibility to create email accounts you should never ever do this. This is because you won't stay forever on that VPS. Instead, I recommend to buy a web hosting package and setup your emails accounts there. Most web hosting packages are very cheap and offer you 500+ mail accounts. Many web hosting packages require that the domain has to be bought and on their website and point to their nameserver. In general, I would try to find a web hosting where the domain can at least point to a different nameserver, so you can use a CDN, and just update the mail records.
After setting up the mail accounts on the web hoster, I would recommend to stay there forever, or as long as you need the email to be working. Transferring email accounts is a pain and may cause that emails get lost in the process. Alternatively, you could setup your own mail server, but this is very complicated, and you probably don't want to make mistakes here, as this could end up in having mails that end up in spam. If you want to send thousands of emails through your app, then you should not send them via your webhosting email (that's probably also limted anyway), but use a service for that, for examle mailgun. If you still want to create your own mailserver, then you also need to install a good mail client. There are free mail clients like RubeCube but they don't look that beautiful. Remaining option is to buy for a hosted mail server with great MailClient, but those aren't cheap.
For domains that don't need email, I buy a domain on the cheapest domain provider that I can find.
A price of a domain can easily vary between 5€ and 50€ per month.
If I need to have an email setup, I will buy the domain from my web hosting package.
Next, I would set the nameserver of the domain
to a CDN provider. There are many CDN provider who offer a free starting package for your domain.
Next I update the A/AAAA records of the domain to point to the VPS. This way, when moving to a new VPS server in the future, you just need to update the A/AAAA records.
One thing that often causes headache, is migration the storage folder of your application and the database. If you using a cloud service like Digital Ocean or AWS, you can host your database and your storage separately. This means, when you move your VPS, you don't have to move storage and database. This is very convenient, but hosting storage on S3 or DO spaces costs extra money. The same is true for extra hosting of the database.