Files
firezone/docs/AGENT.md
Thomas Eizinger e0ee94f60e chore: add basic context about Firezone for AI agents (#10284)
When using an AI-enabled editor (like Zed), it is useful to have a
"rules" file to give it basic context about the project so we don't have
to re-explain it every time.

We can also extend this file with a list of code review instructions /
coding guidelines for Copilot. See
https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions#asking-copilot-coding-agent-to-generate-a-githubcopilot-instructionsmd-file.

I expect this file to grow as we learn which info the agents need about
the product to be helpful. In order to use it, people are encouraged to
create locally-ignored symlinks to the `docs/AGENT.md` file.

---------

Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2025-09-10 03:30:23 +00:00

1.6 KiB

AI agent rules for Firezone

Summary

Firezone is a zero-trust access platform built on top of WireGuard. The data plane components are built in Rust and reside in rust/. The control plane components are built in Elixir and reside in elixir/.

Data plane architecture

At the core of the data plane resides a shared library called connlib. It combines ICE (using the str0m library) and WireGuard (using the boringtun library) to establish on-the-fly tunnels between Clients and Gateways. The entry-point for the data plane is Tunnel which acts as a big event-loop combining three components:

  • A platform-specific TUN device
  • A sans-IO state component representing either the Client or the Gateway
  • A platform-specific UDP socket

Packets from IO sources (TUN device and UDP socket) are passed to the state component, resulting in a UDP or IP packet. The state component also manages ICE through the snownet library, so some UDP traffic is handled internally and does not yield an IP packet.

These three components are split into multiple threads and connected via bounded channels:

  • 1 thread for reading from the TUN device
  • 1 thread for writing to the TUN device
  • 1 thread for handling IPv4 UDP traffic with 1 task each for sending / receiving
  • 1 thread for handling IPv6 UDP traffic with 1 task each for sending / receiving
  • 1 task on the "main" thread that holds the state and reads / writes from and to the channels connecting to the IO threads

Code review guidelines

  • Assume that code compiles and is syntactically correct.
  • Focus on consistency and correctness.