JumboBridge ships as a single Docker image. Publish two ports, mount a volume for your data, and you have the whole console — forwarding, mocks, echo servers, an API client and a network simulator — running locally in about a minute.
Pull and run the published release from Docker Hub. This publishes the web UI on 8080 and the whole 20000–20100 forwarding range, and persists your projects to a named volume:
docker run -d --name jumbobridge \
-p 8080:8080 -p 20000-20100:20000-20100 \
-v jumbobridge-data:/data \
time2wall/jumbobrdige:v0.1.0Then open http://localhost:8080 — create a project, add a forward rule or mock server, and share host:port with whoever needs it.
Publish the whole range. The 20000-20100 mapping is what forward rules and mock servers bind to — without it they'll start but be unreachable from your host.
Keep the volume. -v jumbobridge-data:/data persists your config across restarts. Drop it for a throwaway instance.
Prefer Compose? Save this as docker-compose.yml and run docker compose up -d:
# docker-compose.yml
services:
jumbobridge:
image: time2wall/jumbobrdige:v0.1.0
container_name: jumbobridge
ports:
- "8080:8080" # web UI + API
- "20000-20100:20000-20100" # forwarding / mock port range
environment:
PORT_RANGE: "20000-20100"
UI_PORT: "8080"
RUST_LOG: "info"
volumes:
- jumbobridge-data:/data
restart: unless-stopped
volumes:
jumbobridge-data:Every setting is optional — the defaults below match the built-in behaviour. Pass them with -e on docker run or under environment: in Compose.
| Variable | Default | Description |
|---|---|---|
| UI_PORT | 8080 | Web UI / API port (also settable via JUMBO_PORT). |
| PORT_RANGE | 20000-20100 | Range reserved for forwards, mocks and echo servers. |
| DATABASE_URL | (unset) | sqlite:… or postgres:…; unset means a local SQLite file. |
| JUMBO_SQLITE_PATH | /data/jumbobridge.db | SQLite file location when DATABASE_URL is unset. |
| JUMBO_HOST | 0.0.0.0 | Bind address. Set 127.0.0.1 to restrict to localhost. |
| JUMBO_DEV | false | true enables development mode (permissive CORS, debug logging). |
| RUST_LOG | info | Log filter (tracing EnvFilter syntax). |
Trust model. JumboBridge has no built-in authentication and binds 0.0.0.0 by default. Its API client and forwarders can reach internal hosts, so run it on a trusted network (or behind your own auth proxy) — don't expose it to the public internet. Set JUMBO_HOST=127.0.0.1 to restrict it to localhost.
Here's the whole workflow, screen by screen — from opening the dashboard to breaking the network on purpose.
Browse to http://localhost:8080. The dashboard shows the reserved 20000–20100 range, how many ports are free, reserved and active, and a live activity feed of every forwarder and mock — refreshed over a WebSocket as traffic flows.
Projects keep related forwards, mocks and disruption scenarios together. A Default project always exists; hit New Project to add your own — for example one per integration you're testing.
Pick a source port from the range (or let it auto-assign) and point it at any host:port — TCP, UDP or HTTP. Start and stop each rule from its card and watch the connection and byte counters climb. Share host:port with whoever needs the tunnel.
Mock servers answer traffic instead of forwarding it. Choose a protocol — HTTP, WebSocket, raw TCP, or an MCP/LLM simulator — then add priority-ordered rules that match on method, path, headers or body and return templated responses. Every request is logged per server.
Need to prove a path end-to-end fast? An echo server is a TCP or UDP listener that mirrors back whatever it receives — perfect for a quick connectivity smoke test through a forward or a disruption.
The built-in API client sends HTTP and WebSocket requests server-side — no CORS, and it can reach internal ports. Save requests, swap in {{variables}} from an environment, inspect the full response, keep a history, schedule monitors, or drive a request as concurrent load.
Arm a disruption scenario against any forward or mock: latency (with jitter), throttle, drop, corrupt, partial, blackhole or close. Stack several at once and run them continuously or on a random schedule to see what actually holds.
Point the MCP Explorer at any Model Context Protocol server, connect, and browse its tools, resources and prompts — then invoke them live. Bookmark servers per project so they're a click away.
A standalone command-line runner is on the way — the forwarding, echo and mock engines without the UI or control server, driven from flags, a config file, or the very same database the server uses. Here's a preview of what it'll look like:
jb forward --listen 20000 --to example.com:80 # one forwarder
jb up --config bridge.toml # a batch from a file
jb up --sqlite-path /data/jumbobridge.db # run what the UI definedThe jb binary isn't available yet — it'll ship in a future release. For now, run everything through the Docker image and its web console above.
Pull the image, open the console, and put an elephant between your services.