Linux network management: NetworkManager vs systemd-networkd vs iwd
Linux splits networking into a kernel layer that runs the link and a userspace manager that configures it. This explains NetworkManager, systemd-networkd and iwd, and which one to enable on a fresh Arch install.
level:Beginner
Somewhere near the end of an Arch install you reboot into your new system, type ping archlinux.org, and nothing happens. The installer had working Wi-Fi a minute ago; now you have a bare system that cannot reach the internet. The reason is that Linux does not ship one built-in "network settings" the way Windows and macOS do. The kernel knows how to drive your network card, but deciding which Wi-Fi network to join, what IP address to request, and which DNS server to ask is a separate job handled by a piece of userspace software you choose and enable yourself. There are three serious choices, and the good news is that for almost everyone the right one is obvious. If you are installing a laptop or desktop, install NetworkManager and move on; the rest of this post explains why, and when you might pick something else.
The two layers: link versus configuration
It helps to separate two things that beginners tend to fuse together.
The link is the low-level connection: the kernel talking to your network hardware over a driver, bringing the interface up, and moving packets. This part is built into the kernel. When you see an interface like wlan0 or enp3s0, that is the kernel exposing the hardware. The kernel does not, on its own, decide what to do with that interface.
The configuration is everything above that: scanning for Wi-Fi networks and authenticating to one, asking a DHCP server for an address, setting up routes, pointing the system at a DNS resolver, and reconnecting when you walk from one café to another. This is the job of a network manager, and it runs as a background process — a daemon. If you have not met the term, it is just a long-running program with no window that sits there waiting to do work; the word has a pleasantly nerdy history. On a modern Arch system every option below is started and supervised by systemd, the init system that brings up services at boot, so "enabling networking" in practice means telling systemd to start one of these daemons.
That is the whole mental model: the kernel runs the link, a daemon configures it. The choice you are making is which configuration daemon. If you are coming from elsewhere, this is roughly the job of the Windows network tray or the macOS Wi-Fi menu — except on Linux the piece doing that job is swappable, and you pick it.
The stack below shows where the choice lives. What you are swapping is only the top box; why it can be swapped is that the kernel link layer underneath stays the same regardless; how you swap it is by enabling a different daemon at boot.
flowchart TD
A["Apps + desktop<br/><i>browser, GNOME panel</i>"] --> B["Network manager<br/><i>userspace daemon</i>"]
B --> C["Kernel network interface<br/><i>link: wlan0, enp3s0</i>"]
C --> D["Network hardware"]
B -.-> E["NetworkManager"]
B -.-> F["systemd-networkd"]
B -.-> G["iwd"]
The dashed boxes are the interchangeable choices that can occupy the manager layer.
NetworkManager: the desktop default
NetworkManager is the manager nearly every desktop Linux user runs, and it is what the GNOME and KDE Plasma desktops expect to find. It handles wired Ethernet, Wi-Fi, mobile broadband and VPNs through one daemon, and it is designed for machines that move around and change networks constantly.
Its great virtue is that it has interfaces at every level of comfort. The applet in your system tray that shows the Wi-Fi list is talking to NetworkManager. So is nmtui, a friendly text-menu tool you can drive with arrow keys over SSH or in a console. And so is nmcli, the scriptable command line that power users and automation reach for. They are three front ends over the same daemon, so a network you join in the GUI shows up identically in nmcli.
Crucially, the major desktop environments integrate with it directly. If you install GNOME or KDE Plasma and expect the network icon in the panel to work, NetworkManager is the daemon behind it. Choosing anything else means wiring up your own status indicator. That alone settles the decision for most people: what you get is the panel icon for free, why it works is that the desktop is written to talk to this specific daemon, and how you opt in is simply installing and enabling it.
systemd-networkd: lightweight and declarative
systemd-networkd comes from the same project as systemd itself, and it takes the opposite philosophy. Instead of a chatty daemon that reacts to a user clicking around, it reads small static text files — .network and .link units — and brings the configuration up exactly as written. You describe the desired end state in a file; networkd makes the interface match it.
This is excellent for servers, virtual machines, and any box with a fixed setup that rarely changes: a static IP, a known gateway, no roaming. The configuration lives in version-controllable files, the daemon is small, and there is no GUI surface area to worry about. It is typically paired with systemd-resolved, the companion DNS resolver from the same family, so that name lookups are handled in a consistent, systemd-native way. The trade-off is that it has no notion of "scan and click to join Wi-Fi" — that is not its job — which is exactly why it is a poor fit for a roaming laptop and a great fit for a rack server.
iwd: the Wi-Fi specialist (and what the installer uses)
iwd — iNet wireless daemon, an Intel project — is narrower than the other two: it is specifically a Wi-Fi daemon. It manages wireless authentication and association and does it with very few dependencies and notably fast connection times.
You have almost certainly already used it. The Arch installation ISO ships with iwd enabled, and the iwctl command you use to get the live environment online — iwctl station wlan0 connect MyNetwork — is iwd's client. (The ISO also pre-enables systemd-networkd and systemd-resolved, which is why the live environment Just Works, per the installation guide.) A common surprise: none of that carries over to your installed system unless you install the packages yourself, which is why a fresh boot has no network.
iwd can run two ways. Standalone, it handles Wi-Fi plus basic network configuration, often alongside systemd-networkd and systemd-resolved for a minimal, systemd-flavoured setup. Or it can act as a backend for NetworkManager, replacing NetworkManager's default Wi-Fi machinery (wpa_supplicant) with iwd's faster one while you still get NetworkManager's GUI and VPN handling on top. If you go that route, the wiki is explicit: do not also enable iwd.service directly, because NetworkManager starts and manages iwd itself.
You may still see dhcpcd and netctl mentioned in old guides. dhcpcd is a standalone DHCP client — useful as a building block, occasionally on its own for a simple wired server, but not a full manager. netctl is an older Arch-specific profile-based tool that has been effectively superseded; treat both as legacy and reach for them only if you have a specific reason.
Which should I pick?
For any laptop or desktop, install NetworkManager. It handles Wi-Fi, Ethernet, and VPN through one daemon; it is what GNOME and KDE Plasma expect; and nmtui gives you a usable menu even before you have a desktop installed. This is the boring, correct default and you should not overthink it.
pacman -S networkmanager
systemctl enable --now NetworkManager.service
If you are on a laptop with an Intel Wi-Fi card and want faster, more reliable wireless, you can later set iwd as NetworkManager's backend — but start with the stock setup and only change it if you hit a problem.
For a server, a VM, or any machine with a fixed, unchanging setup, use systemd-networkd plus systemd-resolved. Declarative files, a tiny footprint, nothing to click. The same goes for a headless box you administer over SSH where a roaming Wi-Fi manager would be dead weight.
Choose iwd standalone only when you specifically want a minimal wireless-only system and are comfortable pairing it with systemd-networkd for addressing. It is a fine choice for the deliberate minimalist; it is the wrong first choice for a beginner who just wants the network icon in their panel to work.
The honest caveat from the Arch forums is that none of these is universally "best" — people run all three happily. But for a first install, the decision tree is short: desktop or laptop, NetworkManager; server, systemd-networkd.
💡 Tip The whole decision collapses to one question: is this machine moving around or sitting still? Use NetworkManager for a laptop or desktop, and systemd-networkd for a server. If you only remember one line from this post, remember that one.
What the chart encodes is the same three-way split as the prose; why it branches on machine type is that roaming versus fixed is the property that actually separates the daemons; how you read it is top to bottom from the one question that matters.
flowchart TD
A["What machine is this?"] -->|"laptop or desktop"| B["NetworkManager<br/><i>GUI, nmtui, nmcli</i>"]
A -->|"server or fixed IP"| C["systemd-networkd<br/><i>declarative .network files</i>"]
A -->|"wifi-only and minimal"| D["iwd standalone<br/><i>plus systemd-networkd</i>"]
B --> E["Network icon just works"]
C --> F["Tiny, no GUI surface"]
D --> G["Fast wifi, few deps"]
Most readers stop at the first branch: laptop or desktop, NetworkManager.
How this fits the Arch install
This is the choice behind one short step near the end of the install. In part 3, where you set up the desktop and drivers, you install NetworkManager and enable its service so your new system comes up with working networking after the first reboot — exactly the gap that catches people who skip it. That step is the practical payoff of everything above. For the full walkthrough from a blank disk to a working desktop, see the companion install hub, and for the init system that actually starts your chosen daemon at boot, see what systemd is.
A short close
Linux does not hide networking behind a single settings panel; it hands you a layered system where the kernel runs the link and a daemon you choose configures it. That sounds like more work than it is. For the machine in front of you the answer is almost always NetworkManager, with systemd-networkd waiting in the wings for the day you build a server. Enable the daemon, reboot, and ping should answer.