> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Compatibility and support
> 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 and tested, and it is **not yet an integrated part of
the product**: there is no dashboard page for it, no in-product installer and
no self-service download. Ask your account contact for access.
Its telemetry, once flowing, is ordinary OTLP and needs nothing special —
it appears in Services, Traces and Metrics exactly like SDK telemetry does.
That is the design rather than a shortcut.
## What the support levels mean
| Level | Meaning |
| :-------------- | :-------------------------------------------------------------------------------------------------------------------- |
| **Supported** | 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.
## Requirements at a glance
| | |
| :--------------------------- | :----------------------------------------------------- |
| Operating system | **Linux only** |
| Kernel | **5.8+**, or RHEL-family **4.18+** with eBPF backports |
| Kernel validated on | 6.8 |
| Architecture | `amd64`, `arm64` |
| Kernel type information | `/sys/kernel/btf/vmlinux` must exist |
| `kernel.perf_event_paranoid` | **1 or lower** for profiles B and C |
| Kubernetes | 1.19+ (validated 1.30) |
| Docker | 20.10+ (validated 28.2) |
| Docker Compose | 2.0+ (validated 2.36.2) |
| Helm | 3.8+ (validated 3.15.2) |
Check any host, without installing anything:
```bash theme={null}
./bin/oiq-zerocode-preflight
```
## Kernel
| Kernel | Applies to | Level | Notes |
| :----- | :--------------- | :-------------- | :-------------------------------------------------------------------------------------------- |
| 4.14 | any | **Unsupported** | Below the eBPF feature floor. No kernel type information, no CO-RE. |
| 4.18 | RHEL-family only | **Supported** | RHEL, CentOS, Rocky and Alma 8 backport the required features. Non-RHEL 4.18 is unsupported. |
| 5.4 | any | **Unsupported** | Predates the 5.8 floor. Ubuntu 20.04 GA ships this — use the 5.15 hardware-enablement kernel. |
| 5.8 | any | **Supported** | The documented minimum. |
| 5.10 | any | Expected | Debian 11, newer Amazon Linux 2 stream. Verify kernel type information is present. |
| 5.14 | any | Expected | RHEL 9, SUSE 15.4+. |
| 5.15 | any | Expected | Ubuntu 22.04 GA. |
| 6.1 | any | Expected | Debian 12, Amazon Linux 2023. |
| 6.8 | any | **Supported** | Validated: Ubuntu 22.04 hardware-enablement kernel. |
**`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.
```bash theme={null}
sudo sysctl -w kernel.perf_event_paranoid=1
echo 'kernel.perf_event_paranoid=1' | sudo tee /etc/sysctl.d/99-aiaxoniq.conf
```
Preflight treats this as blocking rather than as a warning.
## Linux distributions
| Distribution | Kernel | Level | Notes |
| :------------------------- | :---------------- | :-------------- | :------------------------------------------------------------------------------------------------------------ |
| Ubuntu 20.04 LTS | 5.4 GA / 5.15 HWE | **Limited** | The GA kernel is below the floor. Install the hardware-enablement kernel. |
| Ubuntu 22.04 LTS | 5.15 / 6.8 | **Supported** | Validated on 6.8. Kernel type information enabled by default. |
| Ubuntu 24.04 LTS | 6.8 | Expected | Same kernel series as the validated host. |
| Debian 11 | 5.10 | Expected | Meets the floor. Confirm kernel type information is present. |
| Debian 12 | 6.1 | Expected | Enabled by default. |
| RHEL / Rocky / Alma 8 | 4.18 | Expected | The documented RHEL-family exception. |
| RHEL / Rocky / Alma 9 | 5.14 | Expected | — |
| Amazon Linux 2 | 4.14 default | **Unsupported** | Default kernel is below the floor. The 5.10 stream is expected to work. |
| Amazon Linux 2023 | 6.1 | Expected | — |
| SUSE / openSUSE 15.4+ | 5.14 | Expected | — |
| Fedora 38+ | 6.2+ | Expected | — |
| Alpine (musl) | host kernel | **Limited** | The kernel belongs to the host, so the floor applies there. musl symbol resolution for uprobes is unverified. |
| Flatcar, Bottlerocket | 5.15+ | Expected | Purpose-built container hosts. |
| GKE Container-Optimized OS | 5.15+ | Expected | Kernel type information present. |
| Talos Linux | 6.x | Expected | API-driven config; capability grants may need a machine-config change. |
| Windows Server | — | **Unsupported** | eBPF is a Linux kernel facility. Use the OpenTelemetry SDK. |
| macOS | — | **Unsupported** | Same. Use the SDK, or a Linux VM for evaluation only. |
## Kubernetes
| Platform | Level | Notes |
| :-------------------------------------- | :-------------- | :------------------------------------------------------------------------------------- |
| k3s / k3d | **Supported** | Validated: full install, rollout and teardown. |
| kind | Expected | Depends on the host kernel, like any container runtime. |
| minikube (docker driver) | Expected | Same — the kernel belongs to the host. |
| kubeadm / self-managed | Expected | Depends on node OS. |
| EKS (EC2 nodes) | Expected | **Set `kernel.perf_event_paranoid=1` on nodes**, or `CAP_SYS_ADMIN` becomes necessary. |
| GKE Standard | Expected | Both common node images carry kernel type information. |
| AKS | Expected | Same perf-event caveat as EKS. |
| OpenShift 4.x | Expected | Requires the shipped constraints — see [OpenShift](/zero-code/openshift). |
| Rancher / RKE2 | Expected | — |
| DigitalOcean / Linode / Hetzner managed | Expected | Standard node access. |
| EKS Fargate | **Unsupported** | No node access, no privileged pods, no DaemonSet. |
| GKE Autopilot | **Unsupported** | 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](/send-data/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](/zero-code/profiles).
## Container runtimes
| Runtime | Level | Notes |
| :------------------------------- | :-------------- | :--------------------------------------------------------------------------- |
| Docker Engine 20.10+ | **Supported** | 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.
## Language runtimes
Instrumented language-agnostically, at the socket and TLS boundary:
| Runtime | Depth |
| :----------------------------------------- | :------------------------------------------------------------------------------------------- |
| **Go** | Deepest. Server and client spans, and the only path to full eBPF-driven context propagation. |
| Java (JDK 8+), .NET, Node.js, Python, Ruby | Protocol-level spans and RED metrics at the socket/TLS boundary. |
| C, C++, Rust | The same, depending on the TLS library in use. |
## Protocols
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](/zero-code/troubleshooting#only-some-services-appear).
## Never supported
| | Why |
| :------------------------------------------------------------------------- | :---------------------------------------------------------------------------- |
| Windows, macOS | eBPF is a Linux kernel facility. |
| Serverless — Fargate, Autopilot, Cloud Run, container instances, functions | No node, no kernel access, no DaemonSet. |
| gVisor, Firecracker, Kata | Syscalls are intercepted, or the guest has its own kernel. |
| Rootless Podman | Cannot grant the required capabilities. |
| In-process detail — custom spans, business attributes, stack traces | eBPF observes the boundary, not your logic. Use the SDK where you need depth. |
## Next
What is absent by design.
Choosing a privilege level.
The questions an evaluation actually asks.