Expose
Public URLs for localhost
Turn a service running on your machine into a reachable public endpoint without deploying a full preview environment first.
Introduction
Binboi docs, split into maintainable guides instead of one giant page.
Binboi is a tunneling and webhook inspection platform for developers who need public URLs, clear CLI authentication, and a calmer way to debug what reached their local app. This landing page introduces the product, explains the model, and points you to the focused documentation guides.
Overview
What Binboi is
Binboi combines a Go relay, a CLI agent, and a dashboard into one developer workflow. The relay gives you a public endpoint, the CLI bridges traffic back to your machine, and the dashboard explains what is happening with tunnels, tokens, logs, and webhook-oriented debugging.
The platform sits in the same family of tools as ngrok, but the product direction leans harder into dashboard visibility, request debugging, and self-hosted control plane clarity. Binboi is especially useful when local development needs to interact with systems that demand a public callback URL, such as payment providers, auth systems, source-control events, or internal QA workflows.
Inspect
Developer-friendly visibility
Move from raw guesswork toward structured visibility around tokens, tunnel state, request metadata, and webhook failures.
Operate
Self-hosted control plane
Run the relay yourself, keep product behavior understandable, and build up from a coherent HTTP tunnel MVP.
Why use it
Why someone would choose Binboi
Most teams reach for Binboi when localhost stops being enough but a full deployment still feels too heavy.
Webhook development
Stripe, Clerk, GitHub, Supabase, and other providers need a public URL. Binboi gives you one while keeping the code local and the debugging loop tight.
Local QA and demos
You can share a stable tunnel URL with another engineer, QA tester, or stakeholder without asking them to run the project locally.
Safer debugging
The docs and product model are designed to help you answer practical questions quickly: did the request arrive, which token was used, which route handled it, and where did it fail?
Self-hosting control
If you want a tunnel system with a transparent control plane instead of an opaque hosted service, Binboi gives you a cleaner starting point.
The simplest framing
Binboi is for the moment when you need a public URL for local work, but you also want the product to explain itself instead of behaving like a black box.
Core model
The small set of concepts that powers the whole product
The product becomes much easier to reason about when you keep the model small and consistent.
Tunnel
A reserved route between a public URL and a local target service reachable through a connected agent.
Agent
The CLI process that authenticates to the relay and forwards traffic to your target port.
Public URL
The external host assigned by the relay, such as `https://orders.binboi.link`.
Target service
Your local application, typically `localhost:<port>` or a service inside your development container network.
Requests and webhooks
HTTP traffic that reaches the relay and is forwarded to your app, including third-party callbacks from providers.
Access tokens
Dashboard-issued credentials used by `binboi login` so the CLI can authenticate securely.
The platform architecture follows directly from those concepts: the dashboard manages operator workflows, the control plane validates tokens and tracks tunnel state, and the CLI keeps a transport session open between the public relay and your machine.
Preview
A short quick-start before you dive deeper
The basic path is straightforward: install the CLI, create a token in the dashboard, log in once, and start an HTTP tunnel.
Shortest useful path
bash
brew install binboi/tap/binboi
binboi login --token <dashboard-token>
binboi whoami
binboi start 3000 my-appThe current repository uses `binboi start` for the working HTTP tunnel flow. Product-facing `binboi http` is documented as the likely ergonomic alias.
What success looks like
1. `binboi login` validates your token and writes it to `~/.binboi/config.json`.
2. `binboi whoami` confirms the CLI can still authenticate against the backend.
3. `binboi start 3000 my-app` prints a public URL and keeps the agent session online.
4. Requests to that URL are forwarded to your local service and surfaced through the dashboard and relay logs.
Docs map
Explore the main guides
Each route focuses on one slice of the product so the docs stay maintainable and easier to update.
Quick Start
Install, log in, and ship your first public URL in a few steps.
Installation
Homebrew, npm wrapper direction, direct binaries, and contributor setup.
Authentication
Access tokens, dashboard token creation, login, and security notes.
CLI
Commands, examples, and what is implemented versus planned.
HTTP Tunnels
How Binboi forwards HTTP traffic and common local development patterns.
Requests
Request inspection, metadata, response previews, and error classifications.
Webhooks
Clerk, Neon, Supabase, Stripe, GitHub, and Linear debugging workflows.
API Keys
Create, review, revoke, and safely operate CLI credentials.
Logs
Raw relay logs, activity events, and tunnel lifecycle visibility.
Regions
Regions, nodes, latency, and selection guidance for self-hosted teams.
Troubleshooting
Invalid token, tunnel offline, forwarding failures, and webhook confusion.
What is implemented today
The strongest current product surfaces are HTTP tunnels, dashboard-backed access tokens, `binboi login`, `binboi whoami`, relay event logs, and a coherent self-hosted control plane. Some richer request inspection and integration flows are still MVP or planned, and the docs call that out directly instead of hiding it.