Deployment

BlazeRules deploys as an embedded library inside an application process; the core does not provide a daemon or REST API. Deployment consists of selecting the correct build for the target CPU and linking it into the host service. The optional agent and dashboard are separate executables. This page also covers the Helm chart under charts/.

📘

Process ownership

The core library has no independent service surface to expose, scale, or secure. It is deployed with the application that embeds it. The agent and dashboard are optional operational tools.

Build a release

Deploy Release builds. The repository includes CMake presets for common production targets; select the preset matching the 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

Rules, lookups, and ONNX models may use exact-object s3://bucket/key URIs through the AWS CLI cache path. Supply credentials through the environment, not 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 from its own agent config file (passed via --config, e.g. agent.yaml — this is separate from rules.yaml, which holds the rules), 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. The agent's http input (POST /v1/logs) is unauthenticated — bind it to a trusted network or front it with an authenticating reverse proxy.
• 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 access controls. The Helm chart defaults the dashboard host to 0.0.0.0 and its Service to ClusterIP. Wider exposure requires authentication and ingress controls. Do not attach a public LoadBalancer or Ingress without an authentication layer.

Containerizing the binaries

The repository does not include a Dockerfile. The Helm chart expects an image named blazerules:latest, configurable through image.repository and image.tag, with binaries at /usr/local/bin/blazerules, /usr/local/bin/blazerules_agent, and /usr/local/bin/blazerules_dashboard. Build a release with the appropriate preset, copy the executables into those paths, and publish the image to a registry.

Deploy with Helm

The chart at charts/blazerules (Chart 0.5.3, appVersion 0.5.3) renders an agent DaemonSet, a dashboard Deployment and Service, a rules ConfigMap, and a ServiceAccount. The dashboard Deployment and agent DaemonSet define hardened securityContext settings, and a NetworkPolicy restricts inbound dashboard traffic.

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

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 use an ephemeral volume and are lost on pod restart. Enable persistence and configure a storageClass when logs must be retained for audit or backtesting.

Related documentation