Beyond ZeekControl

This post provides an overview of the direction the Zeek project is taking around ZeekControl and its intended successor, the Management Framework.

The primary and suggested way to run a Zeek deployment for live traffic monitoring today is ZeekControl. For multi-host deployments, it’s been the tool of choice because it conveniently bundles all the required functionality: it renders configuration files, distributes installation artifacts, configuration and Zeek scripts across systems via rsync, spawns Zeek processes remotely on all systems via SSH (nohup and double exec to daemonize), monitors processes (local and remote) by means of a cron job running on the manager system, rotates and archives logs, and also allows interacting with individual Zeek processes (netstats and print commands). When configured, it also sends emails with daily connection summaries, process crashes, or when the network interface loses connectivity.

Since ZeekControl’s inception almost two decades ago, the landscape for deploying, monitoring and running software has changed significantly and we’ve been adapting Zeek to better fit into this world by leveraging more modern tooling. Our goal is to make simple single-host Zeek deployments straightforward (e.g. for home network or small office monitoring setups), while also providing patterns and answers for large-scale and complex multi-host Zeek deployments.

The Supervisor and Management Frameworks

Moving beyond ZeekControl has been a long term effort within the Zeek project. The first step was the introduction of Zeek’s Supervisor framework in 2019, essentially introducing support for spawning Zeek processes using the Zeek scripting language itself. The Management Framework started around 2021 and builds on top of the Supervisor and Cluster frameworks to spawn and orchestrate Zeek processes across single or multiple systems. The Management Framework introduced a persistent service model by adding two new process roles to a Zeek cluster that always run: agent and controller. Agent processes leverage the Supervisor API to spawn Zeek processes. The controller process interacts with agent processes via Zeek’s Cluster framework. The user-facing zeek-client interacts with the controller process by means of Zeek’s WebSocket API and the Cluster framework. Except for zeek-client, which is implemented in Python, the Management Framework’s implementation is fully in Zeek script.

Current State

Development of the Management Framework has stalled in recent years due to higher priority tasks and responsibilities. Few users have tried it, or if they have, have not provided feedback and we believe adoption rate has been very low if any.

Many users still rely heavily on ZeekControl, even adapting it creatively to run inside containers or in Kubernetes clusters.

Other Zeek power users (e.g. Corelight, ESnet, governmental institutions) have over the years implemented their own ad-hoc solutions to run Zeek when ZeekControl wasn’t a good fit. Corelight, for example, initially used a minimal runit-based setup and later switched to a proprietary self-contained process supervisor with focus on single-host deployments.

While Corelight’s implementation wasn’t immediately suitable for upstreaming, there has also been limited interest in leveraging ZeekControl, Zeek’s built-in Supervisor, or the Management Framework on their appliance, presenting a gap, but also opportunity to align this divergence.

In late 2025, a separate approach around Zeek deployment and process management using a native systemd generator and a new zeek.conf configuration file was merged into the Zeek tree. This setup allows users to easily spawn and supervise Zeek processes on a single host by leveraging systemd-native functionality. It has basic support for log rotation and archiving, but excludes various functionality provided by ZeekControl. The assumption is also that installation of Zeek itself, additional scripts and packages, and configuration files is done using standard configuration management tooling. The focus of the generator is on spawning and supervising the processes that form a Zeek cluster. For the upcoming Zeek 9.0 release, multi-interface support and a preview of multi-host cluster deployment has landed in Zeek’s master branch recently. Multi-host support has been refined in collaboration with engineers at ESnet. We continue to look for feedback, input and further ideas on the approach.

Going Forward

ZeekControl will continue to exist and we’ll maintain it as little or as much as we’ve done in the past years. Meaning we’ll keep it around and ship it with Zeek, but you won’t see major enhancements to it.

Our assumption is that there are no large scale deployments of Zeek clusters orchestrated using the Management Framework and we are officially sunsetting its development. The current plan is to move the policy scripts out of Zeek’s tree and into an external package. The Supervisor Framework and its API will stay within Zeek for the time being, but eventual deprecation is a topic being discussed.

Why

On major Linux distributions, process supervision has essentially been solved by systemd. For other operating systems (or non-systemd environments), s6, runit, supervisord, and a multitude of other projects offer alternatives. There’s little reason in 2026 to build and maintain a full-fledged process supervisor, let alone integrate it with a domain specific language tailored for network monitoring.

Additionally, Zeek processes should be strictly confined and sandboxed from the rest of the system. systemd excels at this without needing to write any code. On Linux, other supervisors can leverage bwrap or nsjail to isolate the spawned Zeek processes, or run all processes in strictly locked-down containers. On non-Linux operating systems, other primitives are available.

Further, looking at the Management Framework from a higher level, you’ll see concepts that exist in standard container orchestrator platforms like Kubernetes today (an agent that offers an API to deploy a workload, that’s the kubelet in Kubernetes). We’re not going to ask users to use Kubernetes or Nomad to deploy multi-host Zeek clusters. We do want to promote the idea, however, that if you use Kubernetes in your infrastructure, you can leverage it to deploy and monitor a Zeek cluster and it would fit nicely with how modern infrastructure works.

Some ideas around this were sketched and presented at the CERN Zeek workshop earlier this year. When not using containers and instead deploying Zeek directly on the OS, any configuration management system (Puppet, Salt, Chef, Ansible, etc.) can be leveraged to install Zeek and roll out the appropriate zeek.conf files to individual systems. At this point, we will not provide or maintain official orchestration playbooks or automation roles. We expect multi-host deployments to handle config distribution using their own existing infrastructure tools. This isn’t a step back from where the Management Framework was headed: it already assumed the existence of some configuration management tooling to install Zeek and start the agent and controller processes.

To interrogate the state of a Zeek cluster at runtime, we’ll keep the idea of offering a WebSocket API used by zeek-client to provide commands like ZeekControl’s print and netstats.

systemd only?

The zeek-systemd-generator executable essentially translates the zeek.conf configuration file into running Zeek processes. systemd generators are a native systemd mechanism and are only applicable to that environment. Many Zeek deployments (including those at Corelight and ESnet) run on Linux, so that’s the project’s focus for the time being. We understand this excludes various other operating systems and non-systemd Linux distributions. We are more than open and interested in discussions and potential volunteers to implement, for example, a s6-generator and would happily merge and maintain it upstream to support the non-systemd Linux, FreeBSD or OpenBSD crowd out there. The zeek.conf configuration file is designed to be operating system and supervisor agnostic and the parsing logic separated partly into a re-usable library already.

A Single-Host zeek.conf Example

You find an example configuration for a Zeek cluster with 3 interface sections, 16 workers in total and 4 proxies and 3 loggers below. This format will be available with Zeek 9.0.

[zeek]
manager = 1
loggers = 3
proxies = 4

[interface eth0]
interface = af_packet::eth0
workers = 4
worker_args = ignore_checksums=T

[interface napatech]
interface = napatech::${worker_index0}
workers = 8
workers_cpu_list = 4-11

[interface geneve]
interface = udp::0.0.0.0:6081:geneve
workers = 4

For a multi-host cluster, multiple zeek.conf files are placed into the <PREFIX>/etc/zeek/cluster directory on the participating hosts. Check out the docs for a walkthrough.

Summary

• zeek.conf + zeek-systemd-generator with multi-interface support to run Zeek on Linux easily and robustly without ZeekControl will be available with Zeek 9.0.
• Preview and docs for running multi-host Zeek deployments available with Zeek 9.0.
• We’re open to contributions for other process supervisors leveraging zeek.conf to support non-Linux or non-systemd distributions.
• ZeekControl will stick around. It’ll continue to be in maintenance mode.
• Development of the Management Framework will officially cease and the scripting code made available as an external Zeek package.

If you are a heavy Management Framework or Supervisor API user and are concerned about the direction we’re taking, we would like to hear from you. Nothing here is completely set in stone and we’d gladly hear feedback now rather than long after the fact. To get in touch, reach out on community.zeek.org, our #development channel on Slack, or write to info@zeek.org to help us shape where this goes.