// the take
Drip is a self-hosted alternative to ngrok/Cloudflare Tunnel: you run the server on your own box with your own domain, and it proxies HTTP, HTTPS, TCP, and WebSocket traffic from the internet to a local service over an encrypted tunnel. It's aimed at developers and small teams who want tunnel infrastructure they control instead of a SaaS with bandwidth caps.
The protocol work looks real rather than bolted on — there's a dedicated frame/heartbeat/adaptive protocol layer (internal/shared/protocol), a connection pool with a scaler for the client side, and per-tunnel QoS using a token bucket with client/server min() enforcement, which is the correct way to do bandwidth limiting on a shared link. Test coverage is unusually good for a project this size: bandwidth, connection groups, listeners, websocket handling, and the registration handshake all have their own _test.go files. The deployment story is practical — Dockerfiles, docker-compose for both plain and Caddy-fronted setups, and example nginx/Caddy configs instead of just "figure it out".
All documentation beyond the README lives on an external site (driptunnel.app) with nothing mirrored in-repo, so there's no offline docs and the install script piping curl straight to bash is the only onboarding path shown. There's no CONTRIBUTING.md or architecture doc, which is a real gap for a project with this much internal protocol/transport complexity — a new contributor has to reverse-engineer internal/server/tcp and internal/client/tcp from scratch. Tunnel/connection state appears to be purely in-memory (port_allocator, connection_group_manager), so a server restart likely drops every active tunnel with no persistence or reconnect-and-resume story mentioned anywhere. Auth is just a static bearer token per the changelog — there's no mention of token rotation, scoping, or per-tunnel ACLs, so a leaked token probably grants full tunnel access.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →