What I do first on a new Linux server

Especially in the 2020’s, as corporations and for-profit companies increasingly enshittify their services and surveil us, people are discovering the benefits of self-hosting open-sourced applications and owning the digital infrastructure they depend on. For most people that probably means renting a VPS from the likes of Linode, DigitalOcean, Hetzner, or Hostinger. Being solely responsible for the administration of a server that is accessible from the internet can be a scary thought due to all the botnets that will constantly try to break into your server from the moment it goes online. Apart from the general security worries regarding having a server accessible to anyone and everyone with malicious intentions over the internet, folks who are entirely new to self-hosting might not even know how to get started and what to do after giving a VPS provider their money. In this article I describe the first steps I take on a fresh VPS. If I’m wrong or miss a crucial step, you are welcome to contact me and I’ll integrate your corrections. 🙂

Introduction#

In case you wish to skip some more introductory words and go straight to the core of this article, you can do so using the table of contents in the sidebar.

My answer to why even a non-technical person would benefit from having their own VPS is the application that is most likely useful to them: self-hosting a password manager like vaultwarden. As commercial password managers increase their prices, worsen their products by switching from platform-native applications to shitty Electron-based cross-platform applications, and increasingly introduce LLM-generated slop into their codebases, hosting your password manager yourself becomes increasingly essential. Although experienced self-hosters might self-host everything including their password manager on a spare computer in their closet, a password manager is such a mission-critical application that should be available 24/7, that you cannot afford to lose access to it and probably should prefer to host on a VPS rather than in your home.

Another good use case for self-hosting is owning your calendars and contacts rather than outsourcing them to untrustworthy Big Tech companies such as Google, Apple or Microsoft. Although VPS providers give you the option to prepare applications such as Nextcloud for that purpose for you so that you don’t have to undertake installing them yourself, I prefer starting from a blank operating system for more flexibility.

For a blank operating system, most people would probably choose Ubuntu Server. But given Canonical’s many bad decisions (such as turning Ubuntu into the "operating system for the AI agentic era" and replacing the coreutils with an immature reimplementation), and with Ubuntu’s package manager APT being significantly inferior to better package managers such as pacman, I choose a blank Arch Linux installation as the starting point for my VPS. Never fear if you think that Arch Linux is difficult to use or outside of your comfort zone, and that using APT and therefore Ubuntu would be easier. Arch gets its reputation of being difficult from its installation process: the hard part about Arch is installing it; arriving at a working operating system. Using it (once it’s installed) is no more difficult than using Ubuntu. Since the VPS provider takes care of the installation and hands you a ready-made installation of Arch, the difficult part is already taken care of for you. There’s no reason to fear Arch Linux if you’re given a ready-made, functioning installation of Arch Linux.

My configuration process#

As laid out in the introduction, the following commands assume that you have chosen Arch Linux as operating system for your VPS, not Ubuntu (Server).

Prepare SSH access#

Immediately after first spinning up your VPS, you can probably only access it via the web interface of your VPS provider. That isn’t convenient. I therefore want to access my VPS from my terminal emulator via SSH. For that I need the IP address of my new VPS and the password of the user root if you haven’t configured a SSH key in the web interface. Setting the password for the user root was probably part of the process of spinning up the VPS in the web interface.

As a prerequisite for this section you need to have created a SSH key pair on the computer that is sitting on your lap or on your table. If you don’t have one already, create a secure SSH key pair like so (after replacing the placeholder Firstname Lastname in the first line with your own name):

FIRSTNAME_LASTNAME='Firstname Lastname' &&
DETAILED_INFORMATION="${LOGNAME}@$(uname -n | cut -d '.' -f '1')_$(date -I)" &&
ssh-keygen -t ed25519 -a 100 -C "${FIRSTNAME_LASTNAME:?} (${DETAILED_INFORMATION:?})" -f ~/.ssh/id_ed25519

That code snippet adds a comment to your SSH key of the form David Culley (david@Davids-personal-Mac_2026-06-20), a naming convention I like because it shows me:

on which of my computers I created the private counterpart of the public SSH key I will copy to the VPS
the account name of the user who created the SSH key pair
the date on which the SSH key pair was created

This naming convention makes it easy to find the SSH key I need to revoke in case I lose my laptop computer.

Now, in the web interface of your VPS, find out the IP address of your VPS using this command and copy it into your notes:

ip address show

For a secure way to connect with your VPS and prevent man-in-the-middle attacks, also find out the fingerprint of the host key on your VPS. You can list which host keys are available on your VPS with this command:

ls -l /etc/ssh/ssh_host_*.pub

That command probably gave you the following output:

/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key.pub

Pick the host key that matches the type of the SSH key pair you created on your local computer. This would be ssh_host_ed25519_key.pub if you just created your SSH key pair with my command from above. Now show the fingerprint of that host key and copy it into your notes:

ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

Now is also a good moment to ensure you have the latest updates installed by entering the following command into the terminal in the web interface, even though your VPS provider just spun up the server from a template:

pacman -Syu

For more convenience, edit the file ~/.ssh/config on your local computer and add the following to the top (or above the line Host * if it exists in your configuration), but replace the placeholder IP_ADDRESS with the real IP address returned by the command ip address show:

Host IP_ADDRESS vps
    HostName IP_ADDRESS
    Port 22
    User root
    IdentityFile ~/.ssh/id_ed25519

You’ll see later why I do this.

Now, since you provided the user name (root) as well as the alias vps in your configuration, you can simply type the following command on your local computer to connect with your VPS:

ssh vps

Because this is the first time you connect to your VPS via SSH and you don’t yet have its host key in your ~/.ssh/known_hosts file, the command-line interface will ask you to type either yes or no or enter a fingerprint. Most people simply type yes, but this is insecure and leaves you vulnerable to man-in-the-middle attacks. Remember the fingerprint you determined above with the command ssh-keygen and copied into your notes? Now is the time to copy it into your clipboard and paste it into the terminal. The SSH connection to your VPS will only be established and your VPS will only be added to the list of your trusted servers if the fingerprint of the host key on the server you’re trying to connect with, matches the fingerprint you just pasted into the terminal.

Because you haven’t yet copied your public SSH key from your local computer to the VPS, you will be prompted for the password of the user root unless you already provided your public SSH key in the web interface of your VPS provider. For now I’ll log into the VPS by entering the password of the user root. I’ll secure the login via SSH in a later step.

Now you should be logged into your VPS from your local computer’s terminal emulator and you don’t need the inconvenient web interface of your VPS provider anymore.

The next thing you should do is to create a user account with less permissions than the almighty user root.

Create non-root user account#

There are two common ways to create a user account:

the high-level abstraction adduser that is pre-installed on Ubuntu but not on Arch, that is supposed to guide you through the user creation process
the underlying program useradd that I prefer on Arch because it doesn’t require an additional installation

Before we create our user, let me briefly explain some ideas that will make the following command clearer.

It’s recommended practice to operate as a non-privileged user and heighten your privileges only when you need them, using the command sudo, instead of operating as the privileged user root all the time. For that to work, you need to add your user to a specific group. On Ubuntu, that group is sudo. On Arch, that group is wheel.
Furthermore, I don’t want to use bash as my shell. Although you should learn its syntax for scripting, it’s not a great shell for everyday usage and entering commands into your terminal emulator. Although zsh is a great improvement over bash for interactive usage thanks to its plugins and great community, I also don’t recommend zsh if you haven’t already invested hours of your lifetime into configuring it. I recommend fish for your everyday shell, which does out of the box what requires multiple plugins if you use zsh. Since fish isn’t pre-installed on Arch, unlike bash, we’ll have to install fish before the following command to create a user will work.

I will name my new user david. It’s my personal machine with only me using it. It’s not a shared machine where multiple users might be named David and where a naming convention like dculley might make more sense. It’s a good practice to provide your full name as a comment because, to the administrator of a server (you, in this case), it’s not always clear from the account name alone who needs to be contacted in case of an issue if the account name doesn’t provide the full name as, for example, david, or dculley or even just dcu. In the case of your own personal VPS, setting this comment doesn’t matter, but if you learn to do something, you might as well learn to do it properly.

Ensure that your preferred shell is installed, whether that is fish or zsh. Be sure to replace the placeholders firstname and Firstname Lastname in the highlighted lines with your own name.

PREFERRED_SHELL=fish &&
pacman -S ${PREFERRED_SHELL:?}

FIRSTNAME_LOWERCASE=firstname &&
FIRSTNAME_LASTNAME='Firstname Lastname' &&
useradd --create-home --groups wheel --shell /usr/bin/${PREFERRED_SHELL} --comment ${FIRSTNAME_LASTNAME:?} ${FIRSTNAME_LOWERCASE:?}

That code block should have resulted in two commands, similar to pacman -S fish and useradd --create-home --groups wheel --shell /usr/bin/fish --comment 'David Culley' david. The reason why I didn’t state the command plainly like that is that, in my experience, I have seen too many people blindly copy-pasting commands no matter how often you remind them to replace placeholders. And I don’t want you to create an account with my name instead of yours. 😉

Now you need to set a strong password for your new user account like so, but of course using your own name:

passwd david

Your new user cannot yet heighten its privileges with sudo. It has been added to the group wheel, but the group wheel hasn’t yet been allowed to use sudo. We’ll fix that now.

First, install your preferred text editor. Mine is Neovim.

pacman -S neovim

In case you aren’t comfortable using Vim/Neovim, proceed with the default text editor like so:

visudo

Otherwise, use the text editor you just installed by setting SUDO_EDITOR:

SUDO_EDITOR=nvim visudo

Either way, uncomment the following line (by removing the #):

%wheel      ALL=(ALL:ALL) ALL

While you’re in that file /etc/sudoers, you can seize the opportunity to make your preferred text editor the new default by adding the following line anywhere in the file:

Defaults editor=/usr/bin/nvim

I like to add it under the section ## Defaults specification somewhere around line 44.

After exiting that file, ensure that your new user can execute sudo:

su - david
sudo pacman -Syu

The first time you execute sudo, you’ll be lectured about your responsibility, but after that you’ll never be bothered again.

If sudo works, execute the exit command twice, once to log out as david and once to log out as root:

exit

On your local computer, open the file ~/.ssh/config again and replace root with your new user’s account name (david in my case):

Host IP_ADDRESS vps
    HostName IP_ADDRESS
    Port 22
    User david
    IdentityFile ~/.ssh/id_ed25519

On your local computer, ensure you have the tool ssh-copy-id installed and execute these two commands:

ssh-copy-id -i ~/.ssh/id_ed25519.pub vps
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@vps

Now check the file ~/.ssh/authorized_keys on your VPS for both root and your non-privileged user and verify that the public SSH key was copied from your local computer to the VPS. For both code snippets, you should see the comment with the naming convention from above at the end of the line, or whatever comment you have set if you used a pre-existing SSH key rather than my command from above.

ssh root@vps
cat ~/.ssh/authorized_keys
exit

ssh david@vps
cat ~/.ssh/authorized_keys

You just saw a good reason for why you should specify your hostname as comment and not your email address as is so often recommended. Imagine connecting to your VPS from both a laptop and a desktop computer, and having specified only your email address in both cases. How would you know which public SSH key comes from which of your computers?

Next up is securing the VPS by requiring SSH keys to log in via SSH. For that we will disable logging in via SSH by providing the password. We will also prevent logging in as user root altogether to enforce logging in as the non-privileged user.

Edit the file /etc/ssh/sshd_config with the following command:

sudoedit /etc/ssh/sshd_config

You will often see commands like sudo nano /etc/ssh/sshd_config or sudo nvim /etc/ssh/sshd_config. Never combine a text editor command with sudo. The command sudoedit exists for that purpose. Everything else is dangerous. Since we previously made our preferred text editor permanent, sudoedit is now equivalent to sudo nvim in my case.

Some of the following settings might also be uncommented in addition to changing their values:

Find the line containing PasswordAuthentication and change its value to no. This enforces SSH keys because it disables password login.
Find the line containing PermitRootLogin and change its value to no. This disables logging in via SSH for the user root. We want to log in as david and then use sudo, or become root with su - if need be. The value without-password is a deprecated alias for prohibit-password.
Find the line containing KbdInteractiveAuthentication and change its value to no. It replaces the deprecated alias ChallengeResponseAuthentication.
Add the line AllowUsers david anywhere in the file. Obviously replace david with your own user name. Now david is the only accepted user which further increases security.
Find the line containing UsePAM and change its value to no. It’s required in corporate environments for policies that force you to regularly change your password, but on personal servers the additional complexity isn’t worth it.
Optionally find the line containing Port and change its value from 22 to any arbitrary four-digit value, like 2222. But don’t use 2222 because if everyone now uses 2222 you might as well keep using 22. The point of changing this setting is obfuscation.

Depending on your VPS provider, you might need to repeat the previously outlined steps if there are files in the directory /etc/ssh/sshd_config.d/ that would override the settings you just made in the file /etc/ssh/sshd_config. List all files that exist in that directory and delete those files if you know what you’re doing or make the same changes to them:

ls -l /etc/ssh/sshd_config.d/

For even more security, establishing a SSH connection to your VPS should ideally require a VPN tunnel (Wireguard) between your home router and your VPS, or something like Tailscale, but this is out of scope for this particular guide about recommended first steps on a fresh VPS.

Now restart your SSH daemon on your VPS:

sudo systemctl restart sshd

If you chose to change the port for SSH from 22 to something else, open the file ~/.ssh/config on your local computer again and change the port to that same arbitrarily chosen number:

Host IP_ADDRESS vps
    HostName IP_ADDRESS
    Port 2222
    User david
    IdentityFile ~/.ssh/id_ed25519

On your local computer, open a new tab or window in your terminal emulator and see if SSH login still works:

ssh vps

The reason you should open a new tab instead of logging out and back in again in the existing tab is that, in case SSH doesn’t work anymore, you’re still logged into your VPS in one tab and can make the fixes that allow you back in.

If you could successfully log back into your non-privileged user (david in my case), continue with the next steps.

Change hostname#

The hostname of your computer is what is shown in your shell prompt, among other places. Let’s change it to something more meaningful so that you can see in your terminal emulator whether a command will be executed on your local computer or via SSH on the VPS.

There are three kinds of hostnames:

static
transient
pretty

The transient hostname will always be identical with the static hostname, unless there are two (or more) computers with the exact same static name in the network. The static name mustn’t contain spaces or fancy characters. It’s the name shown in your shell prompt. The pretty hostname allows spaces and fancy characters and is what would be shown in a GUI.

I’m boring and simply name my computers davids-personal-mac, davids-work-mac, davids-arch-laptop, davids-vps, or hetzner-vps if you rent from different providers. Other people use more eccentric names. The static hostname is also how your computer introduces itself to other computers on the same network, so choosing an unspecific static hostname like work-mac would almost surely conflict with another MacBook in my employer’s network, thereby changing for one of us the transient hostname to work-mac-1 to remove ambiguity.

If you own a domain (like davidculley.com in my case), it’s good practice to append your domain to your hostname. If you don’t own a domain, it’s good practice to append .localdomain to your hostname. Don’t append .local to your hostname, even though you often see other people doing it. That TLD is used by multicast DNS (mDNS). Using it for regular/unicast DNS too will cause ugly network problems.

There are multiple ways to edit your hostname. The simplest way on Arch Linux is probably the command hostnamectl. Replace davids-vps with the name you want to see in your shell prompt and replace localdomain with something like davidculley.com if you own a domain, otherwise leave it as localdomain. Since I configured my account to use the fish shell instead of bash, setting variables looks a bit different from what you’re familiar with:

set YOUR_HOSTNAME 'davids-vps' &&
set YOUR_DOMAIN 'localdomain' &&
sudo hostnamectl hostname --static --transient $YOUR_HOSTNAME.$YOUR_DOMAIN

In my case that code block resulted in the command sudo hostnamectl hostname --static --transient davids-vps.davidculley.com. Set the pretty hostname similarly and restart the shell afterwards to activate the changes. Replace my name with yours.

set YOUR_PRETTY_HOSTNAME 'David’s VPS' &&
sudo hostnamectl hostname --pretty $YOUR_PRETTY_HOSTNAME &&
exec $SHELL

The command used to be hostnamectl set-hostname, but systemd version 249 changed that to just hostnamectl hostname. The old command still works but is deprecated and shouldn’t be used anymore.

The following step is probably unnecessary on a VPS, but it’s a good practice on desktop computers and laptops. Replace my names in the highlighted line with yours:

set YOUR_LONG_AND_SHORT_HOSTNAMES 'davids-vps.davidculley.com    davids-vps' &&
echo "127.0.1.1       $YOUR_LONG_AND_SHORT_HOSTNAMES" | sudo tee -a /etc/hosts

You can check for both your fully-qualified domain name (FQDN) and just the hostname whether your VPS is reachable. Replace the names with your own:

bash

YOUR_HOSTNAME='davids-vps' &&
YOUR_FQDN='davids-vps.davidculley.com' &&
ping -c 1 ${YOUR_HOSTNAME:?} | grep --extended-regexp --only-matching '[[:digit:]]+% packet loss' &&
ping -c 1 ${YOUR_FQDN:?} | grep --extended-regexp --only-matching '[[:digit:]]+% packet loss'

You want to see 0% packet loss twice.

exit

In case you’re having issues, a reboot of your VPS—the first since you created it—might be a good idea at this point, since we’ve had to make quite a few deep-reaching changes to our VPS during this early stage of configuring it:

sudo reboot

From your local computer, you should be able to log back in within the next minute or two:

ssh vps

You can use this forced pause to make yourself a cup of coffee if you want. 🙂

Change timezone#

Once you’re back in, let’s set the timezone to your country’s timezone. The simplest way to do that on Arch Linux probably is using the command timedatectl set-timezone. I live in Germany, so for me the appropriate value to set is Europe/Berlin.

sudo timedatectl set-timezone Europe/Berlin

You can find the value you need for your country by listing all available timezones like so:

timedatectl list-timezones

After setting your timezone, you can verify the time with these commands:

timedatectl status # identical with just 'timedatectl'
date

On a virtual server the next step is probably unnecessary, but if you’re self-hosting on a physical machine, you should set the mainboard’s hardware real-time clock to the time you "downloaded from the internet" (via the NTP):

sudo hwclock --systohc

The output of timedatectl status should show:

active for NTP service
yes for System clock synchronized
RTC time being identical with either Local time or Universal time depending on whether RTC in local TZ says yes or no

Configure UFW#

A firewall protects your VPS from the scary internet where malicious hackers and random scriptkiddies lurk. But firewalls such as iptables or nftables can be very complex. The Uncomplicated Firewall (UFW) acts as an uncomplicated frontend and handles all the heavy lifting for you.

Ensure that UFW is installed:

sudo pacman -S ufw

Before you configure your firewall, you should probably do another reboot to avoid cryptic error messages, just in case …:

sudo reboot

ssh vps

If you followed the optional step to change your SSH port to something other than 22, execute the following code:

set YOUR_NEW_SSH_PORT 1234 &&
sudo ufw default deny incoming &&
sudo ufw default allow outgoing &&
sudo ufw deny 22 &&
sudo ufw limit $YOUR_NEW_SSH_PORT

If you didn’t change the SSH port, execute the following code:

sudo ufw default deny incoming &&
sudo ufw default allow outgoing &&
sudo ufw limit 22

This is a very simple configuration that already protects you very well. More complex configurations are out of scope for this guide.

Either way, enable the firewall now with this command:

sudo ufw enable

In case you’re an experienced server administrator and want to share your UFW rules with me, I’d be happy if you contacted me. 🙂

Configure Fail2ban#

Configuring a firewall together with all the other steps described so far in this guide should already give you pretty good protection. You can in good conscience use your server without Fail2ban and enable it only if you find you need it. I therefore consider it out of scope for this particular guide. If you want me to add it, contact me and I’ll consider adding it to this guide.

Change mirror list#

My VPS is located in Germany, so it makes more sense for me to download updates from German servers rather than from servers on the other side of the globe. This is an optional optimization for faster downloads. If you want that, you need to edit your mirror list. I do that using the tool reflector. Be sure you have reflector installed and then list all the countries you can choose from:

sudo pacman -S reflector &&
reflector --list-countries

You can search for a particular country (for example, Brazil) with the following command:

reflector --list-countries | grep --ignore-case brazil

In the following command, you can use either the name or the code of the country (Germany or DE in my case).

According to the Arch Wiki, the following command to change your mirror list makes sense only if there are more than 5 mirrors in your specified country. If the count for your country is lower than 5, skip the following command:

set YOUR_COUNTRY Germany &&
sudo reflector --country $YOUR_COUNTRY --latest 5 --sort rate --protocol https --save /etc/pacman.d/mirrorlist

If you want, you can inspect the optimized mirror list like so:

cat /etc/pacman.d/mirrorlist

Create SSH key pair#

To be able to download code—for example, your dotfiles—from git forges (such as GitHub or the much better Codeberg) to your VPS in a secure manner, you want a SSH key pair on your VPS, not just one on your local computer. Don’t copy the one you have on your local computer over to your VPS. Create a new one on your VPS. You can reuse the command from the beginning of this guide to create the key pair, but you’ll have to start a bash shell within fish, since fish doesn’t accept the syntax in that specific code snippet.

bash

Now you can paste the command into your bash subshell. Here it is again for your convenience:

FIRSTNAME_LASTNAME='Firstname Lastname' &&
DETAILED_INFORMATION="${LOGNAME}@$(uname -n | cut -d '.' -f '1')_$(date -I)" &&
ssh-keygen -t ed25519 -a 100 -C "${FIRSTNAME_LASTNAME:?} (${DETAILED_INFORMATION:?})" -f ~/.ssh/id_ed25519

Execute exit to leave the bash subshell and return to fish:

exit

Copy your newly created public SSH key into the web interface of your git forge (for example, GitHub) as you normally would. Then you can clone git repositories as you normally do, after ensuring that git is installed.

Bonus: Configure `fish` abbreviations#

In case you’re new to Arch Linux, it takes a while to get used to its package manager pacman and to memorize its unintuitive commands. Ubuntu’s APT commands (for example, apt update or apt upgrade) are certainly more intuitive than their pacman counterparts (in this example, pacman -Syy and pacman -Syu).

One feature of fish that I love is its unique abbreviation system. It can help you with those strange pacman commands. Copy my recommended abbreviations into the file ~/.config/fish/conf.d/abbreviations.fish by executing the following script (in a bash subshell, since fish doesn’t accept the heredoc syntax << EOF … EOF that I use in the script):

bash

cat << EOF >> ~/.config/fish/conf.d/abbreviations.fish
abbr --add pm --command=sudo pacman
abbr --add pacman-install --command=sudo --regex 'i(?:nstall)?' -- -S
abbr --add pacman-search --command=sudo --regex 's(?:earch)?' -- -Ss
abbr --add pacman-uninstall --command=sudo --regex 'uninstall|un?i' -- -R
abbr --add pacman-update --command=sudo --regex 'update|up?d' -- -Syy
abbr --add pacman-upgrade --command=sudo --regex 'u(?:pgrade)?|up?g' -- -Syu
EOF

Return to fish:

exit

Now you can simply type sudo pacman install or even just sudo pm i instead of having to remember sudo pacman -S.
You can simply type sudo pacman search or even just sudo pm s instead of having to remember sudo pacman -Ss.
You can simply type sudo pacman uninstall or even just sudo pm ui or sudo pm uni instead of having to remember sudo pacman -R.
You can simply type sudo pacman update or even just sudo pm ud or sudo pm upd instead of having to remember sudo pacman -Syy.
You can simply type sudo pacman upgrade or even just sudo pm ug or sudo pm upg or sudo pm u instead of having to remember sudo pacman -Syu.

Once you experienced this feature for yourself (and all the other awesome features of fish), you’ll see why I recommended fish over zsh, even if it sometimes requires different syntax than the one you’re used to from bash, or opening a bash subshell if you don’t want to adapt the syntax to fish.

Final words#

Congratulations! That was quite some work, but now you have a secured VPS that is both accessible from the internet and, despite that, not vulnerable to most attacks. You have a secure and convenient SSH configuration, you avoided all the deprecated commands and settings, you have a pretty hostname, everything (including your user account and SSH key pairs) is neatly commented, and you use the user-friendly shell fish which has a slightly different syntax in some regards than bash, but I’m sure you’ll appreciate fish very quickly if you give it a chance.

Executing the commands as such takes a lot less time than the length of this article might suggest. In our day and age of enshittification and increasing surveillance, I wanted to ensure that even relative beginners can gain independence from Big Tech corporations, not just the seasoned (Arch) Linux neckbeards. I therefore was much more elaborate than strictly necessary and didn’t just provide a list of commands but provided a lot of context and explanations. Nobody who would like to become independent and self-host but doesn’t yet have the necessary technical skills should be left behind, even though I didn’t explain how to use text editors such as nano or vim. I even took some measures to prevent careless copy & paste mistakes that admittedly made the commands more complex than they need to be but hopefully added some robustness to reduce the number of support requests. Let me know if you appreciate that or if that was more hindering than useful.

With both Windows and the most mainstream Linux distribution (that is, Ubuntu) becoming worse with every update, I chose to describe my process using Arch Linux rather than what most people feel more comfortable with (that is, Ubuntu). Nobody should be forced to stick with the inferior package manager APT just out of an unfamiliarity with the unknown that is Arch Linux. Hopefully it became clear throughout the article that using Arch (after it’s been successfully installed) isn’t (much) more difficult than using Ubuntu, at least after my fish tricks. By daring to choose the Arch Linux template for your blank operating system rather than the familiar Ubuntu Server, you gained some experience using the superior package manager pacman and one day you might feel confident enough using Arch to try installing Arch yourself from scratch. Until then, your limited experience with Arch doesn’t force you to remain stuck with Canonical’s objectively worsening Ubuntu on your VPS as Canonical is dead set on making Ubuntu the "operating system of the agentic era".

As I wrote in the introduction, if you know how I could improve my process, I hope you will contact me. 🙂