Deployment Types

Deployment guide to get you started with self-hosted Cribl Stream


There are at least two key factors that will determine the type of Cribl Stream deployment in your environment:

  • Amount of Incoming Data: This is defined as the amount of data planned to be ingested per unit of time. E.g. How many MB/s or GB/day?

  • Amount of Data Processing: This is defined as the amount of processing that will happen on incoming data. E.g., is most data passing through and just being routed? Or are there a lot of transformations, regex extractions, field encryptions? Is there a need for heavy re-serialization?

Single-Instance Deployment

When volume is low and/or amount of processing is light, you can get started with a single instance deployment.

Distributed Deployment

To accommodate increased load, we recommend scaling up and perhaps out with multiple instances.

Splunk App Deployment

If you have an existing Splunk Heavy Forwarder infrastructure that you want to use, you can deploy Cribl App for Splunk. See the note below before you plan.

Cribl App for Splunk Deprecation Notice

Please see details here.

Kubernetes/Helm Deployment

You can deploy Cribl Stream Leader Nodes (or single instances) and Worker Nodes via Cribl’s Helm charts.

Docker Deployment

You can deploy Cribl Stream instances using images from Cribl’s public Docker Hub.

Shared-Nothing Architecture

All Cribl Stream deployments are based on a shared-nothing architecture pattern, where instances/Nodes and their Worker Processes operate separately, serving all inputs, outputs, and event processing independently of each other.

This allows the overall system to continue to operate even if individual Processes or Nodes fail. It also allows individual Nodes to upgrade without system-wide downtime.