What software do you install on every new Linux server?

[SenseiSteve]

Everyone has their own deployment checklist, but I'm curious what software makes it onto every new Linux server before it goes into production.

Beyond the operating system itself, what packages or tools do you consider essential from day one? Are there applications you install automatically regardless of whether it's a web server, database server, virtualization host, or something else?

For example, do you always install:

• Monitoring agents (Zabbix, Netdata, Prometheus Node Exporter, etc.)
• Security tools such as Fail2ban, CrowdSec, or AIDE
• Backup software or snapshot utilities
• Performance monitoring and troubleshooting tools
• Firewall management utilities
• Configuration management like Ansible or Puppet
• Container platforms such as Docker or Podman
• Log management or auditing software
• Remote management or automation utilities

Has your "must-have" list changed over the past few years? Perhaps you've removed software that used to be standard or adopted newer tools that have proven more effective.

I'm also interested in whether your list differs depending on the server's role. Do you have one baseline image for everything, or do you maintain separate templates for web servers, database servers, storage nodes, virtualization hosts, and Kubernetes workers?

Finally, if you could recommend one piece of Linux server software that you think is underrated or doesn't get enough attention, what would it be, and why?

 

[Mivocloud]

Hey!

Personally, every time I set up a server, I always install Docker and, in about 80% of cases, GNOME.

Since I use Ubuntu to record videos, this stack is enough for almost any idea that comes to mind.

In general, I consider installing Docker to be the second most important thing to do on a server. First, of course, is updating system packages and boosting the server's security.

Right now, I'm thinking about creating a script to install on every server so a Telegram bot sends notifications about server logins and downtime if it happens to drop. A script like that would be top 3 on the list of things to install right after creating a server.

 

[Cantech Networks]

Hello,

My starter kit on every server: Fail2ban (blocks bad login attempts), UFW (simple firewall), htop (see what's using resources), Netdata (easy monitoring), and auto security updates.

If I am managing more than one server, I also add Ansible makes setup way easier.

Most underestimated tool: Netdata quick to set up and shows you what's happening on your server in real time, without much inconvenience .

 

[RackWorks]

WireGuard is top of my list. Bind SSH, and anything else management-related, to the WG LAN IP instead of leaving it public facing. Cuts attack surface way more than any hardening you do on the public side.

 

[FrancoFang]

My underrated pick is not really a package, it is a habit: baseline the
network path on day one, not when someone complains.

Everyone in this thread installs monitoring for CPU, memory and disk,
and almost nobody records what the route looked like while the box was
healthy. Three weeks later a customer says it feels slow, and you have a
beautiful graph of an idle server and no idea whether the path changed
underneath it. A scheduled mtr to a small fixed set of targets, written
to a file from the hour the machine is provisioned, costs nothing and
turns "we think routing changed" into "it changed on the 14th at 02:00,
and here is the hop it changed at". If you want the tidy version of the
same idea, smokeping or a Prometheus blackbox exporter with ICMP does it
properly.

A smaller one, for Debian and Ubuntu: make the journal persistent. By
default it lives in memory, so the reboot you most want to investigate
is the one whose logs you no longer have. Creating /var/log/journal or
setting Storage=persistent is a one-line fix that people usually
discover the day after they needed it.

Agreeing with Cantech on Netdata being underestimated. It is also the
quickest way to see steal time, which is how a fair number of "server
problems" turn out to be the host rather than your box.

Provider side here.