Uyuni is the open source systems management platform behind SUSE Multi-Linux Manager

The Spacewalk fork and the product that sits on top of it

Uyuni is an open source systems management solution, forked from Spacewalk, and it is the upstream community project from which SUSE Multi-Linux Manager is derived. That single sentence defines the project's position in the ecosystem, and it is worth reading carefully in both directions. The project is the community one, so the code, the review and the roadmap live in the open, under the GPL-2.0 licence. The product is derived from it, which means the commercial distribution is downstream of the community repository rather than the other way around. The practical consequence for an adopter is that the upstream project is the place where fixes land first and where the shape of the platform is decided, while the vendor distribution is the version with a support contract behind it. The project is hosted under the uyuni-project organisation, and the site at uyuni-project.org is the project home, with an OBS project for builds, mailing lists, a Gitter chat channel, and GitHub Discussions described as the primary asynchronous communication channel. There is also an OpenSSF Best Practices badge, which is one of the few third-party signals on the page.

What a systems management platform actually does here

The project describes itself as a systems management and configuration platform, and the topic list gives the shape of the thing: system-management, configuration, container, postgresql, podman, saltstack, spacewalk, suse-manager, java, python and reactjs. In practice this class of platform does four jobs, and the repository layout maps onto them. It inventories the estate, recording what software and hardware each managed system has. It configures systems by applying configuration from the server to a large fleet. It patches them, which is the reason the SaltStack topic is there, since a remote execution and configuration engine is what makes patching thousands of machines a single operation rather than thousands. And it reports, which is the purpose of the reporting/ and search-server/ directories. The domain names in the topic list make the supported scope clear: Linux, with SUSE Multi-Linux Manager and SUSE Manager as the related names. This is not a general IT asset inventory tool and not a configuration management tool, it is a Linux estate management server, and the deployment of one is a project in itself rather than a package you add to a pipeline.

The repository layout as an architecture map

The top level directory listing is the best architectural document the project has, and it is a large one. The java/ directory holds the server side, with the uyuni/ directory beside it as the platform's own code, spacewalk/ holding the inherited upstream code, and susemanager/ and susemanager-utils/ and susemanager-branding-oss/ holding the pieces that carry the SUSE Manager identity. The web/ directory is the browser client, with a separate package.json inside it, and the root package.json is described as a convenience wrapper for development pointing at web/package.json. The client/ directory holds the web client code and the reporting/ directory the reporting stack. Then there are the supporting pieces: proxy/ for the proxy components, containers/ for container related work, search-server/ for the search backend, schema/ for database schema, spacecmd/ for the command line client, python/ for Python components, and the rel-eng/ and projects/ and scripts/ and utils/ directories for release engineering and shared tooling. A devcontainer configuration at .devcontainer/ and a WeBLate configuration at .weblate.ini tell you that the developer experience is containerised and that translation runs through WeBLate.

The web client toolchain and its Node requirements

The root package.json is a forwarding wrapper rather than a real manifest, and it exists to keep the developer command in one place. Every script delegates to the web directory. The dev script, the build script, the lint script, the test script and the proxy script all wrap an npm --prefix web run invocation in a small shell function, and install, clean and zip are handled the same way. The engines block is the part with teeth. Node 22.x is required, npm must be 10.x or newer, and yarn is called out explicitly as deprecated with a note to use npm instead. That is a small but telling detail, because a project of this size has accumulated years of tooling decisions and the manifest is where the current one is recorded. The lint script has both a lint and a lint:production variant, the same pattern as install:production and audit-production-dependencies, which tells you that the production dependency set is audited separately from the development one. A pre-commit configuration at .pre-commit-config.yaml and a rubocop configuration for the Ruby parts round out the toolchain picture.

Where to get it and what to read first

There is no installation snippet in the project documentation page itself, and that is not an oversight. This is a server platform with multiple components, a database, a search server, a proxy and a SaltStack driven client, so the installation guidance is a documentation set rather than a command. The project home at uyuni-project.org is the entry point, and it carries the project documentation along with the contact pages for the Gitter channel, the mailing lists and the issue tracker on GitHub. The repository's own documentation/ directory is where the longer guides live, and the wiki is linked from the resources list under development guides, which is the section to read first if you are evaluating the platform rather than contributing to it. The issue tracker and the Discussions area are both listed, with Discussions named as the primary asynchronous channel, which is a reasonable place to ask the questions that will determine whether the platform fits your estate before you install anything.

The client side: SaltStack as the execution engine

The most consequential design decision in the platform is not visible in the directory listing at all, and it is the choice of SaltStack as the remote execution and configuration engine, which appears in the topic list alongside the fork lineage. That choice is what makes the platform scale, and it is also what ties your estate to a particular set of operational assumptions. SaltStack pushes configuration and commands out to managed systems and reports results back, which is why a patch campaign across a large fleet is one operation in the interface rather than a script that loops over an inventory. It also means the managed systems run a Salt minion, that the server holds the state of that relationship, and that trust configuration between them is part of your security model. For an estate that already runs Salt, or for a team that is comfortable with the model, that is a good fit. For an estate with a different existing configuration management story, the overlap is the thing to evaluate rather than the user interface.

Where the platform is the wrong answer

There are clear cases where a systems management platform is the wrong shape of tool, and the honest answer for a small estate is that a configuration management tool and a few scripts do the same job with none of the server cost. If you manage twenty machines, running a server with a PostgreSQL database, a search server, a proxy and a Salt master is a project rather than a solution, and the operational surface of the platform itself becomes the thing that breaks. The other boundary is scope. This is a Linux platform, and the fork lineage of Spacewalk, SUSE Manager and SUSE Multi-Linux Manager shows the heritage it carries, so an estate that is mostly Windows, or a mixed estate where the Windows side is the hard part, will find the coverage uneven. A third point is the relationship with the vendor product. Choosing Uyuni means choosing the community distribution rather than the product derived from it, so you get the upstream code and the upstream roadmap, and you do not get a support contract for the platform itself. That is a legitimate choice for a team with the skill to run it, and a poor one for a team that needs somebody else to answer the phone.

Editorial conclusion

Adopt Uyuni if you administer a Linux estate large enough that manual inventory and patching do not scale, and if you are prepared to run the server side yourself, since the project is a platform rather than a tool you install on a laptop. Do not adopt it for a handful of machines, where the operational cost of the server outweighs the benefit, and do not adopt it expecting the SUSE Multi-Linux Manager product, because the relationship is the other way round, with the product derived from this community project. Verify two things before you commit: that you can run the server stack, which the documentation directory and the containers/ and proxy/ directories in the tree point to, and that the saltstack based client side is acceptable in your estate, since the topic list names saltstack as the configuration mechanism. The practical first step is to read the development guides linked from the project wiki and to check the installation documentation for the server components before sizing a pilot.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. Project website
4. README
5. uyuni-project/uyuni on GitHub