Learn Linux on a VPS: A 30-Day Plan From First SSH Login to DevOps

You can learn Linux on a VPS from your very first command, and for server skills it's the better classroom. A VPS (virtual private server) is a virtual machine you rent in a data centre, with its own public IP address, so strangers start guessing its passwords within minutes of boot. That's unnerving the first time, but every attempt lands in a log you'll learn to read in week 3. Here's a 30-day plan for absolute beginners: one small exercise a day on Debian 13, with notes where Ubuntu 24.04 or 26.04 differs. Break something? Reinstall and carry on.

The short answer: 1 GB of memory carries you through the first three weeks, and 2 GB adds Docker, Ansible and RHCSA practice. The order that prevents lockouts is sudo user, SSH key tested in a second window, a firewall rule for SSH, firewall on, then passwords off. The public IP is the point, because real login attempts land in your logs, and a laptop VM can't give you that. After the basics come an exam track (LPIC-1, LFCS or RHCSA) and a first taste of git, Docker, Ansible and Terraform.

Why learn Linux on a VPS and not a laptop VM?

Because admin work happens over a network, and a laptop VM hides from it. In VirtualBox's default NAT mode (network address translation), the manual calls the VM "invisible and unreachable from the outside internet"; WSL 2 is behind NAT by default too. Fine for learning commands, useless for learning what the internet does to a server.

The internet shows up fast. On a fresh 8 vCPU, 16 GB server we set up for this guide, the first SSH password guess arrived less than six minutes after boot, and 78 minutes in the log held 261 failed logins from 7 addresses. In 2021, Palo Alto Networks' Unit 42 put 320 honeypots (deliberately weak decoy servers) on public clouds: 80% were compromised within 24 hours, and the busiest SSH honeypot was broken into 169 times in one day. A three-year study of 221 honeypots in 55 countries, presented at ACM IMC 2025, logged about 258 million failed-login sessions. The authors note that disabling password logins can effectively mitigate these attacks, yet brute-force guessing is still everywhere. That's your week 2.

Older tutorials still send beginners to Play with Docker, the browser playground. Its hosted labs closed on 1 March 2026, after about ten years.

1 GB or 2 GB? Sizing the lab server

1 GB of memory until containers arrive, 2 GB for all 30 days. Debian's installation guide recommends 1 GB for a system without a desktop, and Red Hat lists 1.5 GiB as the minimum for RHEL 10, which AlmaLinux 10 and Rocky Linux 10 rebuild.

RS Computers servers are KVM virtual machines in Amsterdam (Netherlands), Prishtina (Kosovo) and Dublin (Ireland). The plans page has the same plans and prices in all three cities. For a lab, KVM matters because each server boots its own kernel (the heart of the operating system), so systemd and Docker behave as they would on a physical machine. Every plan has NVMe storage, its own IPv4 and IPv6 address and unmetered traffic, on a 1 Gb/s port for VPS plans and 10 Gb/s for VDS. Debian, Ubuntu, AlmaLinux and Rocky Linux are available; Windows Server only on VPS Mini and the VDS plans. The client area restores the free weekly backups and handles upgrades. It also has a web console, your way back in after a firewall mistake.

Week 1 (days 1 to 7): get in and stop being root

Root is the all-powerful admin account, with no safety catch. Type the commands. Don't paste them.

Day 1: SSH from Windows PowerShell, a Mac or a phone

SSH (Secure Shell) is the encrypted remote terminal admins live in. Microsoft has offered OpenSSH as a Windows feature since Windows 10 build 1809; in PowerShell, ssh -V should answer with OpenSSH_for_Windows. If "ssh" is not recognized, this adds the client from a PowerShell opened as administrator:

# as the local user, in PowerShell opened as administrator
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

It answers with Online : True and RestartNeeded : False. Macs have ssh in Terminal already. On Android, install Termux from F-Droid (its Play Store build is marked experimental) and run pkg install openssh; on an iPhone, try Blink Shell or Termius. Now connect with the root login you received:

# as the local user, on your computer or phone
ssh root@YOUR_SERVER_IP

Type yes to accept the server's fingerprint, its ID card. The password stays invisible while you type. Normal. A prompt ending in # means you're in.

Exercise: cat /etc/os-release should name Debian GNU/Linux 13 (trixie). Log out with exit and back in until it's boring.

Day 2: Update everything with apt

apt is Debian's package manager. Refresh the package list, then install every update:

# as root
apt update
apt full-upgrade

Press Enter at the [Y/n] question. A second apt update ends with All packages are up to date. On Ubuntu 24.04, which updates itself in the background, a Could not get lock message mentioning unattended-upgr means wait a few minutes; never delete the lock file. Our Debian 13 template doesn't update itself until you set that up on day 12.

Exercise: apt install htop, run htop, quit with q.

Day 3: Your own user, with sudo

sudo lets a normal user run single commands as root. Create the user student (keep the name; later commands use it) and add it to the sudo group:

# as root
apt install sudo
adduser student
usermod -aG sudo student
id student

apt answers that sudo is already the newest version; our template includes it. adduser asks for a password twice. Make it long and unique: password logins stay open until day 11, and the bots from the intro will be guessing. Then come details you can skip with Enter. id must show (sudo); without the -a, -G would replace the user's groups. In a second window, log in with ssh student@YOUR_SERVER_IP and run sudo whoami: after student's password, it prints root. If you see student is not in the sudoers file, rerun usermod as root and log in again, since groups apply at login.

On Ubuntu 26.04, sudo is sudo-rs, a rewrite in the Rust language, and it shows a star for each character of the password you type. The commands are the same; only the missing-group error changes, to I'm sorry student. I'm afraid I can't do that.

Exercise: close the root window. You're student now.

Day 4: Files and folders

Linux is one tree of folders starting at /, and your home is /home/student, or ~. Find out where you are, list everything, make a folder and open a file in the nano editor:

# as the student user
pwd
ls -la
mkdir lab
cd lab
nano notes.txt

Type a line, save with Ctrl+O and Enter, exit with Ctrl+X. cat notes.txt prints it back.

Exercise: copy the file with cp, rename the copy with mv, delete it with rm. There's no recycle bin.

Day 5: Permissions

Each file has an owner, a group, and read, write and execute rights (r, w, x) for the owner, the group and everyone else. Run chmod 600 ~/lab/notes.txt to make your notes private, then ls -l ~/lab: the line now starts with -rw-------, meaning only you read and write. 6 is read plus write, 7 adds execute, 0 is nothing.

Exercise: run sudo chown root:root ~/lab/notes.txt, then cat ~/lab/notes.txt: Permission denied, in your own folder. Undo it with sudo chown student:student ~/lab/notes.txt. Wrong permissions are exactly what break SSH keys next week.

Day 6: What is the machine doing?

Five read-only commands: df -h for disk space, free -h for memory, ip a for addresses, ss -tulpn for listening ports (expect SSH on 22 and little else) and top for live processes, closed with q. The ifconfig of old tutorials isn't installed on Debian 13.

Exercise: find your public IPv6 address: the inet6 line marked scope global in ip a.

Day 7: Review from memory

Exercise: nothing new. From memory, create test2, give it sudo, check it with id, and remove it with sudo deluser --remove-home test2. If deluser says it needs the perl package, run sudo apt install perl and try again. Note what you had to look up.

Week 2 (days 8 to 14): lock the front door

Order matters more than commands. Keep one SSH window open throughout. Allow SSH before the firewall goes on. Test each new login in a second window before closing the first. Run sudo sshd -t before every SSH reload.

Day 8: Make an SSH key

An SSH key is a pair: a private key that never leaves your device and a public .pub key you put on servers. Make one on your own computer:

# as the local user, on your own computer
ssh-keygen -t ed25519 -C "my-laptop"

Press Enter for the default location, then set a passphrase. id_ed25519 and id_ed25519.pub appear in the .ssh folder of your home folder. Ed25519 has been ssh-keygen's default since OpenSSH 9.5.

Exercise: open the .pub file: one line starting with ssh-ed25519. It's the only key file you ever copy.

Day 9: Copy the key (and the Windows workaround)

On a Mac, Linux or Termux, this adds your public key to the server's ~/.ssh/authorized_keys, the list of keys allowed in:

# as the local user, in Terminal or Termux
ssh-copy-id student@YOUR_SERVER_IP

It reports Number of key(s) added: 1. Windows lacks ssh-copy-id, so upload the file with scp instead:

# as the local user, in PowerShell
scp $env:USERPROFILE\.ssh\id_ed25519.pub student@YOUR_SERVER_IP:

It shows 100%. Then log in as student and move the key into place:

# as the student user
mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat ~/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
rm ~/id_ed25519.pub

No output means success. A new ssh student@YOUR_SERVER_IP must now ask Enter passphrase for key, not for the password. Still the password? Back to day 5: ~/.ssh 700, authorized_keys 600, owner student. sudo journalctl -u ssh -e shows the server's reason.

Exercise: cat ~/.ssh/authorized_keys; every line should be yours. The largest campaign in the IMC study, over 46 million sessions, planted its own key in this file.

Day 10: ufw firewall, SSH first

A firewall decides which connections get in, and ufw (Uncomplicated Firewall) is the simple one. Debian 13 has none and Ubuntu ships ufw switched off. Allow SSH first, then switch the firewall on:

# as the student user
sudo apt install ufw
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

Answer y to Command may disrupt existing ssh connections. The status shows Status: active and ALLOW IN for 22/tcp (OpenSSH), plus a (v6) line for your IPv6 address.

Exercise: sudo ufw allow 8080/tcp, find it in sudo ufw status numbered, delete it with sudo ufw delete and its number, then list again: the (v6) copy has its own number and needs its own delete. Check the number twice.

Day 11: Why does password login still work?

Keep this window open all day. First ask sshd which settings it really uses, and list the drop-in config files:

# as the student user
sudo sshd -T | grep -iE '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication) '
ls /etc/ssh/sshd_config.d/

The -i makes grep ignore case. Debian 13's OpenSSH 10.0 prints these names in lower case, while OpenSSH 10.4, released in July 2026, switched its configuration dump to mixed case, such as PasswordAuthentication; this line reads both. On our Debian 13 template you'll see permitrootlogin yes and passwordauthentication yes: root can still log in with a password. Now the trap: sshd keeps the first value it reads, and that folder is read before the rest of the main /etc/ssh/sshd_config. On cloud images, cloud-init (the first-boot setup tool) can leave 50-cloud-init.conf there with PasswordAuthentication yes, silently beating your no. Ubuntu 24.04 users reported exactly that in Launchpad bug 2088207. So add a drop-in that sorts first, test it and reload SSH:

# as the student user
printf '%s\n' 'PermitRootLogin no' 'PasswordAuthentication no' 'KbdInteractiveAuthentication no' | sudo tee /etc/ssh/sshd_config.d/00-hardening.conf
sudo sshd -t
sudo systemctl reload ssh

tee repeats the three lines, and sshd -t prints nothing when the config is valid. Rerun the sshd -T line: all three settings now say no. On Ubuntu 24.04 and 26.04, use sudo systemctl restart ssh. From a second window, this login refuses your key on purpose:

# as the local user, in a second window
ssh -o PubkeyAuthentication=no student@YOUR_SERVER_IP

It must end with Permission denied (publickey). A normal login still works. Only now close the first window.

Exercise: ssh root@YOUR_SERVER_IP. Refused.

Day 12: Automatic security updates

unattended-upgrades installs security updates by itself, daily. Ubuntu Server has it on already; on Debian, this installs it and asks you to confirm:

# as the student user
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure unattended-upgrades

Choose Yes in the dialog. /etc/apt/apt.conf.d/20auto-upgrades should then hold two lines ending in "1";. Automatic reboots are off by default, so after a linux-image update, run sudo reboot yourself.

Exercise: systemctl list-timers 'apt-daily*' shows the next run. When is it?

Day 13: fail2ban

fail2ban bans addresses that fail too often: by default, 5 failures within 10 minutes earn a 10-minute ban. Install it, then look at the SSH jail, fail2ban's word for one watched service:

# as the student user
sudo apt install fail2ban
sudo fail2ban-client status sshd

You see failed and banned counters. If it says it can't access the socket, fail2ban is still starting; wait ten seconds and run it again. Debian 13's package enables this jail and reads the journal, so no /var/log/auth.log is needed; on Ubuntu 24.04, run sudo apt update first so apt picks the fixed package, because the original one crashed on Python 3.12. On Ubuntu 26.04 the package worked first time in our test and also reads the journal. Settings belong in /etc/fail2ban/jail.local, never jail.conf, with your home IP in ignoreip. With keys only, fail2ban mostly cuts noise. Install it anyway and watch bans happen.

Exercise: check Total banned tomorrow.

Day 14: Lockout drill

Exercise: from a fresh window, log in with your key and confirm root and passwords are refused. Open the client area's web console once. For your phone, make a key in Termux and paste its .pub line into authorized_keys from your laptop session; that's now the only way in.

Week 3 (days 15 to 21): logs, upkeep and breaking things

Week 3 starts with reading: service status, logs, disk space and the login attempts piling up since day 1. Then you back up, break things on purpose and rebuild.

Day 15: systemd and services

systemd starts and tracks background services, calling each one a unit. systemctl --failed should report 0 loaded units listed., and systemctl status ssh should show active (running); q exits.

Exercise: sudo systemctl restart fail2ban, then check that its status says it started seconds ago.

Day 16: Read logs with journalctl

The journal is systemd's log. Debian 13 has no /var/log/auth.log by default, so tutorials that open it fail. The first command lists errors since boot; the second follows SSH live:

# as the student user
sudo journalctl -b -p err
sudo journalctl -u ssh -f

No errors is good news. Ctrl+C ends the live view.

Exercise: with it running, log in from another window and spot Accepted publickey for student.

Day 17: Who is trying to get in?

Count today's attempts with usernames that don't exist here, then list the ten most tried:

# as the student user
sudo journalctl -u ssh --since today | grep -c "Invalid user"
sudo journalctl -u ssh --since today | grep -oP 'Invalid user \K\S+' | sort | uniq -c | sort -rn | head

A number, then names with counts: scripts trying the same guesses everywhere. None get in. If the count is zero, the server is simply new; try again tomorrow. If you paste these logs into a forum or a chat, blur the addresses first. Some belong to hijacked home routers and servers, and in the EU an IP address can count as personal data.

Exercise: rerun both in a week. Compare.

Day 18: The weekly check

One lab server needs no monitoring stack. Run these five checks once a week:

1. sudo apt update and apt list --upgradable: what's waiting.
2. systemctl --failed: zero units.
3. df -h: nothing near 100% under Use%.
4. sudo journalctl -b -p err: new errors.
5. sudo fail2ban-client status sshd: the ban count.

Once the server runs something people rely on, add a watcher on another machine, as in our guide to monitoring with Uptime Kuma and Grafana from a second location.

Exercise: put these in ~/lab/check.sh and run bash ~/lab/check.sh. Your first shell script.

Day 19: Backups

RS Computers backs up every server weekly for free, restorable from the client area. Your own copy covers the days in between. Pack /etc, the configuration folder, into a file you own:

# as the student user
sudo tar czf ~/etc-backup.tar.gz /etc
sudo chown student: ~/etc-backup.tar.gz

tar's note about removing the leading / is normal. On your computer, scp student@YOUR_SERVER_IP:etc-backup.tar.gz . fetches it; it ends at 100%. Keep the file private: /etc holds password hashes. Copying by hand teaches the idea; for nightly, encrypted copies on another server, see our off-site backup guide with restic and Borg.

Exercise: tar -tzf etc-backup.tar.gz (tar ships with Windows 10 and later, and with macOS). Find 00-hardening.conf.

Day 20: Break it on purpose

Lock yourself out, with a net. In your open session, this makes your home folder writable by everyone:

# as the student user
chmod 777 ~

A login from a second window now fails, key or not: sshd won't trust keys in a folder anyone can write to. In the first window, read the reason, then repair it:

# as the student user
sudo journalctl -u ssh -n 20
chmod 700 ~

The log mentions bad ownership or modes, and after the chmod, logins work. If you closed every window, open the web console in the client area: it works like a keyboard plugged into the server, and student's password works there.

Exercise: break one more thing and fix it from the logs. A typo in 00-hardening.conf, caught by sudo sshd -t, is a gentle start.

Day 21: Reinstall and rebuild

Reinstall from the client area. It wipes the disk; that's the point. The next login shouts REMOTE HOST IDENTIFICATION HAS CHANGED! because the host keys are new. Tell your computer to forget the old key:

# as the local user, on your own computer
ssh-keygen -R YOUR_SERVER_IP

It reports that known_hosts was updated. Accept the new fingerprint, log in as root and redo days 2 to 13.

Exercise: time it. You'll beat that on day 30.

Week 4 (days 22 to 30): the DevOps path and an exam track

DevOps brings developers' habits to running servers: the setup written down as code, kept in git and rebuilt by script instead of by hand. The last nine days give you a taste of it, plus an exam to aim for.

Day 22: git

git keeps every version of your files. Install it and tell it who you are:

# as the student user
sudo apt install git
git --version
git config --global user.name "YOUR_NAME"
git config --global user.email "YOUR_EMAIL"

Debian 13 prints a 2.47 version (Ubuntu 24.04, 2.43; Ubuntu 26.04, 2.53). The config lines print nothing.

Exercise: in ~/lab, run git init, git add . and git commit -m "first notes". Never commit a private key.

Day 23: Docker

A container is an app packaged with its files, sharing the server's kernel. Docker runs them, and 71.1% of respondents to Stack Overflow's 2025 Developer Survey use it. Install Docker Engine from Docker's own apt repository, following its Debian install page line by line, and skip Debian's docker.io package. Docker's convenience script, which our Docker on a VPS guide uses, does the same in one go; doing it by hand once shows you each step. Then sudo docker run hello-world should print Hello from Docker!.

Exercise: sudo docker ps -a, then remove the finished container with sudo docker rm and its name.

Day 24: Why Docker bypasses ufw

Ports published with docker run -p skip ufw: Docker's documentation says the traffic is diverted before ufw's rules see it. This starts a web server container that only the server itself can reach, then fetches a page:

# as the student user
sudo docker run -d --name web -p 127.0.0.1:8080:80 nginx
curl -I http://127.0.0.1:8080

curl shows HTTP/1.1 200 OK, while port 8080 stays dark from outside. If curl says Connection reset by peer, nginx was still starting; run it again. To see the page on your own computer, tunnel it through SSH:

# as the local user, on your own computer
ssh -L 8080:127.0.0.1:8080 student@YOUR_SERVER_IP

While connected, http://localhost:8080 in your browser shows the nginx welcome page. Don't join the docker group to skip sudo; Docker's docs say it grants root-level privileges.

Exercise: sudo docker rm -f web, rerun it with -p 8080:80, and load the page from outside. It works, despite ufw. Remove it.

Day 25: Ansible

Ansible applies a playbook, a written description of a server, over SSH. Old guides say pip install ansible. pip isn't installed on Debian 13, and even after sudo apt install python3-pip that command stops at error: externally-managed-environment. Use pipx instead, which gives each Python app its own space:

# as the student user
sudo apt install pipx
pipx install --include-deps ansible
pipx ensurepath

Log out and back in. ansible localhost -m ping then warns that no inventory was parsed (fine for now) and answers "ping": "pong". In our test run, pipx installed Ansible 14.4 (ansible-core 2.21) in about half a minute, using close to 500 MB of disk. Day to day, Ansible runs from your own Linux or Mac, or from WSL on Windows, and since ansible-core 2.20 that machine needs Python 3.12 or newer. Debian 13 has 3.13, Ubuntu 24.04 has 3.12 and Ubuntu 26.04 has 3.14, so all three qualify.

Exercise: follow Ansible's getting-started guide with localhost as the only host.

Day 26: A little Terraform

Terraform builds infrastructure from text files through a provider's API. Install it from HashiCorp's apt repository (Debian steps on its install page), after installing lsb-release, which the setup line needs. Skip the software-properties-common package older guides add; Debian 13 doesn't have it. Since August 2023 Terraform uses the Business Source License, and OpenTofu is the open-source fork.

Exercise: HashiCorp's Docker get-started tutorial builds an nginx container with Terraform. Finish with terraform destroy.

Day 27: Your setup as a script

Exercise: copy days 2 to 13 into ~/lab/setup.sh, keeping interactive lines (adduser, dpkg-reconfigure) as comments and using ufw --force enable after the allow line. Commit it, then ask of every line: what if it runs twice? "Nothing changes the second time" has a DevOps name: idempotent.

Day 28: LPIC-1 vs LFCS vs RHCSA

Three entry-level certificates fit this month. LPIC-1 asks you questions about the work; LFCS and RHCSA make you do it on a live system.

The Linux Foundation publishes the LFCS weights: Operations Deployment 25%, Networking 25%, Storage 20%, Essential Commands 20%, Users and Groups 10%. Pick LFCS unless local job ads name Red Hat; then pick RHCSA. Both test doing, which is what you've trained. LPIC-1 suits you if a live exam terminal makes you freeze.

Exercise: tick off the official objectives you've already covered.

Day 29: RHCSA practice on AlmaLinux or Rocky Linux

AlmaLinux and Rocky Linux are free rebuilds of Red Hat Enterprise Linux, so RHCSA practice happens there. Red Hat's EX200 page says the exam is based on RHEL 10, so practise on version 10. It needs a newer CPU level, and this shows what your server supports:

# as the student user
/lib64/ld-linux-x86-64.so.2 --help | grep supported

Rocky Linux 10 needs x86-64-v3 (supported, searched) in the output; AlmaLinux 10 also builds for older x86-64-v2 CPUs. On the server we set up for this guide, the vCPUs reported AVX2 but not AVX-512, so the output listed x86-64-v3 and x86-64-v2 as supported and had no v4 line: enough for Rocky Linux 10. Reinstall and redo week 2 with these swaps:

Leave SELinux enforcing and learn to fix its labels; the exam expects that. On the LFCS or LPIC-1 track, stay on Debian and work ten tasks from the objectives against a two-hour timer.

Exercise: reboot at the end. Did everything survive?

Day 30: Rebuild against the clock

Reinstall Debian 13, clear the host key with ssh-keygen -R, copy setup.sh up with scp and run it as root. Compare the time with day 21. Then book the exam, or put something real behind a domain name; our reverse proxy guide for Caddy, Nginx and Traefik adds free HTTPS in front of it. Leave Kubernetes and your own mail server for later; either can eat a month before the basics are solid.

Exercise: list everything that broke this month and how you fixed it. Keep the list.

Frequently asked questions

Is a VPS better than VirtualBox for learning Linux?

For server skills, yes. A VirtualBox VM in default NAT mode can't be reached from the internet, so you never see real remote access or real attacks. A VPS has its own public IPv4 and IPv6 address and can be reinstalled whenever you break it.

Can I learn Linux on a VPS with only 1 GB of RAM?

Yes. Debian's installation guide recommends 1 GB for a system without a desktop, enough for the first three weeks. Move to 2 GB for Docker and Ansible, or for AlmaLinux and Rocky Linux 10, since Red Hat lists 1.5 GiB as the RHEL 10 minimum.

Which Linux distro should a beginner use on a VPS?

Debian 13, or Ubuntu 24.04 or 26.04 LTS. Debian switches less on by default, so you see each piece being added; Ubuntu has more beginner tutorials. Ubuntu 26.04 LTS came out on 23 April 2026, and Canonical opened upgrades from 24.04 on 29 September 2026. In our test, the sudo, SSH and fail2ban steps worked on 26.04 too, with the differences noted on days 3 and 13. Choose AlmaLinux or Rocky Linux when preparing for RHCSA.

Should I change the default SSH port?

Not in your first month. With key-only login, guessing on port 22 can't succeed; another port mostly quietens the logs. If you change it, allow the new port in ufw first, and on Ubuntu 24.04 or 26.04 run sudo systemctl daemon-reload and sudo systemctl restart ssh.socket, or SSH keeps listening on 22.

Why are there so many failed login attempts on my server?

Every public IP address is scanned by scripts trying common usernames and passwords. In Unit 42's 2021 study, 80% of exposed honeypots were compromised within 24 hours. With password login off the attempts can't succeed, and fail2ban keeps the noise down.

Can RS Computers set this up for me?

Yes. Message us on Telegram or email info@rscomputers-ks.com with the distribution you want and what you plan to learn, and we'll suggest a plan and quote the setup. Doing the 30 days yourself is still the part that teaches.

Order the server, then do day 1

Open the VPS plans page, pick VPS Nano or VPS Micro, choose Debian 13, and do days 1 and 2 straight away: log in, update. Tomorrow, a user. By day 30 you should be able to rebuild the whole server from your own script in one sitting.

← All articles