gobee: Write BPF Programs in Go

eBPF is one of the most useful building blocks for modern Linux observability, security, and traffic control. It is also a sharp tool. Teams often write userspace collectors in Go, then switch to C for the kernel-side program and glue the two halves together with generated bindings.
gobee takes a different path. It transpiles a strict subset of Go into BPF C, generates typed Go bindings on top of cilium/ebpf, and keeps clang in the loop for mature BPF code generation.
What Is gobee?
gobee is a Go-to-BPF workflow for teams that already live in Go. You write kernel-side BPF logic in a constrained Go syntax, mark sections with //bpf:* directives, and run gobee translate. The tool emits readable .bpf.c output, a sourcemap, and a typed Go bindings file.
The project is not trying to hide BPF. The generated C stays visible, clang still compiles the object, and the BPF model remains user-owned.
Key Features
- Typed userspace bindings: call generated loaders, attach helpers, and map accessors instead of string-based collection lookups.
- Go source diagnostics: verifier errors can point back to the original Go file, line, and column.
- Kernel-version gating:
bpfvetruns during load so unsupported hosts fail fast with a clearer message. - Broad BPF surface: current support covers XDP, tracepoints, kprobes, TC, cgroup_skb, LSM, 19 map types, and about 200 typed helper stubs.
- CO-RE through clang: gobee emits C that uses
vmlinux.handBPF_CORE_READ, then relies on clang for BTF and relocations.
Installation
The basic install is a normal Go tool install:
go install github.com/boratanrikulu/gobee/cmd/gobee@latest
You still need clang with BPF target support to compile the generated C into a .bpf.o artifact. On Linux, use your distro package. On macOS, the project recommends installing LLVM through Homebrew or compiling inside a Linux VM.
Quick Workflow
A typical project keeps BPF source under a separate bpf/src directory and generated bindings in an importable Go package:
gobee translate --bindings-dir ./bpf ./bpf/src
make build
sudo ./your-program eth0
That flow is useful for SRE tools that need packet counters, syscall event streams, process telemetry, or custom diagnostics. The kernel program and userspace loader can remain inside one Go module.
Operational Tips
Treat gobee as an ergonomics layer, not an abstraction that removes BPF risk. Review the generated C during code review. Test on the oldest kernel you support. Keep verifier failures visible in CI, and run real-kernel checks for examples that touch maps, tracepoints, and packet paths.
For production agents, also document required capabilities, kernel config assumptions, and fallback behavior when BPF loading fails. A clean error is much better than a silent observability gap.
Conclusion
gobee is worth watching because it meets Go-based infrastructure teams where they already work. It does not replace C, clang, or BPF knowledge, but it can make custom Linux instrumentation easier to build and easier to review.
If you are building operational automation around Linux telemetry, Akmatori helps SRE teams turn signals into guided investigation and remediation workflows. Akmatori runs on Gcore, giving teams a fast global foundation for production infrastructure.
