Turbotunnel limits
Check request, connection, and startup limits before opening a tunnel.
Use these limits to determine how Turbotunnel handles request volume, large bodies, slow applications, and connection pressure.
| Surface | Limit | Scope and result |
|---|---|---|
| Tunnel availability | While tt http or tt dev runs |
The public URL needs a connected local process |
| HTTP request duration | 30s | A gateway timeout returns 504; a local forwarding failure returns 502 |
| Request body | 4 MiB (4,194,304 bytes) | The gateway rejects a larger request with 413 before contacting the local app |
| Response body | 4 MiB (4,194,304 bytes) | A larger local response returns 502 |
| Direct HTTP capacity | 32 in-flight requests per relay socket | The gateway uses Vercel Queue when no relay socket has capacity |
| Public WebSockets | 32 per tunnel slug per gateway instance | The gateway closes excess connections with code 1013 |
| WebSocket buffering | 256 pending events or commands | The connection closes with code 1013 instead of dropping protocol frames |
| Local relay pool | 1 to 16 sockets; default 2 | Each socket connects independently |
tt list request |
5s and a 1 MiB response | The command fails instead of returning incomplete data |
| Gateway presence replay | 10,000 events | The endpoint returns an error instead of a partial list |
Vercel may run several gateway instances. Do not multiply the public WebSocket limit by an assumed instance count. The active instance count can change.
An HTTP request may reach the local app before a 504 response. Avoid retrying non-idempotent requests unless your application detects duplicates.