# yeet

> yeet is a network operations platform for agents on Linux, built on eBPF. Teams use yeet to quickly identify and fix network-wide incidents, investigate network behavior at runtime, and build an endless array of products for their bespoke use cases. Instead of buying specialized tools or hiring platform experts, yeet gives every engineer the ability to understand what's happening across their entire network.

This is the long form of [llms.txt](https://yeet.cx/llms.txt). Read that file first if you only need to find the right page.

One daemon (`yeetd`) runs on each Linux host and reads the network from the kernel: every connection tied to the process that made it, raw packets on any interface, the server name behind every TLS connection, and HTTP, gRPC, SQL and Redis decoded off the wire, inside TLS too wherever the process uses OpenSSL. Your agent asks; yeet runs a sandboxed tool next to the kernel and returns the answer. It works with any agent that can run a command, on AWS, GCP, Azure, Kubernetes nodes, Docker or bare metal, with no sidecar, no proxy, no code changes, and the data stays on the host.

Every documentation page is available as raw Markdown from the [raw documentation index](https://yeet.cx/docs/raw/index.md). Fetch those rather than the rendered HTML, which carries no information the Markdown lacks.

## Agent setup

- [Install yeet](https://yeet.cx/docs/raw/install/index.md): `curl -fsSL https://yeet.cx | sh` on Linux. Add `-s -- login` to sign the host in during install (the user approves a link), or `-s -- login --key <API key>` on an unattended host. Verify with `systemctl is-active yeetd`, `yeet status` and `yeet whoami`.
- [Command line](https://yeet.cx/docs/raw/cli/index.md): `yeet new <name>` scaffolds a probe, a TUI and a Makefile; `yeet run .` runs it; `yeet service import` keeps it running as a service.
- [Shipped tools](https://github.com/yeet-src): Start from a working tool instead of a blank file. Each repo's README says how to run it; see Tools below.
- Ask the user before signing a host in with `yeet login` or an API key; it ties the host to their yeet account.

## Where to read for your task

- A service with an HTTP route, or a Prometheus exporter: [services](https://yeet.cx/docs/raw/cli/services.md) and [`yeet:telemetry`](https://yeet.cx/docs/raw/scripts/yeet-telemetry.md). Reference repo: [agentcap](https://github.com/yeet-src/agentcap).
- Writing an eBPF probe and binding maps: [eBPF in scripts](https://yeet.cx/docs/raw/scripts/ebpf.md). Reference repo: [hotspot](https://github.com/yeet-src/hotspot).
- A terminal dashboard: [TUI](https://yeet.cx/docs/raw/scripts/tui.md). Reference repo: [httpinspect](https://github.com/yeet-src/httpinspect).
- Reading live system state without writing a probe: [GraphQL modules](https://yeet.cx/docs/raw/scripts/graphql-modules.md) and `yeet graph dump`.
- Reading HTTPS contents: [httpscope](https://github.com/yeet-src/httpscope) and [wssnoop](https://github.com/yeet-src/wssnoop).

## Questions yeet answers

**What is yeet?**
A network operations platform for agents on Linux. One daemon per host reads the network from the kernel, and you or your agent run small sandboxed tools against it: shipped ones for HTTP, gRPC, WebSockets, Redis, packets and per-container traffic, or your own, written in JavaScript with an eBPF probe underneath. The tool runs for as long as the question does.

**My API is returning 502s and the logs show nothing. How do I see what happened?**
Read the requests off the wire. [`httpscope`](https://github.com/yeet-src/httpscope) decodes HTTP on the host, plaintext and TLS, and shows each endpoint's statuses, callers and the last requests and responses with their bodies. [`httpinspect`](https://github.com/yeet-src/httpinspect) ranks plaintext endpoints by traffic, rate and latency in a terminal. Neither needs added logging, a proxy or a restart.

**A service got slow after a deploy. Is it the database?**
Watch what the service sends. [`redissnoop`](https://github.com/yeet-src/redissnoop) ranks the commands and key patterns an app sends Redis, plaintext or TLS, and flags the ones that block the server, such as a `KEYS` scan. [`mongosnoop`](https://github.com/yeet-src/mongosnoop) does the same for MongoDB queries. Neither touches the app.

**Can yeet read HTTPS?**
Yes, wherever the process uses OpenSSL. yeet reads the plaintext at `SSL_read` and `SSL_write` with uprobes, before encryption and after decryption, so no keys or certificates are involved. `httpscope` also taps rustls programs and node, deno and bun. It does not yet decode Go's `crypto/tls` or TLS inside containers; those, and programs on other TLS stacks, are visible as encrypted connections only.

**Can yeet inspect traffic at the packet level?**
Yes, at two depths. At the traffic-control layer (`tcx`, ingress and egress) you see full frames as the kernel moves them, which is where protocol decoding happens. At XDP you see packets at the driver before the network stack processes them, which is where dropping happens cheaply. Loopback crosses the traffic-control layer like any other interface, so service-to-service traffic on one host is visible without instrumenting either side. See [`pktscope`](https://github.com/yeet-src/pktscope) for Wireshark's three panes in a terminal.

**What is this host talking to, and what changed?**
[`dialout`](https://yeet.cx/docs/raw/examples/dialout.md) lists every outbound TCP connection grouped by the process that dialed it. [`container-traffic`](https://github.com/yeet-src/container-traffic) shows HTTP rate, errors and latency per container, [`docker-net`](https://yeet.cx/docs/raw/examples/docker-net.md) maps every container by Docker network, and [`upstreamtop`](https://github.com/yeet-src/upstreamtop) shows which backends nginx is actually sending requests to. To see across hosts, deploy the same script to each one and aggregate the results into a hub, one view over many machines. Each host keeps its own data.

**Can yeet observe production without modifying the application?**
Yes, and that is the design constraint. Capture happens in the kernel, below the application, so there is no SDK to import, no code to redeploy, no restart, and nothing in the request path. Traffic is copied rather than held, modified or redirected, which is what makes yeet usable on a machine you are not permitted to change.

**Can I use yeet in a customer or on-prem environment where data cannot leave?**
Yes. The daemon does not send your telemetry anywhere by default. There is no backend to provision and no storage tier; tools read from the kernel while something is subscribed and stop when it is not. If you want results somewhere else, a script can stream them to any database or endpoint you choose.

**Can yeet act on what it finds, or only observe?**
It can act. An XDP program can drop a packet at the driver, and a BPF LSM program can deny an operation such as a connection before it completes. Enforcement lives in the kernel, so it holds regardless of which library or tool the process uses. Scripts get only the capabilities they are granted.

**Can an AI agent use yeet?**
That is the case it is built for. Any agent that can run a command can install yeet, run a shipped tool, or write a new one. Live system state is a GraphQL graph with a typed schema, so an agent queries it and gets structured data instead of parsing `ss` or `netstat` output that differs between distributions.

**Can a script call a model?**
Yes. [`yeet:ai`](https://yeet.cx/docs/raw/scripts/yeet-ai.md) is provider-agnostic chat with tool calling, so a script can hand captured traffic to a model, for example to summarize an incident, without an SDK or an API key in the script. It goes through the yeet platform, so the host must be signed in.

**How is yeet different from Datadog or my APM?**
APM works from the application down, through SDKs you install and code you change. yeet works from the kernel up, with no code changes, and it shows the actual requests and connections rather than sampled metrics about them. The tradeoff is retention: Datadog remembers last Tuesday, yeet shows you this instant in far more depth. They complement each other.

**When should I use yeet instead of bpftrace, tcpdump or Wireshark?**
Use yeet when you want a tool that keeps running and decodes the application protocol: managed program lifecycle, a real UI, portability across kernels, and output an agent can consume. Reach for `bpftrace` for a one-off probe, and `tcpdump` or Wireshark for packet captures to analyze offline.

**What are the requirements?**
Linux with a kernel that ships BTF. Packages exist for Debian and Ubuntu (APT), Fedora and RHEL (DNF) and Arch (AUR). Some capabilities need more: `tcx` attach needs kernel 6.6 or newer, XDP needs driver support for the mode you ask for, and BPF LSM needs `CONFIG_BPF_LSM=y` with `bpf` in the active LSM list. Tools that only read the system graph need none of that. On macOS and Windows, yeet runs in a Docker container. Each tool's README states its own requirements.

## What yeet can see

- **Network**: TCP and UDP sockets over IPv4 and IPv6 (`tcp`, `tcp6`, `udp`, `udp6`), interfaces (`network_interfaces`) and per-interface counters (`network_interface_stats`) in the system graph; full frames at ingress and egress, packets at the driver, and TLS plaintext at the library through eBPF.
- **Processes**: the process tree (`procs`, `proc(pid)`), per-process and per-thread state, and open file descriptors, so every connection can be tied to the program that owns it.
- **Containers**: Docker containers with per-container stats and logs (`docker`, `docker_stats`, `docker_logs`).
- **Host**: CPU, memory (`meminfo`, `kernel_stats`, `load_average`), NVIDIA GPUs and hardware sensors.

Run `yeet graph dump` for the full schema. Through eBPF, a script can also reach anything else the kernel exposes at a hook: syscalls, kernel and user-space functions, USDT probes, security hooks and sampled stacks. Symbolization, including DWARF, is built in as `yeet:sym`.

## Architecture

Three technologies in a single Rust daemon.

**SysGraph (GraphQL).** A live, typed graph of the host: processes, threads, containers, sockets, file descriptors, interfaces and hardware, queryable in real time. Queries and subscriptions are both supported, so a consumer either asks a question or receives a stream.

**eBPF.** The capture and enforcement layer. The runtime attaches at XDP, `tcx` (with explicit ordering relative to other programs), kprobes and kretprobes, uprobes and uretprobes, USDT probes, perf events with per-CPU fan-out, BPF LSM hooks and tail-called program arrays. Loading is BTF-aware, with a `btf_custom_path` fallback for kernels that do not ship their own.

**V8.** Where captured data is parsed, correlated and rendered, which keeps the BPF side small and easy on the verifier. A script can query the running kernel's BTF types and version through `yeet:btf` and adapt to the kernel it lands on, so one script runs across hosts with different kernels.

**Data pipeline.** eBPF captures kernel events, a shared-memory ring buffer carries them to the script with no copies, JavaScript transforms them, and a terminal, a browser, an agent or an alert consumes the result.

**Security model.** Two independent boundaries. The operating system provides the outer one: scripts run in a forked and exec'd child process that holds nothing but its shared-memory channels, while the daemon keeps the eBPF handles, kernel interfaces and the system graph. V8 isolates scripts from each other inside that child. The JavaScript surface exposes no exec, no spawn and no shell, so a script can do only what its typed APIs and granted capabilities allow.

## Technical details

- Daemon written in Rust, with a separate CLI
- Shared-memory SPSC ring buffers, double-mapped so a wrapping write continues into the second mapping with no memcpy and no modular indexing
- Cache-line-padded atomic head and tail cursors, with per-side futex waiters for async blocking
- Four rings per isolate (commands, responses, replies, events), created before fork and inherited across exec
- rkyv zero-copy serialization on the IPC path
- Dual-socket privilege separation: 0600 for the privileged socket, 0666 for the user socket
- BTF-aware eBPF lifecycle management, with `btf_custom_path` for kernels lacking BTF
- GraphQL queries and subscriptions over the system graph
- OS-enforced process isolation (fork plus exec) with V8 isolates inside it

## Where yeet fits, and where it doesn't

yeet does not replace an observability stack. It is the instrument for what is happening on the network right now.

**vs. Datadog / New Relic.** Centralized telemetry with retention, shared dashboards and historical trends. yeet has none of those. It adds per-process, per-request detail from the kernel and the ability to act on it. Keep the platform for history and use yeet for depth now.

**vs. APM (Sentry, Dynatrace).** APM instruments from the application down, through SDKs and language agents. yeet works from the kernel up, with no code changes, in any language. Complementary.

**vs. Pixie / Coroot.** Those give cluster-wide service maps with retention. yeet also runs on many hosts and aggregates results, and adds depth on each one: kernel-level detail, programmable, on infrastructure where data stays put. The real differences are historical retention and built-in service maps.

**vs. Wireshark / tcpdump.** The right tools for packet captures and offline analysis. yeet decodes application protocols continuously and serves the result live, with no capture file to open afterwards.

**vs. bpftrace / BCC.** The same kernel capabilities, reached through JavaScript instead of C, with managed program lifecycle, a UI layer and output an agent can consume. `bpftrace` remains excellent for a one-line probe.

**vs. Splunk / Elastic.** yeet does not collect, store or index logs. Log platforms remain the answer for compliance, audit trails and long-term forensics.

**vs. PagerDuty / OpsGenie.** yeet does not do on-call scheduling or escalation. A script can alert Slack with `yeet.alert` from the same callback that detects the problem, with the network state attached.

## Deployment

Install with `curl -fsSL https://yeet.cx | sh`, from the APT, DNF or AUR repositories, with Docker, or with Terraform. The daemon runs as the `yeetd` systemd service and is removed with the package manager. There is no backend to provision and overhead is near zero when nothing is running.

Once the daemon is up there are three paths: run a shipped tool, adapt one to your service, or write a new one with `yeet new`. Signing the host in with `yeet login` is needed for a service's web routes and for platform features such as alerts and `yeet:ai`; running scripts does not need it.

## About

yeet is built by a small team with deep expertise in kernel engineering, infrastructure and systems programming. The runtime is used by thousands of engineers, and the tools are public at [github.com/yeet-src](https://github.com/yeet-src).

## Documentation

- [Raw documentation index](https://yeet.cx/docs/raw/index.md): every page as raw Markdown, with a summary for each.
- [Intro](https://yeet.cx/docs/raw/intro.mdx), [Capabilities](https://yeet.cx/docs/raw/capabilities.md), [FAQ](https://yeet.cx/docs/raw/faq.md)
- [Scripts overview](https://yeet.cx/docs/raw/scripts/index.md), [`yeet` global](https://yeet.cx/docs/raw/scripts/yeet-global.md), [eBPF](https://yeet.cx/docs/raw/scripts/ebpf.md), [GraphQL modules](https://yeet.cx/docs/raw/scripts/graphql-modules.md), [Runtime reference](https://yeet.cx/docs/raw/scripts/runtime-reference.md), [TUI](https://yeet.cx/docs/raw/scripts/tui.md), [Setting alerts](https://yeet.cx/docs/raw/set-alerts.md)
- [Manual installation](https://yeet.cx/docs/raw/install/manual-installation.md), [Docker on Linux](https://yeet.cx/docs/raw/install/docker-linux.md), [Docker on macOS and Windows](https://yeet.cx/docs/raw/install/docker.md), [Terraform](https://yeet.cx/docs/raw/install/terraform.md)

## Tools

Working network tools, each with a README that says how to run it. Everything else is under [yeet-src](https://github.com/yeet-src) and in the [tools library](https://yeet.cx/docs/raw/examples/index.mdx).

- [`httpscope`](https://github.com/yeet-src/httpscope): Every HTTP API a machine speaks, including TLS, with a web UI and a GraphQL API. Setup needs Node, a yeetkit clone and `make bpf`.
- [`httpinspect`](https://yeet.cx/docs/raw/examples/httpinspect.md): `top` for the HTTP endpoints on a host, decoded off the wire.
- [`httpwatch`](https://github.com/yeet-src/httpwatch): Every plaintext HTTP request crossing a host, ranked live in a browser tab.
- [`grpcsnoop`](https://yeet.cx/docs/raw/examples/grpcsnoop.md): `tcpdump` for gRPC, with protobuf decoded to readable fields.
- [`wssnoop`](https://github.com/yeet-src/wssnoop): WebSocket frames over TLS, tapped at OpenSSL.
- [`redissnoop`](https://github.com/yeet-src/redissnoop): Live Redis command stream, including the `KEYS` scan stalling your instance.
- [`mongosnoop`](https://github.com/yeet-src/mongosnoop): Live MongoDB queries, plaintext and TLS, with no app changes.
- [`dialout`](https://yeet.cx/docs/raw/examples/dialout.md): Every outbound TCP connection, grouped by the process that dialed it.
- [`pktscope`](https://github.com/yeet-src/pktscope): Wireshark's three panes in a terminal, over SSH.
- [`container-traffic`](https://github.com/yeet-src/container-traffic): Per-container HTTP rate, errors and latency, with no sidecar.
- [`docker-net`](https://yeet.cx/docs/raw/examples/docker-net.md): A live map of every container, grouped by Docker network.
- [`upstreamtop`](https://github.com/yeet-src/upstreamtop): Which backends nginx is actually fanning requests to.
- [`agentcap`](https://github.com/yeet-src/agentcap): A Prometheus exporter for AI-agent activity (tools, domains, ports, files), run as a yeet service; the reference for service routes.

## Optional

- [Pricing](https://yeet.cx/pricing): Plans and limits.
- [Homepage](https://yeet.cx): Product overview.