Recently, I set up my first virtual private server (VPS) for hosting my websites and applications. Chances are quite high, the webpage you are looking at right now is served by this server. After some research, I decided to go with Strato as my hosting provider. My friend Codie suggested them to me and they have great prices and all the options I would need. The setup process turned out to be quite straightforward, but I wanted to document the steps I took to make it easier for future reference and maybe help others who are embarking on a similar task.

This guide covers the complete setup from initial server provisioning to having a fully functional development environment with SSH access, user management, and basic web server configuration. Let's dive into the details!

Depending on your use case you want to carefully select the hardware for your VPS. If can either choose to set up a VPS which has more than enough power for your services and pay more or you could pay less but have the risk of running into hardware bottlenecks. 

Personally I went for a STRATO VPS Linux VC4-8, which has 4 cores, 8GB of RAM and 240 GB of storage. I pay 6 EUR/month for it and I think that's quite the steal. Hardware-wise it can handle small to medium tasks. It's definitely an overkill for just hosting a private website but you could run other services on it. Like I run my analytics tool called umami on there (blogpost: [here](https://manuel-ramsaier.com/blog/setting-up-your-own-google-analytics-umami)). I would refrain from e-mail hosting though. Tried it, it sucks.

Initial Server Setup and SSH Configuration

The first step in setting up any VPS is getting secure SSH access. I started by generating the necessary SSH keys using PuTTYgen to get the public key in the right format for the initial server installation. This was necessary as my ssh key was in the wrong format and the Strato Setup process did not recognize it at first.

Once I had initial access, the next crucial step was creating a new user account. Running as root is never a good practice, so I set up a dedicated user for my daily operations.

Creating a New User and Setting Up SSH Access

Here's the sequence of commands I used to create and configure the new user:

Security is paramount when setting up a server. One of the first things I did was change the default SSH port to reduce automated attack attempts.

On the client side, I edited the SSH config to have a more convenient connection setup. This makes it much easier to connect to the server without remembering IP addresses and ports every time.

This simple change can significantly reduce the noise from automated bots trying to brute force their way into your server.

UFW (Uncomplicated Firewall) is a nice way for managing iptables firewall rules on Linux systems, designed to simplify the process of configuring a secure network. So I block all by default and just allow the ports I want to allow. This would be the port 443 for ssl, port 80 for certbot and also my custom ssh port obviously (be **careful** not to lock you out of ssh). A custom way of ufw settings could look like this (custom ssh port: 2222):

With secure access established, it was time to set up a proper development environment. I went with my preferred tools and configurations:

This installs [git](https://git-scm.com/), [ohmyzsh](https://ohmyz.sh/) and [uv](https://github.com/astral-sh/uv) (my favorite package manager for python since poetry).

For Node.js development, I installed the latest stable version using the Node Version Manager (n):

I also installed the GitHub CLI for easier repository management and nginx for web serving capabilities:

Next, we will explore the services used for serving you website. I chose to go with [next.js](https://nextjs.org/) which is a react framework by vercel. This makes me sleep easy at night as I know that if the demand for my frontend grows too much, I can deploy easily to vercel and be done with it. For this website with almost only static content I think it is not a problem to worry about right now. 

So we will dive into Nginx, Certbot, systemd and a bit of shell scripting to launch your service in production or development mode.

Nginx, Certbot, and Next.js Configuration

Nginx (pronounced 'engine-x') is a powerful web server and reverse proxy that acts as the front door to your web applications. Think of it as a traffic controller that sits between your users and your actual application server. Here's what nginx does for your setup:

In my setup, nginx receives all incoming HTTP/HTTPS requests and forwards them to my Next.js application running on a custom port (I like to keep 3000 clean). This separation of concerns is a best practice - nginx handles web server duties while your application focuses on business logic.

Here's the nginx configuration I use for my website. I'll explain each section and provide a template you can adapt for your own domain:

Let me break down the key components of this configuration:

The `server_name` directive tells nginx which domain this configuration applies to. Replace `YOUR_DOMAIN.com` with your actual domain name.

The second server block at the bottom of the fileredirects all HTTP traffic to HTTPS for security. Only allow for HTTPS traffic to reach nginx.

The `location /` block handles all incoming requests and forwards them to your application:

The security headers protect against common web vulnerabilities:

I really love the ease of use of certbot. You just run it with the nginx flag enabled and you are good to go. Remember though, that you should check your renewal setup as the certificates once expired pretty much make your service unavailable. It cannot be reached anymore. 

Systemd is the service manager in modern Linux distributions that handles starting, stopping, and managing system services. For your web application, you'll want to create a systemd service that automatically starts your application on boot and restarts it if it crashes.

Here's the systemd service configuration I use for my Next.js application:

The systemd service calls a startup script that handles the application lifecycle. This script manages dependencies, builds the application, and starts it in the correct mode. Here's the `start.sh` script I use:

This script provides several important functions:

The script accepts a mode parameter (`dev` or `prod`) to determine how to run the application:

The script loads NVM to ensure the correct Node.js version is used, which is crucial for consistent application behavior.

In production mode, the script verifies that the build was successful by checking for the `.next` directory before starting the server.

Make sure your `start.sh` script is executable:

Setting up a VPS from scratch can seem a little bit much at first, but with the right approach and tools, it becomes quite manageable. 

Set up a new Virtual Private Server (VPS)

Hosting your own Google Analytics (Umami)

I recently saw  a post on X, where a user said how fascinated he was when switching from the not particularily user friendly UI of Google Analytics to an open source alternative called [Umami](https://umami.is/). My experiences with Google Analytics are limited but as I saw Umami being GDPR compliant by default (more info: [Umami FAQ](https://umami.is/docs/faq)), I wanted to give it a shot. 

Btw, Umami means **delicious savory taste** and originates from Japan where it was identified in 1908. Almost a century later, In 2002, it has been discoverd that the human tongue can distinctively taste umami besides the four typical tasts: sour, bitter, sweet and salty. Now let's get a taste of Umami Data Analytics.

Still new to all this, I checked the website first to get an impression. The data analytics platform offers: 

This sounds like exactly what I was hoping to get from a data analytics platform, so I went ahead and checked out the [GitHub Repository](https://github.com/umami-software/umami). Give it a star, if you decide to use it!

It's not such an obvious choice to me. Self hosting is great and all but the Umami Cload offers some generous Free Tier usage. 

So, to be fair, this for now seems absolutely enough for me and I would have gotten around some of the headache I describe further down below. But I also wanted to face this challenge and to try self hosting it. It is always good to know if you scale beyond the Free Tier if you have an easy route for self hosting vs. vendor lock-in. So, self-hosting it is!

Whenever I start to try out a new tool on my VPS (Virtual Private Server), I especially look for a uninstall.sh or a docker image. I burnt myself too often not to think about the way back before installing something on the machine which serves my homepages / SaaS. So I was pleased to see a docker image to use. 

Technically, it sounded straightforward. Change a few things in the docker-compose.yml file and spin it up. But as always, I got to do some preparations first:

Having set up all this I was happy to see the login screen on my custom domain. But this is where things turned South.

I was hit in the face with this error message, when trying to login with the default user:

This took a bit for me to resolve but I finally found the reason: The Cloudflare Proxy threw a Challenge via .html and Umami expected to get a JSON response. This was more obvious when I looked into the developer console.

I then changed the DNS entry for the umami subdomain to DNS only and voila, it worked. 

Now with the setup complete, I could finally add my webpage to my Umami Server. When you add a site to the dashboard, a unique ID will be assigned and you can get a code block to include on your webpage like so: 


The tracking code (*0cfe30f8-1b8e-47e1-8f3c-f5327c86fbd1*) allows umami to identify which webpage it was sent from. It is unique for every homepage. As most of my websites use next.js, you have to find a good place where to include this. One good option is the **_app.tsx** component. There wrap it into a Script (from next/Script) component and you are good. Make sure to deactivate extensions like *uBlock Origin* when you test it. Pay close attention to the *network tab* and you will see the request sent to your subdomain. 

The interface / dashboard looks clean, minimal and I like it very much. It works quite good and I am still at the beginning of getting to know all the functions / ways to analyze the data. So I will update this post when I have some more mileage in with this tool. So far I can fully recommend doing this. 

Set up a new Virtual Private Server (VPS)

Setting up your own Google Analytics (Umami)