Linux for Starters: What Actually Matters When You Run a Server

Most Linux beginner guides are about picking a desktop distro, which is a fine hobby and almost entirely irrelevant to why a developer needs Linux. You need Linux because your code runs on it. That changes the syllabus completely: the distro barely matters (use Ubuntu LTS and stop thinking about it), the desktop environment does not matter at all, and the things that will actually bite you are permissions, systemd, the package manager, and reading logs. Here is the short version of what to learn, in the order it will hurt you.

Pick Ubuntu LTS and move on
Permissions are the thing that will actually break
systemd runs everything, so learn four commands
The commands you will type every day
Read the logs before you change anything
What you can skip for now
How this fits the rest of the stack
FAQ

Pick Ubuntu LTS and move on

The distro question consumes an enormous amount of beginner attention and deserves almost none of it.

Use Ubuntu LTS. Not because it is technically superior - Debian is more conservative, Fedora is more current, Alpine is smaller - but because it has the largest volume of documentation, the most third-party install instructions written specifically for it, and a five-year support window. When you paste an error into a search engine at 2am, the answer will be for Ubuntu.

The naming is simple: 24.04 means April 2024. Even-numbered years with .04 are the LTS releases, supported for five years. Use those and skip the interim releases entirely.

When the other distros matter:

Debian - when you want fewer surprises and Ubuntu’s habit of shipping snaps annoys you.
Alpine - inside containers, where a 5MB base image beats a 70MB one. Be aware it uses musl instead of glibc, which occasionally breaks binaries in ways that take an hour to diagnose.
RHEL, Rocky, Alma - when an enterprise contract or a vendor’s support matrix demands it.

That is the entire decision. The desktop-distro listicles ranking Mint against Zorin are answering a different question than the one you have.

Permissions are the thing that will actually break

More beginner Linux time is lost to permissions than to anything else, and the model is small enough to learn in ten minutes.

Every file has an owner, a group, and three sets of permissions - read (4), write (2), execute (1) - for the owner, the group, and everyone else.

ls -l deploy.sh
-rwxr-xr--  1 deploy  www-data  1200 Jul 14 09:22 deploy.sh

That reads as: owner deploy can read, write, and execute; group www-data can read and execute; everyone else can only read. As a number, that is 754.

The three commands you need:

chmod 640 config.env      # owner read/write, group read, others nothing
chown deploy:www-data app.log
chmod +x deploy.sh        # make it runnable

The rules worth memorising, because they are the ones that cause real incidents:

SSH keys must be 600, and ~/.ssh must be 700. SSH silently refuses to use a key that anyone else can read. This is the single most common cause of a mysterious permission-denied on a key that is obviously correct.
Never chmod 777 anything. It is not a fix, it is a way of turning a permissions problem into a security problem while appearing to make progress.
Secrets should be 600, owned by the user that reads them.

systemd runs everything, so learn four commands

On any modern Linux server, systemd starts your service, restarts it when it dies, and captures its output. You do not need to love it. You need four commands.

systemctl status nginx      # is it running, and what did it say when it stopped
systemctl restart nginx
systemctl enable nginx      # start automatically at boot
journalctl -u nginx -f      # follow the logs

systemctl status is the first thing to run when anything is wrong, and it is the command beginners most consistently skip. It tells you whether the process is running, what its exit code was, and shows the last few log lines - which is usually enough to diagnose the problem without going any further.

The distinction that trips people up: start runs it now, enable makes it run at boot. They are separate. A service that works perfectly until the box reboots is almost always one that was started but never enabled.

For logs, journalctl -u <service> -n 100 --no-pager gets you the last hundred lines, and -f follows in real time. Application logs may also be in /var/log/, but on a systemd box the journal is the first place to look.

The commands you will type every day

Ignore the thousand-command reference lists. This is the working set.

Finding things:

grep -rn "TypeError" /var/log/app/     # search file contents, recursively, with line numbers
find . -name "*.log" -mtime +7         # files matching a name, older than 7 days

Understanding a running box:

df -h            # disk space - run this first when anything is mysteriously broken
free -h          # memory
top              # what is eating the CPU
ss -tulpn        # what is listening on which port

Moving things:

rsync -avz ./dist/ deploy@server:/var/www/app/
tar -czf backup.tar.gz ./data

Two of these deserve special attention. df -h should be your reflex whenever a server behaves strangely for no apparent reason - a full disk produces bizarre, unrelated-looking failures across every service on the box, and it is the single most common cause of the weird ones. And ss -tulpn answers the question that comes up constantly: what is already using port 3000.

Read the logs before you change anything

The most valuable habit in Linux is not a command. It is resisting the urge to start changing things before you have read what the machine is telling you.

The standard sequence when something is broken:

systemctl status <service> - is it even running, and what was the exit code?
journalctl -u <service> -n 100 - what did it say on the way down?
df -h - is the disk full? It is full more often than you would believe.
ss -tulpn | grep <port> - is something else already on the port?

Four commands, and they resolve the large majority of “the server is broken” situations without any config changes at all.

The failure pattern to avoid is the one everyone starts with: an error appears, you paste it into a search engine, you find a Stack Overflow answer from 2016, and you apply a config change you do not understand to a problem you have not diagnosed. Sometimes it works, which is worse than if it had failed, because now the box has a change in it that nobody can explain.

What you can skip for now

The Linux world will happily sell you a syllabus ten times longer than you need. Some things genuinely can wait.

Skip: compiling your own kernel, learning vim beyond i to insert and :wq to save (use nano, nobody serious cares), memorising every tar flag, desktop environments, awk and sed as a programming language, and the entire distro-tribalism discourse.

Learn eventually, but not first: shell scripting beyond simple sequences, SELinux and AppArmor, iptables and nftables, cgroups.

Learn now, because it will bite you this month: the permission model, systemctl and journalctl, the package manager (apt update, apt install, and knowing that apt upgrade on a production box in the middle of the day is a career-limiting move), SSH keys and ~/.ssh/config, and df -h.

The honest truth about Linux as a developer: you are not becoming a sysadmin. You are learning enough to be unafraid of the box your code runs on, and to read what it says when it is unhappy. That is a much smaller syllabus than the internet implies, and you can cover most of it in a weekend.

How this fits the rest of the stack

Whatever you decide here, the cost of the decision only shows up as a bill. The RunxBuild hosting calculator is the right place to model that before committing: the compute, the database, the storage, the bandwidth, the worker - each one is a separate line item, and the real cost of a platform is the sum, not the headline number. The RunxBuild dashboard is where the team sees the actual usage once it is running.

Useful related references:

FAQ

Which Linux distro should a beginner developer use?

Ubuntu LTS. Not because it is technically better than Debian or Fedora, but because it has the most documentation and the most third-party install instructions written for it. When you search an error message, the answer will be for Ubuntu. Use the even-year .04 releases, which get five years of support.

What Linux commands should I learn first?

systemctl status, journalctl -u, df -h, and ss -tulpn will diagnose most server problems. Add chmod, chown, grep -rn, and rsync for daily work. That is a much smaller set than most beginner guides suggest, and it covers the majority of real situations.

Why does SSH refuse my key with permission denied?

Almost always file permissions. A private key must be 600 and the ~/.ssh directory must be 700 - SSH silently refuses to use a key that other users can read. Run chmod 600 on the key file before you debug anything else.

Do I need to learn vim?

No. Learn enough to escape it - press i to type, then Escape and :wq to save and quit - and use nano for actual editing. Nobody serious will judge you, and the time is better spent on permissions and systemd.

What is the difference between systemctl start and systemctl enable?

start runs the service now; enable makes it start automatically at boot. They are independent. A service that works fine until the machine reboots and then never comes back is almost always one that was started but never enabled.