Cribl Stream configurations are deployed after the bundle containing them is saved and committed. Deploying here means propagating updated configurations to Worker Nodes.

The typical workflow for deploying Cribl Stream configurations is the following:

1. Configure.
2. Save.
3. Commit (and optionally push).
4. Deploy.

You deploy new configurations at the Worker Group level: Locate the desired Worker Group and select Deploy. Worker Nodes that belong to the group will start pulling updated configurations on their next check-in with the Leader Node.

Can’t Log In to the Worker Node as Admin User? ​

When a Worker Node pulls its first configuration, the admin password will be randomized, unless specifically changed. This means that users won’t be able to log in on the Worker Node with default credentials. For details, see Set Worker/Edge Node Passwords.

Configuration and Lookup File Locations ​

When deployed via the Leader Node, lookup files are distributed to Worker Nodes as part of a configuration deployment.

If you want your lookup files to be part of the Cribl Stream configuration version control process, we recommended deploying using the Leader Node. Alternatively, you can update your lookup file on the individual Worker Nodes, which can be useful for larger lookup files (greater than 10 MB, for example), for lookup files maintained using some other mechanism, or for lookup files that are updated frequently.

For other options, see About Lookups.

Some configuration changes will require restarts, while many others require only reloads. See Configurations and Restart for details.

Restarts and reloads of each Worker Process are handled automatically by the Worker Node. Note that individual Worker Nodes might temporarily disappear from the Leader’s Workers tab while restarting.

Worker Process Configuration Rollout ​

When a Worker Node applies configuration changes after a deploy, it updates Worker Processes in rolling batches. This keeps the Node processing data while changes take effect.

By default, 20% of running Worker Processes (minimum one) reload or restart at each step. Every Worker Process in a batch must finish reloading or report as started after a restart before the next batch begins.

If a Worker Process does not finish reloading within the configured timeout, Cribl Stream restarts it so the updated configuration applies. If the configuration bundle cannot be extracted after download, Cribl Stream reverts to the previous configuration.

Configure rollout behavior with these advanced settings on the Worker Processes tab. Consult Cribl Support before changing them.

In a Distributed deployment, configure these settings at Worker Groups > groupName > Group Settings > Worker Processes. In a Single-instance deployment, configure them at Settings > System > Service Processes. You can also set workerProcessConfigUpdateConcurrency and workerProcessReloadTimeout in the workers section of cribl.yml.

Restarts That Don’t Involve the API Process ​

These restarts roll out gradually to minimize disruption and keep as much processing capability online as possible:

• Every Worker Process in a batch must come up and report as started before the next batch begins.
• The rolling restart continues until all processes have restarted.

Restarts That Involve the API Process ​

These restarts are not rolling. All Worker Processes stop before the API Process can restart. Once the API Process restarts, it starts up all Worker Processes.