Skip to main content

Byte-level forwarding & privacy

raba's server never parses the content of what you tunnel. This isn't a policy decision layered on top of a request-inspecting proxy — it's a structural property of how the whole system is built.

What "byte-level forwarding" actually means​

For HTTP specifically, the server reads just enough of the very first request on a connection to find the Host header (needed to know which project to route to) — that's it. Everything else, for every protocol, is forwarded as opaque bytes: request bodies, response bodies, headers beyond Host, the entire TCP/UDP payload for non-HTTP projects. The server has no code path that deserializes, inspects, or transforms the content you're tunneling — there's nothing to turn on or off, because the capability to look inside your traffic was never built.

This is also why HTTP, TCP, and UDP share almost identical internal plumbing (see HTTP, TCP, and UDP tunneling) — a server that genuinely doesn't care what's inside the bytes it's forwarding doesn't need protocol-specific parsing logic to begin with.

What raba does log​

Connection metadata — not content. Per completed connection: byte counts in/out, protocol, connection duration, and for HTTP, the method and path of the first request only (already "free" to capture, since the server already parses that far to find Host — no additional parsing is added just to log it). A keep-alive HTTP connection carrying several pipelined requests still produces exactly one log row for the whole connection, matching the byte-level design: the server never parses far enough into the stream to distinguish individual pipelined requests from each other.

Never logged: request or response body content, for any protocol.

Credentials are compartmentalized, not shared​

raba uses three separate credential types, each scoped to one job, and none of them can substitute for another:

  • JWT session cookie — browser-bound, short-lived, for the dashboard only.
  • Personal Access Token (PAT) — long-lived, revocable, for CLI-driven management actions (creating projects, reading stats). A PAT can never be used to authenticate a tunnel connection.
  • Project secret — opaque, long-lived, used only by the headless Client to authenticate its tunnel handshake. A project secret can never be used to call the management API.

All three are CSPRNG-generated and stored only as a hash (never plaintext) — each is shown to you exactly once, at creation time.