Linux Package Managers: How Software Gets Installed on a Server

On your laptop, installing software is a familiar ritual: find a website, download an installer, double-click it, click Next a few times, done. On a Linux server there’s no website to visit and no installer to double-click — and honestly, that turns out to be a better way to do it. Instead, you tell a package manager what you want, and it fetches the software, sets it up, and tracks it for you.

If you’ve ever wondered why server tutorials are full of lines like apt install nginx or dnf install git, this is the piece that makes all of them make sense. Once you understand what a package manager actually does, installing, updating, and removing software on a server stops feeling like memorized magic and starts feeling like a tool you control.

What a package manager actually is

A package manager is a program whose entire job is to install, update, and remove other software on your system. You give it the name of what you want — git, curl, a web server — and it handles everything else: downloading the right files, putting them in the right places, wiring up the commands, and remembering that it’s installed so you can cleanly remove it later.

A package is the unit it deals in. Think of it as a tidy bundle: the actual program files, plus a small manifest describing what the package is, what version it is, and — crucially — what other packages it needs in order to work. That last part is the real magic, and we’ll get to it.

The key mental shift coming from Windows or macOS: on a server you almost never “download and run an installer.” You ask the package manager, and it pulls the software from a trusted, central source. That source is called a repository.

Repositories: where packages come from

A repository (often shortened to “repo”) is a curated online collection of packages that your system is configured to trust. When you ask to install something, the package manager looks it up in these repositories, downloads it from there, and verifies it.

Every Linux distribution maintains its own official repositories — a big, tested catalog of software that’s been packaged specifically for that system. This matters for a few reasons:

• It’s a single source of truth. You don’t hunt across random websites hoping you found the real download. One trusted catalog has everything.
• It’s verified. Packages are cryptographically signed. The package manager checks the signature, so you know the software wasn’t tampered with on the way to your server.
• It’s consistent. Everything in the repo is built and tested to work together on your specific system.

Your system keeps a local index of what’s available in those repos — basically a copy of the catalog’s table of contents. That index can go stale, which is why nearly every install session starts by refreshing it. More on that command in a moment.

        YOUR SERVER                         THE INTERNET
   ┌──────────────────────┐           ┌────────────────────────┐
   │  package manager     │  asks →   │   repository (repo)    │
   │  + local index       │           │   curated, signed      │
   │                      │  ← gets   │   catalog of packages  │
   └──────────────────────┘           └────────────────────────┘
        installs into
        the right places

Dependencies: the problem package managers were built to solve

Here’s the thing that makes package managers genuinely valuable instead of just convenient. Most software doesn’t stand alone. A program you want often relies on other pieces of software to function — shared libraries, runtimes, helper tools. Those required pieces are called dependencies.

Imagine installing a web application by hand. It needs a particular library. That library needs two more libraries. One of those needs a specific version of something else. Track all of this down yourself across a dozen packages — making sure every version is compatible — and you’ve stumbled into what people grimly call “dependency hell.” It’s tedious, error-prone, and easy to get subtly wrong.

A package manager makes that disappear. When you ask for one package, it reads that package’s manifest, sees everything it depends on, finds those dependencies’ dependencies, and presents you with the full list to install in one shot. It resolves the whole tree automatically.

   You ask for:   webapp
                    │
        ┌───────────┼───────────┐
     lib-a       runtime      lib-b
        │                        │
     lib-c                   lib-d (v2.1)

   The package manager works all of this out
   and installs every box in the right order.

It also keeps the books on the way back out. When you remove software, the package manager knows which dependencies were only installed because of it, and can clean those up too — so your server doesn’t slowly fill with orphaned junk nobody remembers installing.

The big families: apt, dnf, pacman, and friends

Linux isn’t one operating system — it’s a whole family of distributions, and they don’t all share the same package manager. Which one you use depends on which distro your server runs. If that idea is new, it’s worth a quick look at how distros differ in Linux distributions, because that choice is exactly what decides your package manager.

There are two big lineages you’ll meet constantly:

• The Debian family (Debian, Ubuntu, and their relatives) uses apt. Underneath, packages are .deb files, but you almost always drive it through apt. This is the most common family for beginner-friendly servers.
• The Red Hat family (Fedora, RHEL, Rocky, AlmaLinux) uses dnf (the modern successor to the older yum). Packages here are .rpm files.

A couple more worth recognizing, even if you don’t use them yet:

• pacman — Arch Linux and its derivatives.
• zypper — openSUSE.
• apk — Alpine Linux, popular in lightweight container images for being tiny.

The good news: they all do the same job and share the same concepts — repositories, packages, dependencies, install/update/remove. Once you understand the idea, switching between them is mostly a matter of learning a different word for “install.”

The commands you’ll actually use

Let’s get concrete with the Debian/Ubuntu family, since it’s the most common starting point. These same five actions exist in every package manager — only the spelling changes.

Almost everything you’ll do involves administrator rights, because installing system software touches protected parts of the system. That’s why these commands start with sudo. If the idea of sudo and root access is fuzzy, the file permissions article explains why ordinary users can’t just write anywhere on a server. And since you’ll be typing all of this into a terminal, the command line article is a good companion if the shell still feels unfamiliar.

1. Refresh the index. Update your local copy of the catalog so you’re working from current information. Do this first, especially before installing.

sudo apt update

2. Install a package. Ask for software by name. The package manager figures out the dependencies and asks you to confirm.

sudo apt install git

3. Upgrade everything. Apply available updates to all installed packages — important for security fixes.

sudo apt upgrade

4. Remove a package. Uninstall software you no longer need.

sudo apt remove git

5. Search the catalog. Find out whether something exists in the repos, and under what name.

apt search compression

Here’s roughly how a real install plays out, so the flow isn’t a surprise:

$ sudo apt update
  Reading package lists... Done
  (your local index is now fresh)

$ sudo apt install git
  Reading dependencies... Done
  The following NEW packages will be installed:
    git git-man liberror-perl ...
  Need to get 5,200 kB of archives.
  Do you want to continue? [Y/n] y
  ...
  Setting up git ...
  Done.

Notice that asking for one thing (git) pulled in a handful of extra packages you never named. That’s dependency resolution doing its job — exactly the work you’d otherwise be doing by hand.

For comparison, here’s the same set of actions in the other major families, so you can see how little really changes:

ACTION           Debian/Ubuntu (apt)      Fedora/RHEL (dnf)        Arch (pacman)
─────────────────────────────────────────────────────────────────────────────────
refresh index    sudo apt update          (refreshed automatically) sudo pacman -Sy
install          sudo apt install NAME     sudo dnf install NAME    sudo pacman -S NAME
upgrade all      sudo apt upgrade          sudo dnf upgrade         sudo pacman -Syu
remove           sudo apt remove NAME      sudo dnf remove NAME     sudo pacman -R NAME
search           apt search TERM           dnf search TERM          pacman -Ss TERM

Same five ideas, three different dialects. Learn the row labels on the left and you can sit down at any of these systems.

Versions, updates, and why stale software is a risk

There’s a subtle but important reason package managers matter for server work specifically: keeping software updated is a security job, not just a convenience. Servers are exposed to the internet around the clock, and outdated software is one of the most common ways they get compromised. When a vulnerability is found in a piece of software, the fix arrives as an updated package in the repository. The whole point of apt upgrade / dnf upgrade is to pull those fixes in.

This is also why distributions are sometimes described as “stable” or “cutting-edge.” Stable distros (like Debian) deliberately ship slightly older, heavily-tested versions and patch them for security, prioritizing predictability. Others ship the newest versions quickly, prioritizing features. Neither is “better” — they’re different trade-offs, and the package manager is how you live with whichever one you chose.

A quick word on the newer universal formats

You may run into Snap, Flatpak, and AppImage. These are a newer style of packaging where an app ships with its own dependencies bundled inside, so it can run across many distributions without caring about what’s already installed. That solves portability, at the cost of larger downloads and some duplication.

For server work, you’ll mostly stick with your distro’s native package manager (apt, dnf, and so on) — it’s leaner and integrates tightly with the system. The universal formats show up more on the desktop, but it’s good to know the names so they don’t confuse you later.

Why this is foundational

Almost every server task you’ll ever do begins with installing something. A web server, a database, a runtime for your application, monitoring tools, security tools — all of it arrives through the package manager. Get comfortable with this one tool and an enormous amount of server work becomes routine instead of intimidating.

More deeply, package managers encode a philosophy that runs through all of Linux: trusted central sources, automatic dependency handling, clean install-and-remove, and updates as a first-class habit. Internalize that, and you’re not just memorizing apt install — you’re learning how a server is meant to be cared for over time.

Wrapping up

Here’s the whole picture in one place:

• A package manager installs, updates, and removes software on your system; you ask by name and it handles the rest.
• A package is a bundle of program files plus a manifest, including the list of other packages it needs.
• Repositories are curated, signed, trusted catalogs that your system pulls software from — one source of truth instead of random websites.
• Dependencies are the other software a package needs; the package manager resolves the whole tree automatically and avoids “dependency hell.”
• The big families are apt (Debian/Ubuntu), dnf (Fedora/RHEL), and pacman (Arch) — same concepts, different commands.
• The five everyday actions are refresh, install, upgrade, remove, search, and most need sudo.
• Keeping packages updated is a security responsibility, because outdated software is a favorite way in for attackers.

Once you can install and update software confidently, the natural next step is learning what to do with those programs once they’re running — how the things you installed keep working in the background as processes and services on your server.