Skip to main content
Local development is comfortable right up until something outside your machine needs to hit your agent. A webhook provider, a teammate, or a quick external test all run into the same wall: localhost does not exist anywhere except your own machine.

​
Why Tunneling Matters

Bindu provides built-in tunneling so you can expose a local agent to the internet during development and testing without deploying it to a server first. That makes it easier to share a work-in-progress agent or test webhook flows while keeping the code and runtime local.
Local-only developmentDevelopment with tunneling
Agent is reachable only on localhostAgent gets a public internet URL
Webhook testing is awkward or impossibleExternal services can call into your local agent
Sharing requires a deployment stepOthers can access the tunneled URL directly
Iteration stays trapped in one machineDevelopment stays local while access becomes public
Production setup is overkill for quick feedbackPublic access is available for testing and demos
That is the shift: tunneling keeps the agent on your machine, but removes the localhost barrier when you need public reachability.
Tunneling is for local development and testing only. Do not use it in production. For production deployments, use proper hosting with SSL certificates and security configurations.

​
How Bindu Tunneling Works

Bindu uses FRP (Fast Reverse Proxy) tunneling to create a secure connection between your local agent and a public URL.
Behind the scenes: the first time you enable tunneling, Bindu automatically downloads the official frpc (FRP client) binary to ~/.bindu/frpc/. If your OS or firewall prompts you about a new executable making outbound network connections, this is expected behavior.

​
The Public Address Model

Tunneling starts by enabling launch=True in bindufy(): 
from bindu import bindufy

config = {
    "author": "your.email@example.com",
    "name": "my_agent",
    "description": "My development agent",
    "deployment": {"url": "http://localhost:3773", "expose": True},
    "skills": ["skills/question-answering"],
}

async def handler(message):
    return {"role": "assistant", "content": "Hello!"}

# Enable tunneling for local development
bindufy(config, handler, launch=True)
When the agent starts, you will see output like this: 
✅ Tunnel established: https://abc123xyz.tunnel.getbindu.com
🌐 Public URL: https://abc123xyz.tunnel.getbindu.com
The public URL is temporary and maps back to your local agent.

Local First

Your agent still runs locally on localhost:3773.

Public URL

FRP assigns a random 12-character public subdomain such as abc123xyz.tunnel.getbindu.com.

Development Only

This is meant for testing and demos, not for production traffic.

​
The Lifecycle: Start, Tunnel, Forward

Under the hood, tunneling moves through three practical stages.
1

Start

Your local agent starts on localhost:3773 with launch=True enabled in bindufy().That is the only change in the local setup. The rest of the agent continues to run as usual on your machine.
2

Tunnel

The FRP client connects to Bindu’s tunnel server and creates a tunnel for the local agent.At that point, a public URL is generated with a random subdomain, for example:
abc123xyz.tunnel.getbindu.com
3

Forward

Requests sent to the public URL are forwarded to the local agent and the response goes back through the same path.
  1. Local Agent Starts — your agent runs on localhost:3773
  2. Tunnel Created — FRP client connects to Bindu’s tunnel server
  3. Public URL Generated — random 12-character subdomain assigned
  4. Traffic Forwarded — requests to public URL are forwarded to your local agent

​
Local Testing Through The Tunnel

Once the tunnel is up, you can test the local agent from outside your machine.

​
Basic Development Test

# Terminal 1: Start agent with tunnel
uv run python my_agent.py

# Terminal 2: Test from anywhere
curl https://abc123xyz.tunnel.getbindu.com/
This is the simplest use case: keep the code local, but make the agent reachable from the internet during development.
The tunneled agent is still your local process. If the process stops, the tunnel is no longer useful because there is nothing listening behind it.

​
The Value Of A Public Development URL

Tunneling is most useful when local development has to interact with something outside the machine.
Test your agent without deploying it. The agent runs on your machine, but the public URL makes it reachable for quick external checks.
Use the tunnel when an external service needs to call back into your local agent during development.
Share the public URL with someone else so they can hit the agent without asking you to deploy it first.
Use the tunnel for demos where local iteration matters more than production deployment.

​
Limits And Troubleshooting

Tunneling is intentionally narrow in scope. It solves development reachability, not production hosting.

​
Current Limits

  • Development Only — not suitable for production traffic
  • Temporary URLs — the 12-character subdomain changes on each restart
  • No Persistence — the tunnel closes when the agent stops

​
For Production

Do not use tunneling in production. Production workloads should use proper infrastructure instead of a development tunnel.

​
Connection Timeout

If the tunnel fails to connect, verify your network allows outbound connections to the FRP server: 
# Check internet connection
ping tunnel.getbindu.com

# Ensure outbound connections to port 7000 are allowed
If the tunnel cannot connect, start with the network path and firewall rules (specifically port 7000) before debugging anything in the agent itself.

​
Practical Boundaries

Good Fit

Tunneling is a good fit when you need quick public access to a local agent for testing, demos, or webhook development.

Wrong Fit

It is the wrong fit for production traffic, persistent public infrastructure, or anything that depends on strong uptime guarantees.
Sunflower LogoBindu tunneling makes a local agentreachable for development without pretending to be production, so testing can move faster without changing where you build.