Tunnels
R3VERB tunnels give your local apps secure, auditable access to services that usually live behind VPNs, private networks, or Kubernetes clusters.
How tunnels work
The CLI establishes an outbound, TLS-encrypted connection to the R3VERB control plane. Incoming requests hit a public URL and are forwarded back to your local server over that connection.
Basic usage
Forward traffic from a public URL to a local port:
r3v tunnel api:3000
Kubernetes & clusters
In cluster mode, the R3VERB agent runs inside your Kubernetes cluster and manages tunnels automatically from annotations. Use the dashboard to see which services are exposed and to copy shareable URLs.
Cluster agents & keys
Each customer can have multiple clusters in R3VERB. For each cluster you deploy exactly one cluster agent, which authenticates back to the control plane using a cluster-scoped token.
- One R3VERB cluster agent per cluster.
- Each agent is bound to a specific organization and cluster.
- All tunnel and capture data stays scoped to that org+cluster.
There are two ways to provision a token for the agent:
- Use the dashboard to generate a cluster token for the cluster and configure your agent to send it as Authorization: Bearer <token>.
- In single-tenant setups, configure a fast-path env key on the control plane using:R3V_CLUSTER_AGENT_KEY
R3V_CLUSTER_AGENT_ORG_ID
R3V_CLUSTER_AGENT_CLUSTER_IDWhen the agent sends a matching bearer token, the control plane treats it as a cluster-scoped token for that org+cluster without needing a database-backed key.
The env-based key is intended for single-tenant or bootstrap scenarios (for one org+cluster per control-plane deployment). For additional clusters, use regular cluster tokens via the dashboard.