Two searches bring people to this page. The first is a team still running Spacewalk, which has had no releases since May 2020, and which needs somewhere to go. The second is a team that runs Red Hat Satellite for its RHEL hosts and has just inherited Ubuntu, Debian or SUSE servers that Satellite cannot manage. Both end up asking the same question: what manages patching across a mixed Linux fleet without a second console for every distribution?
This guide answers it honestly. SysWard is one of the options and is listed with its limits.
The short version
| If you are coming from | Closest replacement | When to pick something else |
|---|---|---|
| Spacewalk (any version) | Uyuni, the Spacewalk fork SUSE maintains, or its supported form, SUSE Multi-Linux Manager | You do not want to operate a Salt-based control plane |
| Oracle Linux Manager | Uyuni or Multi-Linux Manager, or Oracle’s own OS Management Hub if the fleet is Oracle Linux only | Same as above |
| Red Hat Satellite, adding non-RHEL hosts | Keep Satellite for RHEL and add a cross-distribution tool, or move everything to Uyuni or Foreman with Katello | You want one console more than you want Red Hat’s content workflow |
| Nothing yet, mixed fleet | A SaaS such as SysWard, Action1 or Automox, or Uyuni if you will self-host | Air-gapped networks, where the self-hosted options lead |
Why Spacewalk shops have to move
Spacewalk was the upstream of Red Hat Satellite 5 and of the original SUSE Manager. The project was discontinued on 31 May 2020; 2.10 was the last release. Red Hat had already rebuilt Satellite 6 on Foreman and Katello, and SUSE had forked Spacewalk in 2018 to create Uyuni. Oracle kept a Spacewalk-based product, Oracle Linux Manager, but deprecated it alongside Oracle Linux 7’s end of premier support in December 2024, with extended support ending in 2026.
A management server that has not had a security release in six years is a liability in its own right, before you consider that it cannot manage RHEL 9 or 10, Ubuntu 24.04 or Debian 13 clients properly. If you run Spacewalk today, the migration is not optional; the only choice is where.
Why Satellite shops look for something more
Satellite is very good at what it is for: mirroring Red Hat content, promoting it through lifecycle environments, applying errata by host group and proving compliance to auditors, including on disconnected networks. Its limits are equally clear:
- It manages the Red Hat family. Ubuntu, Debian and SUSE hosts are outside its design, and its upstream’s deb support does not carry native errata for them.
- It is licensed through Red Hat subscriptions, so it is priced for hosts you already pay Red Hat for, not for the Rocky, Alma or Ubuntu hosts that tend to arrive through acquisitions and cloud teams.
- It is a substantial server to operate. Upgrades, capsules and content views are a job, which is fine for a platform team and heavy for a two-person infrastructure group.
None of that is a reason to leave Satellite if your estate is RHEL. It is a reason to add or switch when it is not. Our Red Hat patch management guide covers patching RHEL without Satellite at all.
The alternatives, compared
| Tool | Manages | Runs as | Cost model | Best for |
|---|---|---|---|---|
| Uyuni | SLES, openSUSE, RHEL/Alma/Rocky 8, 9 and 10, Oracle Linux, Debian 12 and 13, Ubuntu 22.04 and 24.04, Amazon Linux | Self-hosted, Salt-based | Free open source | Spacewalk migrations; teams that will run their own platform |
| SUSE Multi-Linux Manager | Same clients as Uyuni | Self-hosted, or PAYG on AWS and Azure | SUSE subscription per managed instance | Uyuni with a vendor behind it |
| Foreman with Katello | RHEL family first; deb content for Debian and Ubuntu without native errata | Self-hosted | Free open source | Satellite-style lifecycle management without the subscription |
| Red Hat Satellite | Red Hat family | Self-hosted, disconnected supported | Red Hat subscription | RHEL estates, regulated and air-gapped |
| Native tools plus Ansible | Everything | On each host, your playbooks | Free | Small fleets with configuration management already in place |
| SysWard | Ubuntu, Debian, RHEL, CentOS, Rocky, Alma, SUSE, Amazon Linux | SaaS, or a self-hosted appliance | Free for 5 servers, then per agent | Mixed fleets that want CVE context and an audit trail without operating a server |
| Action1, Automox | Major Linux distributions plus Windows and macOS | SaaS | Per endpoint (Action1 free to 200) | Estates where Linux is a minority next to Windows |
Uyuni and SUSE Multi-Linux Manager
If you are leaving Spacewalk, this is the path of least surprise. Uyuni is Spacewalk’s fork, the web interface will look familiar, and its client list is the broadest of any self-hosted option: the whole RHEL family through version 10, Debian 12 and 13, Ubuntu 22.04 and 24.04, SUSE and openSUSE, Oracle Linux and Amazon Linux. Execution moved from Spacewalk’s client daemon to Salt, which is the main thing your team learns. Multi-Linux Manager is the supported product built from Uyuni; it reached version 5.1 in July 2025 and can be bought pay-as-you-go on AWS and Azure as well as by subscription.
Where it is weaker: it is a platform. Expect to own a Salt master, a database, channel mirroring and upgrades, and to schedule time for each of them. Teams that adopted Spacewalk because it was already there sometimes find they never wanted to run a management server at all.
Foreman with Katello
Foreman is the provisioning and configuration platform Satellite 6 is built on, and Katello adds the content management, errata and lifecycle environments that make it a patching tool. For RHEL, Rocky and Alma it is Satellite without the subscription, and it can carry deb repositories for Debian and Ubuntu hosts. What it lacks on the Debian side is native errata, so security-only updates and CVE reporting for those hosts need external services that map Debian Security Announcements and Ubuntu Security Notices onto packages, which several teams run but Katello does not ship.
Where it fits: a team that wants lifecycle management and provisioning, not only patching, on a mostly Red Hat-family fleet. Upgrades between Foreman versions are their own project, as they are with Satellite.
A SaaS with a self-hosted option
SysWard is the option we build, so read this section with that in mind. It manages Ubuntu, Debian, RHEL, CentOS, Rocky, Alma, SUSE and Amazon Linux with one agent and one workflow: the agent reports installed packages and pending updates, the service matches them against the current CVE feeds, you schedule rollouts by group, and every applied or failed update is recorded per host for the audit trail. There is no management server to run; the self-hosted appliance is the same product on your own VM for teams that cannot use SaaS. It is free for 5 servers with no card.
Where it does not fit: it does not mirror repositories or promote content through lifecycle environments, so it is not a Satellite replacement for teams whose workflow is content views. It is a patching and vulnerability tool, not a provisioning platform. Fully air-gapped networks are better served by Uyuni, Multi-Linux Manager or Satellite, which document disconnected operation. Action1 and Automox are the equivalent choice when Windows and macOS endpoints outnumber Linux servers; the ten-tool comparison covers both.
Native tools plus Ansible
unattended-upgrades, dnf-automatic and a zypper patch timer, driven by Ansible with serial batches, is a real alternative for a small fleet, and it is what many Spacewalk shops quietly ran alongside it. It costs nothing and needs no server. What it does not give you is CVE context or a central record of what was applied where, which is the moment most teams reach for one of the tools above. The automation guide is the long version.
Migration notes
Spacewalk to Uyuni. Uyuni documents a migration from Spacewalk servers, but treat it as a rebuild with a data import rather than an upgrade: stand up a new Uyuni server, recreate channels, register clients with the Salt minion, and decommission Spacewalk once the last client has moved. Do the RHEL-family hosts first; they are the ones Spacewalk was serving well, so they validate the new server before you register the Ubuntu and Debian hosts it never managed.
Satellite plus a second tool. If Satellite stays for RHEL, the cleanest split is by responsibility, not by host: Satellite keeps content and lifecycle for the Red Hat family, and the cross-distribution tool owns the patch schedule, CVE reporting and the audit record for everything. Avoid two tools both applying updates to the same host on their own schedules.
Satellite to Foreman. Foreman with Katello is the same lineage, so the concepts carry over one to one. What you lose is Red Hat’s content delivery and support; what you gain is a free platform you can also point at Debian and Ubuntu content. Plan for the errata gap on the deb side before you commit.
Anything to SaaS. Install the agent on a pilot group, run it read-only next to the existing tool for two weeks to compare inventories and CVE lists, then move the patch schedule group by group. Because the agent only reports and applies packages, the old server can stay in place until the last group has moved.
How to decide
- Is the fleet the Red Hat family only? Stay on Satellite, or move to Foreman with Katello if the subscription is the problem.
- Are you leaving Spacewalk with a team that likes running platforms? Uyuni, or Multi-Linux Manager for support.
- Is the fleet mixed and the team small? A SaaS with a self-hosted option, and keep the native tools as the mechanism underneath.
- Is the network air-gapped? Uyuni, Multi-Linux Manager or Satellite, in that order of breadth.
Ready to see how a mixed fleet looks in one console? Start free with 5 agents, no card required, or read the ten-tool comparison first.