Rudder manages configuration and security posture across estates

What the platform is for

Rudder is described as a system infrastructure automation platform, dedicated to empowering IT operational teams to ensure and improve their security posture and fostering collaboration in Security Operations. The repository description puts it more plainly: a configuration and security automation platform for managing cloud, hybrid or on-premises infrastructure.

The feature list is organised into four groups, and the grouping is the point. Under security posture management come automated systems inventory, patch management, vulnerability management, and system hardening and security standards compliance. Under configuration management comes the policy work, with the note that configuration policies can be created using a visual editor or as YAML code, along with what the README calls advanced compliance visualization. Then multi-platform support, covering cloud, hybrid and on-premise setups running on Linux or Windows, and a scalable and dynamic approach described as including a hierarchical configuration data engine and automated classification of managed systems.

The scale claim in the README is that typical deployments manage hundreds to thousands of systems and a single Rudder server can manage more than 10k systems. That is the number to hold on to when sizing, and it is stated by the project rather than measured here.

The repository is written in Scala and Rust, with the Cargo.toml workspace listing the Rust members: the agent, agentd, rudderc, the module type API, the CLI, the commons, the report library, and module types for augeas, commands, inventory, system-updates, template, secedit and scheduler, plus the relay sources. The workspace declares edition 2024, licence GPL-3.0-or-later and a rust-version of 1.98.1.

The homepage is rudder.io, with documentation at docs.rudder.io and a bug tracker at issues.rudder.io.

Server, relays and the agent on every host

The components section of the README describes the architecture, and it is the part that determines whether the model fits your estate.

A Rudder installation is made of three things. A central server provides the web interface, the HTTP API and the automation engine, and it can be extended with plugins. Relays are optional, and they act as smart proxies between the server and the agents. And a light agent is installed on every managed system, where it runs autonomously and checks and modifies the state of the system continuously, in practice every five minutes by default.

That last detail is the one to think about. The agent is pull-based and periodic, not event driven. Every managed host wakes up on its own interval, checks what it should look like against what the policy says, and corrects the difference. That is why the system is described as continuous configuration rather than as a deployment tool, and it is also why the relays exist: they are a way to fan out to a large estate without every host opening a connection to the central server.

The separation also has a security consequence that is easy to miss. The server holds the policies, the inventory and the API, and it never connects to the managed hosts. The agents connect outward. In an estate where the server sits in a different security zone from the machines it manages, or where the managed machines are in datacentres you do not want to expose, that direction matters.

The module types in the Rust workspace show how the policy work is decomposed. There are separate types for augeas, commands, inventory, system-updates, template, secedit and scheduler, plus a rudder-module-type crate that is presumably the interface those implement. The secedit type is the one that ties back to the security standards compliance claim, and the inventory type to automated systems inventory.

Installing Rudder, and the free trial path

There is a documented step by step installation in the documentation, and the README points at it for a standard setup with or without a subscription, followed by a get started guide with a hands-on tutorial on configuration policies.

For a quick setup on Linux systems there is an installer script, and the server invocation is:

curl --proto '=https' --tlsv1.2 -sSf https://repository.rudder.io/tools/rudder-setup | sh -s -- setup-server latest

The agent uses the same script, with the server's IP or hostname substituted for SERVER:

curl --proto '=https' --tlsv1.2 -sSf https://repository.rudder.io/tools/rudder-setup | sh -s -- setup-agent latest SERVER

The protocol and TLS version flags are pinned in the command itself, which is a reasonable thing for a script that fetches and runs code on a machine.

The README also tells you how to review the script before running it, which is the better habit for a security tool:

wget https://repository.rudder.io/tools/rudder-setup
chmod +x rudder-setup
./rudder-setup -h

So a full evaluation of the platform without touching a server is possible. The README links a demo web interface at demo.rudder.io with fake data, described as a way to get a glimpse of the available features and interfaces, and the site also offers a free trial on request. The tip box in the installation section is explicit that an active subscription is needed for a complete setup including the security features, and that without one you get Rudder Core only, and that an existing Rudder Core installation can be upgraded to a subscription or a free trial license at any time.

The open-core split, in the project's own terms

The FAQ is unusually direct about the commercial model, and this is the section to read before anything else.

Rudder has adopted an open-core model. Rudder Core is available for free and totally open-source, under GPL 3.0 or an Apache 2.0 licence, and it includes the main Rudder components, Linux agents, plus several plugins. The complete Rudder solution is paid and partially open-source, with a part of the paid plugins and agents distributed under a proprietary licence.

What the subscription adds is listed precisely: additional plugins that add major features, support for older versions on Linux distributions, support for additional architectures, ARM32 and ARM64, support for Windows, extended support for Rudder releases, professional support and user assistance, and training.

The two editions are described as serving different purposes. Rudder Core is a versatile automation engine for mainstream Linux systems with a complete web UI, built to give access to essential configuration management and inventory features to small businesses and individuals. Rudder is a multi-platform operational security solution, answering the needs of most organizations, including enterprise setup and critical infrastructures.

The most useful sentence in the FAQ is about how the packages relate. Rudder Core is a subset of the full solution, and the packages publicly available are identical to the packages provided to subscription users, with the same QA and security processes. The README calls this not a two-speed model but a two-scope model. The practical meaning is that you are not getting a worse build of the same thing, you are getting fewer features, and a decision to upgrade later does not mean reinstalling anything.

Upgrading from Core, and who governs the project

The upgrade question has its own FAQ entry, and the answer is short.

The full Rudder solution is a direct super-set of Rudder Core, so you do not have to reinstall anything, and your server and agents are compatible with the additional features, which come as plugins. You may just need to change the repository URL on your systems to benefit from the extended maintenance in the future.

That last part is the operational detail worth remembering. The switch is a repository URL and a plugin set, not a migration project, which is an unusual position for open-core software to be in and reduces the cost of starting on Core.

On governance, the README says the project is lead by the French company of the same name, previously known as Normation. The repository still carries the Normation organisation name, and the Cargo.toml lists the authors as Rudder developers with the [email protected] address, so the rename is recent in the tooling as well as in the branding.

The repository layout backs up the scale of the operation. Beyond the Rust workspace there is a webapp/ directory for the server's web interface, a relay/ directory, a docker/ directory, an adr/ directory for architecture decision records, a qa-test directory, a policies/ directory, a sbom/ directory for a software bill of materials, and a trivy.yaml with a .trivyignore, which is a container vulnerability scanner configuration and tells you the security posture of the build pipeline itself. There is also a Jenkinsfile and a Jenkinsfile-security for CI, an AI_POLICY.md, a SECURITY.adoc alongside SECURITY.md, and a LICENSE_EXCEPTION file with a LICENSES/ directory for the third party licence accounting.

Where Rudder fits against the alternatives

The comparisons worth making are with the other tools in this space, and the differences are about scope rather than about which one is better.

Against a configuration management tool such as Ansible or Puppet, the difference is where the logic lives. In those tools, the desired state is expressed as a play or a manifest that is executed against hosts, and the host state is whatever the last run left behind. Rudder keeps a persistent server side model of the desired state, with the policy, the inventory and the compliance view on the server, and the agent on the host continuously reconciles towards it. The README's phrase continuous configuration and its five minute agent cycle describe that model.

Against a security posture management tool, the difference is that Rudder reaches the remediation step. Most posture tools tell you a host is missing a hardening rule and leave it there. Rudder's security posture management list includes hardening and security standards compliance alongside patch and vulnerability management, which is remediation expressed as policy rather than as a separate workflow.

The trade for the operator is that the agent must be installed and run with enough privilege to change system state, and a periodic agent is a different operational model from a push or an agentless scan. For a fleet of thousands of hosts with an internal CA and a controlled network, that is usually a reasonable price. For a handful of cloud instances that are recreated often, it may be more machinery than the job needs.

The open-core split is the other axis of comparison, and it is unusual in how it is handled. The statement that the public packages are identical to the subscription packages, with the same QA and security processes, means the free edition is not a degraded build. What it means in practice is that the feature list is where the commercial decision lives, and for a team that needs Windows agents or the older Linux distribution support, that decision is made for them.

Editorial conclusion

Rudder suits a security operations team that wants configuration management and compliance reporting to come from the same engine, since the inventory, the policies and the audit trail live in one place and the agent approach does not require an agent on the server side. It is the wrong tool if you need Windows agents, because support for Windows is one of the listed benefits of the paid product, and it is the wrong tool if you want a single open-source artefact, because the security features live in the subscription. Before evaluating, read the Rudder Core section of the README to see exactly which features the free edition omits, and try the demo web interface at demo.rudder.io with its fake data before running the installer on a real server.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Normation/rudder on GitHub
3. Project website
4. README
5. Releases