Mandatory flows

The following flows from the Nodes to the Rudder Root Server (or Relay Server) have to be allowed:

Port 5309, TCP
Agent communication port, used to fetch policy and shared files from the policy server.
Port 443, TCP, for nodes
WebDAV/HTTPS communication port, used to send inventory and fetch the id of the Rudder Server.
Port 514, TCP/UDP
Syslog port, used to centralize reports.

And this one is optional:

Port 5310, TCP
Agent communication port, used to communicate the policies to the Rudder nodes when debugging communication between a Node and a policy server with the rudder server debug command.

Open the following flow from the clients desktop to the Rudder Root Server:

Port 443, TCP, for users
HTTPS communication port, used to access the Rudder web interface or API.

Optional flows

These flows are recommended for compatibility:

Port 80, TCP, for nodes
WebDAV/HTTP communication port, kept for compatibility with pre-3.1 nodes and AIX nodes.

These flows are used to add features to Rudder:

Port 5309, TCP
Agent communication port, used to trigger an agent run on a node from its policy server.
CFEngine Enterprise
Managing Windows machines requires the commercial version of CFEngine, called Enterprise. It needs to open the port 5308 TCP from the Node to the Rudder Root Server.

This version used to be called Nova before.

DNS - Name resolution

If you want to be able to trigger agent runs from the Root Server (without having to wait for regular automated run), you will need your Root Server (or Relay Server) to be able to resolve your nodes using the provided hostname.

JVM Security Policy

Rudder needs unlimited strength security policy because it uses a variety of advanced hashing and cryptographic algorithms only available in that mode.

Any recent JVM (JDK 8 > 8u161, all JDK 9 and more recent) is configured by default with this policy.

You can check your case by running the following command on your server:

jrunscript -e 'exit (javax.crypto.Cipher.getMaxAllowedKeyLength("RC5") >= 256 ? 0 : 1);'; echo $?

If it returns 0, you have the correct policy. In other cases, you will need to change it.

For that, you can download the unlimited strength policy for JDK 8 here.

Then, simply copy the java.policy file into $JAVA_HOME/jre/lib/security/java.policy.

Fully supported Operating Systems

Fully supported Operating Systems are systems that are frequently built and tested on our servers. Partially suported Operating Systems are systems that have been built and tested at least once but that have not seen continuous flow of fixes.

For Rudder Nodes

The following operating systems are supported for Rudder Nodes and packages are available for these platforms:


  • Debian 5 to 9
  • RedHat Enterprise Linux (RHEL) / RHEL-like 3 and 5 to 7
  • Fedora 18
  • SuSE Linux Enterprise Server (SLES) 10 SP3, 11 SP1, 11 SP2, 11 SP3, 11 SP4, 12, 12 SP1, 12 SP2
  • Ubuntu 10.04 LTS (Lucid), 12.04 LTS (Precise), 12.10 (Quantal), 14.04 LTS (Trusty), 16.04 LTS (Xenial), 18.04 LTS (Bionic)

Other Unix systems:

  • IBM AIX 5.3, 6.1 and 7.1


[Tip]Windows and AIX Nodes
  • On Windows, installing Rudder requires the commercial version of CFEngine (named CFEngine Enterprise)
  • For IBM AIX, pre-built RPM packages are distributed by Normation only

Hence, as a starting point, we suggest that you only use Linux machines. Once you are accustomed to Rudder, contact Normation to obtain a demo version for these platforms.

For Rudder Root Server

The following operating systems are supported as a Root server:


  • Debian 7, 8 and 9
  • RedHat Enterprise Linux (RHEL) / CentOS 6 and 7
  • SuSE Linux Enterprise Server (SLES) 11 SP1 and SP3, 12 SP1, 12 SP2
  • Ubuntu 14.04 LTS (Trusty), 16.04 LTS (Xenial)

Partially supported Operating Systems

Fully supported Operating Systems are systems that are frequently built and tested on our servers. Partially suported Operating Systems are systems that have been built and tested at least once but that have not seen continuous flow of fixes.


[Warning]Partially supported Operating Systems

It is possible to use Rudder on other platforms than the fully supported ones. However, we haven’t tested the application on them, and can’t currently supply any packages for them. Moreover, some Techniques may not work properly. If you wish to get Rudder support on those systems, please get in touch with us!

A reference about how to manually build a Rudder agent is available on Rudder's documentation here: Building the Rudder Agent

For Rudder Nodes

The following operating systems have had an agent built using Building the Rudder Agent:

  • FreeBSD
  • Slackware
  • Solaris 10 and 11
  • Raspbian, based on jessie (via dpkg)
  • Debian 8 on ARM (armhf version) (via dpkg)
  • OpenSUSE (via rpm)

You can also follow the documentation instructions to build and install Rudder Agent locally on your favorite linux distribution. Even if this distribution has not been tested by us, it has a reasonable chance of success.

For Rudder Root Server

We advise against using an unsupported OS for Rudder server because the server contains much more code than the agent. This code is tailored against specific OS versions to work around many system limitations and specificities.

Cloud compatibility

The agent provides an abstraction that permits a high level management of the infrastructure. This abstraction is independant of the underlying hardware. This also works for the cloud - we can define configuration rules in Rudder that will be applied as well inside a cloud instance as in a virtual server or in a physical machine of a datacenter.

Any cloud instance based on one of the supported operating system is automatically supported.

Hardware specifications for Rudder Agent

Rudder agent has a very small footprint, and only consumes:

  • 10 to 20 MB of RAM during an agent run
  • a few kB on the network to check or update its policies
  • a few kB on the network to report
  • around 100 MB of disk space for the installed files and the workspace

These figures will vary depending on your configuration (backup retention, number of configured components to check, etc…).

Hardware specifications and sizing for Rudder Root Server

A dedicated server is strongly recommended, either physical or virtual with at least one dedicated core. Rudder Server runs on both 32 (if available) and 64 bit versions of every supported Operating System.


Rudder does not fear big infrastructures. It is currently used in production in infrastructure with more than 7000 nodes.


The required amount of RAM mainly depends on the number of managed nodes. A general rule for the minimal value on a stand-alone server is:

  • less than 50 nodes: 2 GB
  • between 50 and 1000 nodes: 4 GB
  • more than 1000 nodes: 4 GB + 1 GB of RAM by 500 nodes above 1000.

When managing more than 1000 nodes, we also recommend you to use a multiserver installation for Rudder as described in chapter Multiserver Rudder.

When your server has more than 2 GB of RAM, you have to configure the RAM allocated to the Java Virtual Machine as explained in the section about webapplication RAM configuration.

When your server has more than 4 GB, you may need to also tune the PostgresSQL server, as explained in the Optimize PostgreSQL Server section.


As an example, a Rudder server which manages 2600 nodes (with a lot of policies checked) will need:

  • A server with 8 GB of RAM,
  • 4 GB of RAM will be allocated to the JVM.

In our load-tests, with such a configuration, the server is not stressed and the user experience is good.


The PostgreSQL database will take up most disk space needed by Rudder. The storage necessary for the database can be estimated by counting around 150 to 400 kB by Directive, by Node and by day of retention of node’s execution reports (the default is 4 days):

max_space = number of Directives * number of Nodes * retention duration in days * 400 kB

For example, a default installation with 500 nodes and an average of 50 Directives by node, should require between 14 GB and 38 GB of disk space for PostgreSQL.

Follow the Reports Retention section to configure the retention duration.


Be careful to correctly size your /var partition. Compliance data are growing fast, and PostgreSQL doesn’t like at all to encounter a write error because the disk is full. It is also adviced to set-up your monitoring to check for available space on that partition.