Installing an Explorer

runZero requires the use of at least one Explorer within your environment to enable network discovery. The Explorer should be installed on a system with reliable connectivity to the network you want to discover. For internal networks, runZero works best when installed on a system with a wired (vs wireless) connection.

For external network discovery, nearly any cloud provider with a reliable connection should do. If the runZero Explorer is installed in a container or virtualized system, ensure that it has direct access to the network (host networking in Docker, bridged networking in VMware, etc).


To install the runZero Explorer, log in to the runZero Console and switch to the Organization that should be associated with the Explorer. Explorer downloads are then available by selecting Deploy in the left navigator and choosing the Deploy Explorers sub-menu.

Note: The Explorer download link is specific to your active organization and using the wrong link can result a new Explorer being associated with the wrong organization.

Download the correct binary for your system from the Explorer download page. For most systems, select the 64-bit (x86_64) architecture. For macOS, you will need to select 64-bit Intel (x86_64) or ARM (Apple M1), depending on your hardware. For embedded devices, such as the Raspberry Pi 3+, choose the ARM7 architecture. Windows binaries are signed with a valid Authenticode signature, which should be validated before the executable is launched.

The Explorer installation process requires administrative privileges. On Windows, a UAC prompt may be displayed. On Linux and macOS the downloaded binary should be made executable (chmod u+x runzero-explorer.bin) and then executed with root privileges (sudo or from root shell). In either case, the Explorer should install itself as a system service and start immediately, displaying a new entry in the Explorers page.

System requirements


  • Windows Server 2012 R2+ or Windows 10 Build 1604+
  • Processor running at 2.0 GHz or faster
  • At least 16GiB of memory (8GiB for small environments)
  • At least 1GB of free storage space

Windows Server 2008, Windows Server 2012, Windows 7, and Windows 8 may be able to run the Explorer in a pinch, but are not officially supported.


  • Kernel version 2.6.23 or later
  • Processor running at 2.0 GHz or faster
  • At least 16GiB of memory (4GiB for small environments)
  • At least 1GB of free storage space

Linux ARM devices with limited processing power and memory, such as the Raspberry Pi, can run the runZero Explorer, but may have trouble scanning larger networks.


  • macOS 10.11 (El Capitan) or newer
  • Processor running at 2.0 GHz or faster
  • At least 16GiB of memory (8GiB for small environments)
  • At least 1GB of free storage space

macOS systems running Catalina (10.15) or newer need to use the curl download method to avoid issues with the new Notary requirements.

BSD variants

  • Processor running at 2.0 GHz or faster
  • At least 16GiB of memory (4GiB for small environments)
  • At least 1GB of free storage space

Requires root access to a system running a recent version of the operating system. FreeBSD 11.2 or newer, recent versions of NetBSD/DragonFly/OpenBSD.

Web screenshots

Google Chrome should be installed on the Explorer system to enable web screenshots. Please note that “snap”-based Chromium installs (Ubuntu 20.04 and newer) don’t appear to work properly in headless mode and the official Chrome packages should be used instead with the following commands:

$ curl -o chrome.deb && \
    sudo apt install ./chrome.deb


Note: Some components of the application still reference the name "Rumble" for backwards compatibility. The documentation will be updated as these are changed.

The Explorer can be configured by setting variables in a .env file located in the same directory as the executable. On Windows this file should be created in C:\Program Files\rumble\.env, while other platforms should use /opt/rumble/bin/.env. The format of this file is VAR=VAL with one variable per line.

Configuration file locations

Windows: C:\Program Files\rumble\.env

Other Platforms: /opt/rumble/bin/.env

Network communication

The Explorer connects to the host on TCP port 443 using TLS and two static IPv4 addresses (, and two static IPv6 addresses (2600:9000:a415:cd87:fbe5:476a:3533:69f2, 2600:9000:a716:ee91:85f9:3c9:48c9:59b9). This connection is used for Explorer registration, job scheduling, status messages, and submission of completed scan jobs. For completely offline environments, the runZero Scanner can be used to create scan data files that can be uploaded later via the Inventory Import action. The host is used for automatic updates of the Explorer executable.

Please note that certain web proxies that perform TLS inspection do not handle Websocket communication properly and TLS inspection will need to be disabled for the runZero Explorer to successfully connect. The most popular product with this problem is the Sophos (previously Cyberoam) security appliance. Websense users may need to add a bypass rule for

Proxy support is handled automatically in most cases. On the Windows platform, proxy information is read from the registry keys (used by Chrome, Edge, and IE).

The proxy can be configured by setting the HTTPS_PROXY environment variable. The value of the HTTPS_PROXY environment variable should be a hostname and port (proxy:8080) or just a hostname (proxy). Environment variables are read from your configuration file. Please view the Configuration section to see how to set environment variables.

Removing an Explorer

The easiest way to remove an Explorer is to use the Explorers page Manage menu and choose the Remove Explorer option. This will remove the service and terminate the current explorer process. If you would like to remove the Explorer without using the runZero Console, there are a couple options.

On the Windows platform, each Explorer will be listed in Programs and Features (as the runZero Agent), and can be uninstalled like any other application.

On all platforms, including Windows, the Explorer can uninstall itself if run with the uninstall argument from a root or Administrator shell:


c:\Program Files\rumble\runzero-explorer-[oid].exe uninstall

Other Platforms

/opt/rumble/runzero-explorer-[oid] uninstall

Log management

The Explorer logs to a file and to standard output by default. On Windows the default log file location is the installation directory (C:\Program Files\runZero) while other platforms log to the files /var/log/rumble.log and /var/log/rumble.err. The default configuration limits log files to 100Mb, creates three backups, and expires logs after 90 days. These defaults can be be changed by setting the following values in the .env file:

  • The RUMBLE_AGENT_LOG_MAX_SIZE setting controls the maximum log size in megabytes. The default is 100.
  • The RUMBLE_AGENT_LOG_MAX_BACKUPS setting controls the number of backup files created by log rotation. The default is 3.
  • The RUMBLE_AGENT_LOG_MAX_AGE setting controls the maximum age in days, this applies to all files, including backups. The default is 90.
  • The RUMBLE_AGENT_LOG_COMPRESS setting determines whether to gzip compress the backups. The default is false.
  • The RUMBLE_AGENT_LOG_STDOUT setting determines whether to write logs to standard output (and syslog for systemd/upstart). The default is true.

The Explorer must be restarted for these settings to take effect.

Restart an Explorer

The quickest way is to force an update from the cloud console, otherwise you can find the service name and restart it by hand.

On Linux systems using systemd, first obtain the name of the Explorer (rumble-agent) service:

$ systemctl | grep rumble-agent

Then restart the service using this name:

$ systemctl restart rumble-agent-[uuid-value]

A kill -9 of the Explorer pid should cause a restart as well.

Certificate Authorities (CAs)

The runZero Explorer uses the system-installed certificate authorities to validate TLS connections in addition to an internal CA certificate bundle (derived from Debian 10). By default, both the system certificate roots, and the bundled roots are considered for all secure TLS connections. This behavior can be controlled via environment variables (set in the .env file or at the system level):

  • The RUMBLE_TLS_IGNORE_SYSTEM_ROOTCA setting can be set to true to ignore the system CA roots.
  • The RUMBLE_TLS_IGNORE_EMBEDDED_ROOTCA setting can be set to true to ignore the bundled CA roots.
  • The RUMBLE_TLS_ADDITIONAL_ROOTCA setting can be set to a file path containing additional CA roots in PEM format.

Manual mode

If a supported system service manager, such as systemd or upstart, is not detected, the runZero Explorer will switch to manual mode, running in the foreground, and replacing and re-executing its own binary as new updates become available. For temporary Explorer installations or to run the Explorer in a container environment, the argument “manual” can be specified:

$ sudo ./runzero-explorer.bin manual

Storage locations

The runZero Explorer installs into %PROGRAMFILES%\rumble on Windows and /opt/rumble on all other platforms. Temporary files are stored in the default operating system locations. These locations can be overridden using the .env file. Note that the Explorer service needs to be restarted (or force updated) for these changes to take effect.

On Windows, the temporary file location is chosen from the first non-empty environment value of TMP, TEMP, or USERPROFILE, falling back to the Windows directory. To override this location, set an entry in .env like the following:


On all other platforms, the temporary file location is chosen based on the value of TMPDIR, falling back to /tmp otherwise. To override this location, set an entry in .env like the following:


Any scans that fail to upload are stored in the runZero Explorer installation directory and can be imported into the platform manually or using the runZero Scanner’s --import and --upload options.

Container installations

The runZero Explorer can run in standard container environments, but may require additional configuration. To run as a standalone executable, the Explorer can be run with the argument manual. For non-persistent containers an Explorer identifier needs to be persisted through an environment variable. This can be done by setting the variable RUMBLE_AGENT_HOST_ID to a 32-character hexadecimal string. This identifier is used to uniquely identify the Explorer within an organization.

To generate a suitable identifier, the openssl tool may be used:

$ openssl rand -hex 16

Here is a sample Containerfile you can edit and use:

# Sample Containerfile for running the runZero Explorer in a container, with 
# screenshot support.
FROM debian:stable-slim

WORKDIR /opt/rumble

# Ensure curl is available and install tools for wireless scanning.
RUN apt update && apt install -y curl wireless-tools

# Install Chrome for screenshots.
RUN curl -o chrome.deb && \
    apt install -y ./chrome.deb

# Set AGENT_URL to be the download URL for your Linux runZero Explorer. To 
# find your URL, go to 
# and click on the first URL box to copy it to the clipboard.
ENV AGENT_URL=[uniqueToken]/[versionID]/runzero-explorer-linux-amd64.bin

# This ID is used to track the Explorer even if the container is rebuilt.
# Set it to a unique 32 character hex ID. You can generate one via:
# $ openssl rand -hex 16

# If you need to set environment variables to change the Explorer behavior,
# you can do so via the ENV directive. Example:

ADD ${AGENT_URL} runzero-explorer.bin

RUN chmod +x runzero-explorer.bin

# For full functionality the runZero scanner needs to send and receive raw 
# packets, which requires elevated privileges. 
USER root

# The argument `manual` tells runZero not to look for SystemD or upstart.
ENTRYPOINT [ "/opt/rumble/runzero-explorer.bin", "manual" ]

This containerfile works with podman as well as Docker. Note that because of the requirement for root privileges, you should start the container as root. For the best results, run the container with the --privileged option to allow the Explorer to listen to network traffic.

Automated installations

The Explorer will automatically install when executed if root or administrative privileges are available.

On Linux and BSD systems, automatic installation depends on the presence of a supported init service like systemd or upstart. If no supported init service is found, the Explorer will instead run in manual mode, automatically overwriting and re-executing itself with each update. To automatically deploy an Explorer on systems without a supported init service, the Explorer should be executed in the background and with the nohup wrapper.

On Windows systems, the Explorer will automatically install when run interactively or when the updater parameter is passed to the binary. For environments where MSIs are required, the Explorer MSI wrapper can be used to deploy an Explorer from the runZero Console or a local mirror.

AWS EC2 installations

The runZero Explorer can be run in an AWS EC2 instance. However, there are a number of configuration changes required to avoid packet loss when scanning.

  • DNS resolution from EC2 to the AWS DNS server has a fixed cap of 1024 packets per second which cannot be increased. To avoid this, set a custom list of non-AWS nameservers in the scan configuration advanced section.

  • Any Security Group without a 0/0 rule results in connection tracking, which has an undocumented limit on connections per instance type. Avoid this by adding 0/0 allow for ICMP/UDP inbound and outbound for the Explorer instance. Also add a 0/0 allow for outbound TCP connections. (Inbound TCP is not currently required for runZero scans, but may be needed in the future for callback protocols.)

  • Overall packet rates have undocumented limits which depend on instance type. You will need to experiment with sizing your Explorer instances until scans are consistent for a given scan rate. We hope to gather and share data on appropriate instance sizes soon.

The Explorer should work well deployed to a memory optimized, compute optimized, or general compute instance. Since the Explorer can make full use of multi-core systems, you may want to target the number of cores to the number of simultaneous scans. You probably won’t want to run larger scans on an instance with less than 32GiB of RAM.