Skip to content

Verifying

The cheapest test of the three states is a packet capture. Run all three.

sudo tcpdump -n -i any 'host prometheus.log10x.com or host api.log10x.com' &

# State 1: no license. Expect no vendor traffic.
tenx run @run/input/forwarder/fluentbit @apps/receiver

# State 3: a license AND an endpoint. Expect whoami, write, and the
# per-pattern metrics the shipped Receiver config sends to the same host.
TENX_LICENSE_KEY="$(cat license.jwt)" \
  TENX_BACKEND_ENDPOINT=https://prometheus.log10x.com/ \
  tenx run @run/input/forwarder/fluentbit @apps/receiver

# State 2: the same run, air-gapped. Expect no vendor traffic.
TENX_LICENSE_KEY="$(cat license.jwt)" \
  TENX_BACKEND_ENDPOINT=https://prometheus.log10x.com/ \
  TENX_AIRGAPPED=true \
  tenx run @run/input/forwarder/fluentbit @apps/receiver

The Receiver takes its input from a forwarder module, which is why each run names one. To watch the engine's own two calls without the per-pattern stream, run @apps/dev instead, whose config leaves the log10x metric output commented out.

Confirming a pulled image carries no license is the other check worth running:

docker pull ghcr.io/log-10x/fluent-bit-10x:<tag>
docker inspect ghcr.io/log-10x/fluent-bit-10x:<tag> \
  --format '{{range .Config.Env}}{{println .}}{{end}}' | grep TENX_LICENSE_KEY

Running the engine in a container started with --network none is the stronger version of the first test: the pipeline completes, because no product function depends on a log10x endpoint.

For what is inside the artifact you just tested, every release ships a CycloneDX SBOM naming each component.