Cockpit on Fedora Server means you can run the whole box from a browser tab, using your normal Linux login on port 9090. Services, logs, storage, the firewall, updates, containers and virtual machines all live in one place. You’ll finish this guide with the web console reachable from your admin network, Podman containers and KVM guests showing up in it, and a certificate and firewall rule you chose instead of the defaults.
Fedora Server ships Cockpit already enabled, so the first part is quick there, and the same steps also add it to a Cloud or minimal install that doesn’t have it. The VMs and Podman pages need extra packages, and each hides a trap we hit and fixed below: a libvirt error page right after install, and rootless containers that quietly stop when you log out. I went through every step in October 2026 on a Fedora 45 server VM built from the Cloud image with the Server edition’s headless-management group and release identity, and they hold.
Check what your Fedora install already has
The Fedora Server edition installs Cockpit through its headless-management group, enables cockpit.socket with a preset, and opens the cockpit service in its FedoraServer firewall zone. If that’s your install, you can open the console right away and skip to the login section. You can see exactly what the group brings in:
dnf group info headless-managementCockpit itself is mandatory, and four of its modules come along by default:
Id : headless-management
Name : Headless Management
Description : Tools for managing the system without an attached graphical console.
Installed : no
Order :
Langonly :
Uservisible : yes
Repositories : fedora
Mandatory packages : PackageKit
: cockpit
: openssh-server
Default packages : cockpit-networkmanager
: cockpit-packagekit
: cockpit-selinux
: cockpit-storaged
: udisks2-iscsi
: udisks2-lvm2Notice what isn’t in that list: the Virtual machines, Podman containers and File browser pages. Those are separate packages on every edition, and you’ll add them in a later step.
Install Cockpit where it’s missing
On a Cloud image, a minimal install or a Workstation you want to manage remotely, install the same group Fedora Server uses, so you end up with the same pages. Our VM started from the Cloud image, which has neither Cockpit nor firewalld, so it got both:
sudo dnf -y group install headless-management
sudo dnf -y install firewalld
sudo systemctl enable --now firewalld
sudo systemctl enable --now cockpit.socketCockpit is socket-activated. systemd listens on port 9090 and only starts the web service when a browser connects, so an idle Cockpit costs you almost nothing. Check that the socket is listening:
systemctl status cockpit.socket --no-pager | head -8You should see active (listening) on [::]:9090:
● cockpit.socket - Cockpit Web Service Socket
Loaded: loaded (/usr/lib/systemd/system/cockpit.socket; enabled; preset: disabled)
Active: active (listening) since Tue 2026-10-20 12:04:16 UTC; 23ms ago
Invocation: 05dbe18a872d40088378d97c54179883
Triggers: ● cockpit.service
Docs: man:cockpit-ws(8)
Listen: [::]:9090 (Stream)
Process: 2318 ExecStartPost=/usr/share/cockpit/issue/update-issue localhost (code=exited, status=0/SUCCESS)The part that trips people up is the firewall. A plain firewalld install uses the public zone, and that zone does not include Cockpit, so another machine is refused straight away while curl -k https://localhost:9090 works fine on the server itself. Open it:
sudo firewall-cmd --add-service=cockpit --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-servicesCockpit now sits next to SSH in the list. The lock-down section at the end narrows this to your admin network, which is what you will want on any server you can reach from outside your LAN:
cockpit dhcpv6-client mdns sshLog in to the web console
Browse to https://10.0.1.50:9090, using your server’s address. Your browser will warn about the certificate, because Cockpit generates a self-signed one on first start; that is normal, and you can replace it later in this guide. You log in with a normal Linux account that has a password:
If a login that should work is refused, check these two things first, because both are defaults rather than mistakes:
rootis blocked, because it is listed in/etc/cockpit/disallowed-users; log in with your own account instead- Your account has a password; a Cloud image user that only ever logged in with an SSH key has none, so set one with
sudo passwd $USER
Once both are true, you will get in on the first try. Your account also needs to be in wheel if you want to change anything, as the next step shows.
You’ll land on the Overview page with Limited access at the top right. Click it and enter your password to switch to Administrative access, which is how Cockpit runs privileged actions through sudo for your wheel account. The Overview then shows health, usage and the system details:
From here, the left menu covers most day-to-day jobs: Logs reads the journal with filters, Services starts and stops units, Accounts manages users, and Software updates applies dnf updates through PackageKit. Terminal gives you a shell in the browser, which is handy when SSH isn’t an option from the machine you’re on.
Add the VMs, Podman and Files pages
Three add-ons turn Cockpit from a status page into a place you actually manage workloads. Install them together; on our VM this pulled in 154 packages, largely the libvirt and QEMU stack behind the VMs page, and took under two minutes:
sudo dnf -y install cockpit-machines cockpit-podman cockpit-filesReload the browser tab and three new pages appear in the menu. Each one needs something different before it is useful, so you know what to expect:
- Virtual machines needs the libvirt sockets started, which the install does not do
- Podman containers works straight away, because the page starts Podman’s socket itself, but rootless containers need lingering to outlive your login
- File browser works straight away; with administrative access on, it can read and change any file on the system
Don’t be surprised if the VMs page shows an error at this point, or if a container you started later shows as exited. The next two sections show exactly what we saw and the command that fixed each one.
Start libvirt for the Virtual machines page
Installing cockpit-machines doesn’t start the libvirt daemons, so the page opens on an error instead of an empty VM list. This is what you’ll see right after the install:
Fedora uses libvirt’s modular daemons, one per driver, each started by its own socket. Starting only the QEMU, network and storage sockets got the VM list working, but the page then showed a Failed to retrieve node devices banner, because the node device daemon was still off and virsh nodedev-list failed with Failed to connect socket to '/var/run/libvirt/virtnodedevd-sock'. Enable all four sockets the page uses:
sudo systemctl enable --now virtqemud.socket virtnetworkd.socket virtstoraged.socket virtnodedevd.socketThe install had already preset virtqemud.socket to enabled without starting it, so a reboot would start that one too, but the command above covers all four without one. Before creating guests, check that the server can run them. ls -l /dev/kvm must show the device, which on a VM like ours needs nested virtualization turned on in the host; the KVM setup guide for Fedora covers the CPU checks. You can create a VM with Create VM in the page, or with virt-install, which is what we used for a small Alpine Linux test guest. The --osinfo value is the closest Alpine release libosinfo knew; the newer ISO the first line downloads booted fine with it:
ISO=$(curl -fsSL https://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/x86_64/latest-releases.yaml | awk '/file: alpine-virt-.*x86_64.iso/{print $2}')
sudo curl -fsSL -o /var/lib/libvirt/images/$ISO https://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/x86_64/$ISO
sudo virt-install --name alpine01 --memory 512 --vcpus 1 --cdrom /var/lib/libvirt/images/$ISO --disk size=2 --osinfo alpinelinux3.21 --network network=default --noautoconsoleBack in the browser, the guest shows as running under the System connection, with buttons to shut it down, open its console and change its hardware:
Click the VM’s name to reach its console, disks and network interfaces. Guests you create here live in the libvirt system connection, the same one sudo virsh and virt-manager’s QEMU/KVM connection use, so you can move between the tools freely. A plain virsh as a normal user talks to a separate per-user session instead.
Keep rootless containers running for the Podman page
The Podman page shows both system containers and the ones your own account runs without root, and it starts the Podman API socket for you when it loads. Enabling the user socket yourself is optional but handy for other API clients; then start a test container:
systemctl --user enable --now podman.socket
podman run -d --name web -p 8080:80 docker.io/library/nginx:alpineThat container was Up when we started it over SSH. After we logged out, it stopped; a minute later podman ps -a --format "{{.Names}} {{.Status}}" showed:
web Exited (0) 3 minutes agoNothing was wrong with nginx. Rootless containers run inside your user’s systemd session, and when your last session closes, systemd stops that session and everything in it, including the container. loginctl show-user lorna -p Linger confirms that lingering is off for the account, which is the default:
Linger=noTurn lingering on, so your user manager keeps running without a login, then start the container again:
sudo loginctl enable-linger $USER
loginctl show-user $USER -p Linger
podman start webThis time we logged out and waited 85 seconds, longer than logind’s stop delay, and the container was still Up, and the Podman page shows it running under user: lorna with live CPU and memory figures:
You can stop here if you only need to watch containers. For anything you want started at boot, define it as a Quadlet unit instead of a podman run you typed once; the Podman on Fedora guide walks through that.
Manage storage and the firewall
The Storage page reads udisks2, so it shows every disk, partition and Btrfs subvolume with its mount point and usage, and live read and write graphs above them. On our VM the Cloud image’s Btrfs layout appears as one sda3 filesystem with root, home, var and boot subvolumes; a Fedora Server install shows XFS on LVM here instead:
From here you can format a new disk, create LVM volume groups or mount NFS shares without remembering the exact commands. Take care on a live server, though: the page will happily format a disk that holds data if you pick the wrong one, just like the command line would.
Under Networking, then Edit rules and zones, you get firewalld per zone. After the libvirt step, a second Libvirt zone appears for the virbr0 bridge, which is libvirt opening DHCP and DNS for its guests and not something you need to change:
Be careful when editing the zone that holds your own connection. Removing cockpit from it here locks you out of the web console the next time you connect, and removing ssh as well leaves only the server’s local console. If you’re not sure, make firewall changes from the command line over SSH, where a typo in a --permanent rule doesn’t apply until you reload. The SSH server guide for Fedora covers getting that connection in place first.
Replace the self-signed certificate
Cockpit reads certificates from /etc/cockpit/ws-certs.d and uses the last .cert file in alphabetical order, so you add yours with a higher number instead of overwriting the generated one. Ask Cockpit which certificate it would use right now:
sudo /usr/libexec/cockpit-certificate-ensure --checkOn a fresh install it is the self-signed pair Cockpit created on first start:
Would use certificate /etc/cockpit/ws-certs.d/0-self-signed.certCopy your own certificate and its key into the directory with the same base name. Use a certificate from your internal CA, or a Let’s Encrypt one if the server has a public DNS name; the example below generates one only so the commands are complete:
openssl req -x509 -newkey rsa:2048 -nodes -days 365 -subj "/CN=fedora-server.example.lan" -addext "subjectAltName=DNS:fedora-server.example.lan" -keyout server.key -out server.cert
sudo install -m 644 server.cert /etc/cockpit/ws-certs.d/50-server.cert
sudo install -m 600 server.key /etc/cockpit/ws-certs.d/50-server.key
sudo /usr/libexec/cockpit-certificate-ensure --check
sudo systemctl restart cockpitThe check now picks your file:
Would use certificate /etc/cockpit/ws-certs.d/50-server.certConfirm what the running service actually hands out, then delete the working copies so no unprotected key is left in your directory:
echo | openssl s_client -connect localhost:9090 2>/dev/null | openssl x509 -noout -subject
rm -f server.key server.certThe subject is your hostname, not the machine ID the self-signed certificate used:
subject=CN=fedora-server.example.lanAlways install the key in the same step as the certificate. On our first try the key copy failed, and the certificate alone was enough to stop Cockpit from starting at all:
cockpit-certificate-ensure: open: /etc/cockpit/ws-certs.d/50-server.key: No such file or directory
Job for cockpit.service failed because the control process exited with error code.
See "systemctl status cockpit.service" and "journalctl -xeu cockpit.service" for details.If you see that, either put the matching key in place or delete the stray .cert file, then restart cockpit. Running the --check command before every restart catches it without taking the console down.
Lock down the web console
Cockpit gives anyone who can reach port 9090 a login page for an account with sudo rights, so treat it like SSH. The most useful single change is limiting who can reach it, which takes a firewall rich rule in place of the open service. Use your own admin subnet in place of 10.0.1.0/24:
sudo firewall-cmd --permanent --remove-service=cockpit
sudo firewall-cmd --permanent --add-rich-rule="rule family=ipv4 source address=10.0.1.0/24 service name=cockpit accept"
sudo firewall-cmd --reload
sudo firewall-cmd --list-rich-rulesRun these over SSH rather than in Cockpit’s own terminal, so a mistake can’t cut off the shell you’re fixing it from. Cockpit drops out of the open services list, and only the rule for your subnet lets it through. The rule is IPv4 only, so add a matching family=ipv6 rule if you reach the server over IPv6. A browser on that subnet still got the login page in our test:
rule family="ipv4" source address="10.0.1.0/24" service name="cockpit" acceptBefore you call the server done, run through these checks once. Each one closes a gap we saw on the default install:
- Port 9090 is reachable only from your admin network (
firewall-cmd --list-rich-rules) rootis still in/etc/cockpit/disallowed-users- Only admin accounts are in the
wheelgroup, since every wheel member can switch Cockpit to administrative access cockpit-certificate-ensure --checknames your certificate, not0-self-signed.cert- Accounts used for Cockpit have strong passwords, because the login page asks for one
- Software updates shows the system as up to date, so Cockpit itself gets security fixes
If you also want the server hardened beyond Cockpit, the Fedora security hardening guide covers SSH, SELinux and auditing, and the post-install checklist for Fedora 45 is a good place to start on a brand-new machine.
