Deployment

BlazeRules deploys as an embedded library inside your own process — there is no daemon or REST API in the core. "Deploying" therefore means building the right release for your target CPU and linking it into your service. The optional agent and dashboard are separate executables you can run alongside it; this page covers both, plus the real Helm chart under charts/.

📘

You own the process

Because the core is a library, there is no service to expose, scale, or secure on its own. You deploy BlazeRules by deploying the application that embeds it. The agent and dashboard are conveniences, not the product.

Build a release

Always deploy Release builds. The repo ships CMake presets for the common production shapes so you don't hand-assemble flags. Pick the preset that matches your target CPU:

cmake --preset linux-x86_64-release-dispatch
cmake --build --preset linux-x86_64-release-dispatch -j

🚧

Don't ship -march=native builds

BLAZERULES_NATIVE_TUNE and the linux-release-native preset tune for the build machine's CPU. They are great for local benchmarking and unsafe for portable deployment — a binary tuned for one microarchitecture can fault or underperform on another. For fleets with mixed CPUs, use a *-dispatch or cloud-portable-release build, which compiles ISA-specific kernels separately and selects one at runtime.

Choose a SIMD backend per platform

The dispatch presets pick a backend automatically. Override only with a measured reason (see Configuration Reference).

AWS credentials

If your rules, lookups, or ONNX models live in S3, the engine reads exact-object s3://bucket/key URIs via the AWS CLI cache path. Supply credentials through the environment, not your YAML:

export BLAZERULES_AWS_PROFILE=production
export BLAZERULES_AWS_REGION=us-east-1
export BLAZERULES_AWS_ENDPOINT_URL=https://s3.us-east-1.amazonaws.com

In Kubernetes, mount these from a Secret (or use IRSA / the node's role) — never bake them into the chart values or a config map.

Agent and dashboard

Two executables ship for operational convenience in full builds (Configuration Reference).

• blazerules_agent — a multi-input ingest process. It reads a top-level instances: block (see rules.yaml), pulling from http, file_tail, or stdin inputs and writing decisions to an ndjson or stdout output. In the chart it runs as a DaemonSet: blazerules_agent --config /etc/blazerules/agent.yaml.
• blazerules_dashboard — a local read-only UI that renders decision and dead-letter logs. Run it directly with --host, --port, --decision-log, --dead-letter-log, and --rules:

./cmake-build-release/blazerules_dashboard \
  --host 127.0.0.1 --port 9470 \
  --decision-log /var/log/blazerules/decisions.ndjson \
  --dead-letter-log /var/log/blazerules/dead_letters.ndjson \
  --rules rules.yaml

❗

The dashboard is read-only and unauthenticated — never expose it publicly

The dashboard has no authentication. Bind it to 127.0.0.1 for local use, or keep it cluster-internal behind your own access controls. Note that the Helm chart defaults the dashboard host to 0.0.0.0 and its Service to ClusterIP — that keeps it inside the cluster, but you must still put authentication/ingress controls in front of it before any wider exposure. Do not attach a public LoadBalancer or Ingress without an auth layer.

Containerizing the binaries

The repo does not include a Dockerfile, so you build and publish the image yourself. The Helm chart expects an image named blazerules:latest (configurable via image.repository / image.tag) whose binaries live at /usr/local/bin/blazerules_agent and /usr/local/bin/blazerules_dashboard — those are the exact paths the chart's command: entries invoke. Build a release with the appropriate preset above, copy the resulting executables to those paths in your image, and push it to your registry.

Deploy with Helm

A real chart lives at charts/blazerules (Chart 0.1.0, appVersion 0.1.0). It renders an agent DaemonSet, a dashboard Deployment + Service, a ConfigMap for rules, and a ServiceAccount.

helm install blazerules ./charts/blazerules \
  --set image.repository=your-registry/blazerules \
  --set image.tag=0.1.0

Key values (defaults shown):

image:
  repository: blazerules
  tag: latest

agent:
  enabled: true
  mode: daemonset
  batchSize: 2048
  flushMs: 1000
  input: {type: file_tail, path: /var/log/containers/blazerules.log}
  output: {type: ndjson, path: /var/log/blazerules/decisions.ndjson}

dashboard:
  enabled: true
  port: 9470
  host: 0.0.0.0
  service: {type: ClusterIP}
  decisionLogPath: /var/log/blazerules/decisions.ndjson
  deadLetterLogPath: /var/log/blazerules/dead_letters.ndjson
  metricsUrl: ""

persistence:
  enabled: false
  size: 10Gi

The agent writes the decision log; the dashboard reads it (plus the dead-letter log) — wire both to the same paths, which the defaults above already do. The dead-letter log is populated when the agent runs with ingest_error_mode = IngestErrorMode.SKIP_TO_DEAD_LETTER. The chart's dashboard.metricsUrl is empty by default; when set, it should point to a Prometheus exposition endpoint such as http://127.0.0.1:9464/metrics.

📘

Persistence is off by default

With persistence.enabled: false, decision and dead-letter logs are written to an ephemeral volume and lost on pod restart. Enable persistence (and a storageClass) if you need to retain logs for audit or backtesting.

Where to go next