Chisel solves the awkward middle between SSH and a VPN
Chisel is for the moment when ordinary SSH forwarding is inconvenient, a full VPN is excessive, and outbound HTTP is one of the few paths a network permits. It packages a client and server into 1 Go executable, sends TCP or UDP tunnels over HTTP, and secures the connection with the SSH protocol. That combination makes it useful for development access, controlled operations work, homelabs, and temporary routes into otherwise unreachable services.
The project is not a hosted relay or a policy platform. You provide the server, decide what it can reach, and control who connects. Its 16,492 GitHub stars indicate broad awareness, but popularity should not be confused with safe configuration. A Chisel server can become a meaningful network entry point, so its small binary reduces packaging effort, not operational responsibility.
What happened when we ran it
We cloned commit 3c00f04 and ran it on September 5, 2026 in an unprivileged Debian container with 3 CPUs and 8 GB of RAM. Installation succeeded in 29 seconds and installed 28 packages. The repository contained 97 files, about 8,462 lines of source, and occupied 0.3 MB when checked out, which is genuinely compact for the number of tunneling modes advertised.
The build then succeeded in 25 seconds. The Go test run finished in 35 seconds, with 18 passed and 0 failed out of 18. That is our result on our box, not a general performance benchmark, and it says nothing about throughput or behavior under packet loss. It does show that the checked commit could be installed, compiled, and tested without secret credentials or privileged container access.
We also found 2 CI workflow files and a tests directory, both useful maintenance signals. There was no Dockerfile in the cloned repository, although the README documents published multi-architecture images on Docker Hub and GitHub Container Registry. In other words, consuming an image is documented, while the measured source tree does not give operators a local Dockerfile to inspect as part of this review.
One connection can carry several useful tunnel shapes
Chisel's strongest practical feature is consolidation. A client can create multiple endpoints over 1 TCP connection, forward normal or reverse ports, carry TCP or UDP traffic, and optionally provide SOCKS5 access. It can also pass through SOCKS or HTTP CONNECT proxies. Those choices cover more constrained-network cases than a tool that only publishes one local TCP port.
The reconnect behavior is similarly grounded in real operational problems. Clients use exponential backoff with tunable minimum and maximum retry intervals, while keepalive pings detect connections lost after sleep, NAT expiry, or a server restart. Stdio mode also supports ssh -o ProxyCommand, providing a route for SSH over HTTP when a direct SSH connection is unavailable.
Server mode can double as a reverse proxy for ordinary web requests. The README's Fly.io example sends normal browser traffic to a backend while the same endpoint accepts Chisel clients, and the default server port is 8080. This can fit hosting environments built around HTTP ingress, but sharing a public endpoint also makes careful routing and observability more important.
Security features are useful, but configuration carries the risk
Connections use Go's crypto/ssh, and clients can match the server fingerprint to detect a machine-in-the-middle attack. The server supports a users file containing credentials and allowed-address regular expressions, reloads that file when it changes, and applies updates to new tunnels without interrupting established ones. Version 1.12.0 therefore exposes enough controls for a deliberately managed small deployment.
The sharpest edge is in those address expressions. The README explicitly warns that patterns are not anchored by default, so a pattern intended for 10.0.0.1:80 can match a longer, unintended address. SOCKS5 permission also needs an explicit matching rule, while an empty rule matches everything. These are documented hazards, but they are exactly the sort of details a hurried operator can miss.
Key handling deserves equal attention. Without a persistent key choice, the server can generate a new key on each run, while users relying on fingerprint verification need a stable identity. Chisel offers --keygen and --keyfile, including an inline ck- value, yet the operator must still store that private material appropriately and distribute the expected fingerprint through a trusted channel.
The project looks active, with an issue backlog worth checking
The latest supplied release is v1.12.0 from August 29, 2026, and the last push was September 1, only 4 days before this review. Taken together, those dates are strong current-maintenance signals. The repository also gained 6 stars in the supplied trending snapshot, though a one-day star change is attention, not evidence of support quality. One release date alone cannot establish a long-term release cadence.
There are 246 open issues. That is enough that prospective users should search for their operating system, proxy type, UDP needs, and authentication pattern before standardizing on Chisel. The supplied data does not show response times or how many issues are confirmed bugs, so we would not claim the backlog is either healthy triage or neglect. Recent code and release activity matter more than issue count alone.
It belongs at a narrow network boundary, not as your control plane
In a real stack, Chisel fits best as a focused transport between an explicitly managed server and a small number of clients. Put monitoring, firewall rules, secret management, and process supervision around it, then expose only the destinations each user needs. For a 1-off development path or recovery route, its portable binary and auto-reconnect behavior are compelling.
It is less convincing as an organization-wide replacement for a mesh VPN, identity-aware proxy, or managed tunnel service. Chisel's users file and address regexes are useful, but they are not centralized device posture, audit policy, or a friendly administration layer. If the goal is simply to move selected traffic through HTTP with minimal machinery, Chisel earns a shortlist spot; if the goal is governing hundreds of users and devices, start higher in the stack.