Which kernels, distributions, clouds, container runtimes and language runtimes the zero-code agent supports — stated as validated, expected, limited or unsupported.
Whether the agent runs on a given host is decided by the kernel, not by the
language or base image of the workload. This page is the full matrix — and it
distinguishes what was actually run from what merely ought to work.
Availability. The zero-code agent is an early-access distribution. It is
installable, upgradable, tested and visible in the product, and it is not
yet self-service: there is no in-product installer and no download. Ask your
account contact for the distribution.Once it is running, find it under Zero-code in the dashboard — the hosts
reporting, the services each discovered, the agent version on every node, and
how recently each was last heard from. Its telemetry is ordinary OTLP and
needs nothing special: it also appears in Services, Traces and Metrics exactly
like SDK telemetry. That is the design rather than a shortcut.
Validated by us, or a direct consequence of a validated case. A bug report against it will be investigated.
Expected
Meets every documented requirement with no known obstacle, but we have not run it. Report problems; we will look.
Limited
Works with a caveat that materially changes the experience. The caveat is always stated.
Unsupported
Known not to work. The reason is always stated.
The distinction between supported and expected is deliberate. Marking
a platform “supported” because it ought to work is how a support team ends up
defending a claim engineering never made. Only rows that were actually run
are supported.
perf_event_paranoid is the trap. Above 1 the kernel denies perf-event
access even with CAP_PERFMON granted. Profiles B and C attach kprobes, so
the agent starts, holds every capability, passes its own checks — and
collects nothing, silently.
sudo sysctl -w kernel.perf_event_paranoid=1echo 'kernel.perf_event_paranoid=1' | sudo tee /etc/sysctl.d/99-aiaxoniq.conf
Preflight treats this as blocking rather than as a warning.
Restricts host PID and the required capability set.
AKS Virtual Nodes
Unsupported
No node.
Cloud Run / App Runner / Container Apps
Unsupported
Serverless; no kernel to instrument.
The rule: if you control the node, the agent works. If you do not —
Fargate, Autopilot, Cloud Run, container instances — use the OpenTelemetry
SDK or a sidecar Collector. See
Installation overview.
Profile A is not available on Kubernetes at all: the upstream chart
hardcodes a six-capability floor for unprivileged mode, so a three-capability
profile cannot be expressed. The chart refuses it by name rather than silently
widening the grant. See Capability profiles.
Validated on 28.2. Needs --pid=host and the profile capabilities.
Docker Compose v2
Supported
Validated on 2.36.2.
Docker Desktop (macOS / Windows)
Limited
Runs inside the Linux VM and observes only what runs there. Evaluation only.
Podman, rootful
Expected
Equivalent to Docker for this purpose.
Podman, rootless
Unsupported
Cannot grant the required capabilities.
containerd / CRI-O
Supported
The Kubernetes path.
LXC / LXD, privileged
Expected
Unverified.
gVisor
Unsupported
Intercepts syscalls in userspace; host eBPF sees nothing inside.
Firecracker / Kata
Unsupported
Each guest has its own kernel.
AWS ECS on EC2
Expected
Daemon-scheduled task with the capability set.
AWS ECS on Fargate
Unsupported
No host access.
The kernel belongs to the host, so a container has none of its own and
your workload’s base image is irrelevant. Observing processes in other
containers additionally needs host PID access.
HTTP/S, HTTP/2, gRPC, gRPC-Web, JSON-RPC, MQTT, NATS, AMQP 1.0; PostgreSQL,
MySQL, SQL Server, MongoDB, Redis, Couchbase; Kafka; GraphQL;
Elasticsearch/OpenSearch; S3; and GenAI APIs including OpenAI, Anthropic,
Gemini and Bedrock.
TLS coverage depends on the library, and the full matrix is unmeasured.The agent hooks OpenSSL. Statically linked TLS, BoringSSL, rustls, GnuTLS
and NSS are each a potential gap. Node.js bundles its own OpenSSL and
Rust’s rustls is not OpenSSL — both are known risks rather than known
failures.This presents as “that service is missing”, never as an error. If a service
you expected is absent, this is the first thing to suspect. See
Only some services appear.
