sish

Open-source tunneling infrastructure, honestly reviewed. What you actually get when you stop paying for ngrok and run your own.

TL;DR

• What it is: Open-source (MIT) SSH tunnel server — you run ssh -R with your existing SSH keypair and get a public HTTPS/TCP endpoint, no proprietary agent required [README].
• Who it’s for: Developers and small engineering teams who need persistent, self-controlled tunneling infrastructure for webhooks, local dev sharing, or exposing TCP services — and are tired of ngrok’s free-tier restrictions [1][README].
• Cost savings: ngrok’s free tier caps you at 1 tunnel with random subdomains and bandwidth limits; paid plans start around $8–10/mo per seat. sish self-hosted runs on a $5–6/mo VPS with unlimited tunnels, custom subdomains, and no per-seat pricing [README][1].
• Key strength: Standard SSH is the client. Anyone on your team with an SSH keypair can connect without installing anything beyond what they already have [README].
• Key weakness: No management UI, no traffic inspector, no dashboard. This is a server you configure via flags — not a product you click through [README][1].

---

What is sish

sish is an SSH server written in Go that handles forwarding and multiplexing. You point your SSH client at it using the -R flag — the same flag you’d use to forward a port through a bastion host — and sish turns that connection into a public URL [README].

The project describes itself as “open source serveo/ngrok alternative” in the README, which is accurate. Serveo was a free, no-install SSH tunneling service that became unreliable and eventually went down. Sish is what you deploy yourself to get that same behavior under your own domain, with your own infrastructure, and with a license that doesn’t restrict what you do with it [README][1].

At 4,560 GitHub stars, it’s not the biggest project in the tunneling space (frp sits at 76,000+), but it occupies a specific niche: the tool where SSH is the entire client interface, not just the transport [3][README]. You don’t configure a YAML file, you don’t install a daemon, you type one SSH command and you have a tunnel. That’s the whole pitch.

The project is maintained by antoniomika and sponsored by pico.sh. There’s a managed version at tuns.sh if you want to validate the workflow before self-hosting [README].

---

Why people choose it

The SaaSHub alternatives page [1] lists sish as the third-most-cited alternative to ngrok (after localhost.run), which tells you the positioning: it’s in the “self-hosted, open-source, no custom client” corner of the tunneling market.

Versus ngrok. This is the comparison that drives most sish adoption. ngrok has become the default choice for local dev tunneling, but its free tier is structurally frustrating: one tunnel at a time, random subdomains that change on every restart, bandwidth caps, and no persistent URLs without a paid plan. Sish removes all of these constraints by design — you run it on a VPS with your domain, set subdomain rules, and tunnels are as stable as your SSH connection [1][README]. More importantly, ngrok requires installing and authenticating their proprietary agent. Sish requires nothing beyond SSH, which is already on every developer machine and CI runner [README].

Versus Cloudflare Tunnel. Cloudflare’s free tunneling product is excellent for production deployments — it integrates with their WAF, CDN, and access policies. But it requires a Cloudflare account, ties your infrastructure to their platform, and the cloudflared daemon is another binary to install and update. Sish requires SSH, which is already there [1].

Versus frp. frp (76,000+ stars) is the most capable self-hosted tunneling tool in terms of raw features — it supports XTCP, KCP, QUIC, and complex load-balancing scenarios [3]. But frp requires both a server-side config (frps.ini) and a client-side config (frpc.ini). Sish requires only the server config; the client is a one-liner SSH command. For teams where developers shouldn’t need to touch config files to share a local service, that difference matters [3][README].

Versus localhost.run. localhost.run is the closest to sish in the “SSH-only, no client needed” approach. The difference is that localhost.run is a hosted service — you’re trusting their infrastructure. Sish is what you run yourself if you want the same UX under your own domain with your own keys [1][2].

The honest summary: sish wins on simplicity of the client interface and self-sovereignty. If you’ve ever watched a developer struggle to install and authenticate the ngrok agent in a CI pipeline, sish is the answer — ssh -R 80:localhost:8080 your-server.com just works with any standard SSH client [README].

---

Features

From the README and documentation:

Tunnel types:

• HTTP and HTTPS with automatic TLS (via Let’s Encrypt) [README]
• WebSocket (WS/WSS) tunneling [README]
• Raw TCP port forwarding [README]
• TCP aliases — private internal-only access reachable only through authenticated SSH connections, not exposed publicly [README]
• SNI proxy support — routes TLS traffic by server name without terminating TLS, letting multiple backends share one port [README]

Routing and access control:

• Custom subdomains on your domain (e.g., ssh -R myapp:80:localhost:3000 sish.yourdomain.com) [README]
• Random subdomain fallback when custom name is taken [README]
• Key-based authentication with dynamic key reloading — add authorized keys without restarting [README]
• Password authentication option [README]
• Restrictive binding policies for multi-tenant deployments [README]
• Load balancing modes for HTTP, TCP, and SNI aliases when multiple clients bind the same name [README]

Observability:

• Service console for inspecting forwarded requests [README]
• No web dashboard — the console is SSH-based [README]

Deployment:

• Docker images published (antoniomika/sish on Docker Hub) [README]
• Binary releases for direct installation [README]
• No external database dependency — sish is a single binary [README]

What it doesn’t have:

• No traffic inspector UI like ngrok’s localhost:4040 web interface
• No replay of requests
• No usage analytics dashboard
• No built-in auth for the tunneled service (sish secures the SSH connection, not what’s behind it)

---

Pricing: SaaS vs self-hosted math

tuns.sh (their managed service): No public pricing is listed in the available sources. The README presents it as a validation tool — try it before self-hosting — rather than a commercial product [README].

ngrok for comparison [1]:

• Free: 1 tunnel, random subdomain, bandwidth limits, no custom domains
• Paid: starts ~$8–10/month per seat; custom domains, multiple tunnels, team features on higher tiers
• Enterprise: custom pricing

Self-hosted sish:

• Software license: $0 (MIT) [README]
• VPS: $5–6/month (Hetzner CX11, Contabo, or DigitalOcean Droplet) handles typical single-team use
• Domain: whatever you already pay for yearly
• TLS: automatic via Let’s Encrypt, $0

Concrete math for a small dev team:

A team of 3 developers, each needing persistent custom subdomains for webhook development and local service sharing. On ngrok’s paid plan at ~$10/seat/month, that’s $30/month. Self-hosted sish on a $6 Hetzner VPS: $6/month total, shared across the whole team, unlimited tunnels, custom subdomains on your domain. Over 12 months: ngrok ≈ $360, sish ≈ $72 + one setup afternoon. The $288 annual savings buys a lot of VPS headroom [1][README].

The math only improves as your team grows. ngrok charges per seat; sish charges for one VPS regardless of how many developers SSH into it.

---

Deployment reality check

sish deploys as a Docker container, and the README provides the exact command [README]:

docker run -itd --name sish \
    -v ~/sish/ssl:/ssl \
    -v ~/sish/keys:/keys \
    -v ~/sish/pubkeys:/pubkeys \
    --net=host antoniomika/sish:latest \
    --ssh-address=:2222 \
    --http-address=:80 \
    --https-address=:443 \
    --https=true \
    --https-certificate-directory=/ssl \
    --authentication-keys-directory=/pubkeys \
    --private-keys-directory=/keys \
    --domain=example.com

What you need:

• A Linux VPS with a public IP and ports 80, 443, 2222 open
• A domain with a wildcard DNS record pointing to your VPS (*.yourdomain.com → VPS IP)
• Docker installed
• Your team’s SSH public keys dropped into the pubkeys directory

What can go sideways:

• The wildcard DNS requirement catches people off guard. Your domain registrar or DNS provider needs to support wildcard records — most do, but some cheap registrars don’t, and some CDN configurations conflict with wildcards.
• Authentication is all-or-nothing by default: you either accept the public key or you don’t. Fine-grained per-user routing rules require more configuration work than the README surfaces.
• The --net=host flag is required for TCP forwarding to work properly in Docker. If your VPS runs a restrictive container runtime or you’re on a platform that doesn’t allow host networking (some managed container services), this gets complicated.
• No admin UI means debugging misbehaving tunnels requires reading Docker logs directly. The service console helps, but it’s not as polished as ngrok’s introspection interface.
• sish secures the connection, not the service. If your local app doesn’t have auth, anyone with your public URL can reach it. This is expected behavior, but non-technical teammates sometimes assume the tunnel adds a security layer that it doesn’t [README].

Realistic time estimates:

• Developer already comfortable with Docker and DNS: 20–30 minutes to a working HTTPS tunnel.
• Developer who’s set up a VPS before but less familiar with DNS wildcards: 1–2 hours.
• Non-technical user: this is not the right tool. The deployment and key management steps require SSH comfort that isn’t something you can hand off to someone who’s never touched a terminal.

---

Pros and cons

Pros

• Standard SSH is the entire client. No proprietary binary, no auth token to manage, no agent to install. Works from any machine, any CI runner, any OS [README].
• MIT licensed. No usage restrictions, no commercial licensing required, fork and embed freely [README][1].
• Unlimited tunnels on your own infrastructure. No per-seat, per-tunnel, or per-bandwidth pricing once you’re self-hosted [README][1].
• Private TCP aliases. The ability to create SSH-jump-accessible private tunnels — not publicly exposed — is a feature most hosted alternatives don’t offer at all [README].
• SNI routing. Route multiple TLS backends through one port by SNI without terminating TLS. Useful for multi-tenant setups [README].
• Dynamic key reloading. Add or revoke SSH keys without restarting the server — practical for teams where members change [README].
• Single binary / minimal dependencies. No database, no external queue, no complex config [README].
• Managed option to try first. tuns.sh lets you validate the SSH workflow before committing to a VPS [README].

Cons

• No web UI or traffic inspector. ngrok’s localhost:4040 dashboard — where you can see every request, replay it, inspect headers — has no equivalent in sish. You’re reading logs [README].
• Requires SSH knowledge to use. The “no custom client” strength is also a usability ceiling — your team needs to be comfortable with SSH flags and key management [README].
• Wildcard DNS required. A non-obvious infrastructure requirement that blocks people unfamiliar with DNS configuration.
• No built-in auth for tunneled services. The tunnel is secured; what’s behind it is your problem [README].
• Thin third-party documentation. Most of what’s written about sish is in comparison tables, not practical guides [1][2][3][4]. If you hit an edge case, the README and docs.ssi.sh are your primary references.
• Not suitable for non-technical users. Despite the elegant simplicity of the SSH command, the setup process — VPS, DNS, key management — requires technical competence [README].
• Small community relative to frp or ngrok. 4,560 stars vs. 76,000+ for frp. Finding Stack Overflow answers or community guides for edge cases is harder [3].

---

Who should use this / who shouldn’t

Use sish if:

• You’re a developer or small engineering team paying for ngrok and resenting the per-seat pricing model.
• Your CI/CD pipelines need webhook endpoints and you don’t want to manage ngrok auth tokens across runners.
• You want your tunneling infrastructure under your domain with your keys — not a vendor’s subdomain.
• You need TCP aliases for private internal access patterns between team members.
• You’re already running a VPS for something else and adding sish costs essentially nothing.

Skip it (use tuns.sh or localhost.run) if:

• You want the SSH tunneling workflow but don’t want to manage a VPS at all. The managed options exist for exactly this.

Skip it (use ngrok) if:

• You need the traffic inspection UI — replaying requests, inspecting headers in a browser while your webhook fires — is a core part of your debugging workflow. ngrok’s introspection has no equivalent in sish.
• You need access control on the tunneled URL itself (ngrok’s IP policies, auth middleware) rather than just on the SSH connection.
• Your team has zero Linux/SSH experience. ngrok’s agent is a GUI-friendlier onramp.

Skip it (use Cloudflare Tunnel) if:

• This is production traffic, not development. Cloudflare Tunnel is free, integrates with their WAF and Access policies, and is more operationally hardened for sustained production load.
• You’re already in the Cloudflare ecosystem.

Skip it (use frp) if:

• You need UDP forwarding, QUIC transport, or complex load-balancing scenarios. frp’s feature set is broader; sish’s is simpler [3].

---

Alternatives worth considering

From the SaaSHub comparison pages [1][2] and the open-source alternatives lists [3][4]:

• ngrok — the incumbent. Easiest onramp, best introspection UI, proprietary agent, per-seat SaaS pricing. Go here if you need the dashboard or your team isn’t comfortable with SSH config.
• Cloudflare Tunnel — free, production-grade, integrates with Cloudflare’s security stack. Requires cloudflared agent and a Cloudflare account. Best for persistent production endpoints, not ad-hoc dev sharing.
• frp (76,000+ stars) — the most capable self-hosted option. Supports UDP, QUIC, complex routing. Requires both server and client config files [3].
• localhost.run — SSH-based like sish but hosted, no self-hosting needed. Free tier available, no custom domains without payment [1][2].
• Chisel — TCP/UDP tunnel over HTTP. Good for environments where SSH egress is blocked but HTTP isn’t [3].
• zrok — newer, built on OpenZiti, designed for zero-trust networking rather than simple port forwarding [1].
• Pagekite — older, battle-tested, custom subdomain support, commercial service with self-hosting option [1][2].
• Packetriot — commercial, $5/month for 5 tunnels, custom domains, IP filtering — a middle ground between ngrok’s pricing and full self-hosting [1].
• Expose — PHP-based open-source tunnel server if your stack is PHP-native [1].

For a developer team choosing between self-hosted options, the realistic comparison is sish vs frp: sish wins on client simplicity (no config file required), frp wins on feature depth and community size.

---

Bottom line

Sish does one thing cleanly: it turns a standard ssh -R command into a public HTTPS endpoint. No custom client, no vendor account, no per-tunnel fees, MIT licensed. If your team’s pain is ngrok’s seat pricing or random subdomains that break your webhook registrations every time you restart the tunnel, sish solves that with one Docker container and a wildcard DNS record. The trade-offs are honest: there’s no traffic inspector UI, setup requires real SSH and DNS competence, and the community is small enough that edge-case troubleshooting falls back to the README. This is infrastructure for developers, not a product for non-technical users. But for the right team — developers who live in the terminal and want to stop paying per-seat for something that should cost $6/month — sish is exactly as simple as it should be.

If the VPS setup is the blocker, upready.dev deploys this kind of infrastructure for clients as a one-time engagement.

---

Sources

1. SaaSHub — sish Alternatives & Competitors (comparison page with 12+ alternatives listed, community votes and feature comparisons). https://www.saashub.com/sish-alternatives
2. SaaSHub — Staqlab Tunnel Alternatives & Competitors (sish listed as top-3 alternative). https://www.saashub.com/staqlab-tunnel-alternatives
3. Awesome Open Source — go-http-tunnel Alternatives (sish listed alongside frp, chisel, rathole, gost with star counts and license data). https://awesomeopensource.com/project/mmatczuk/go-http-tunnel
4. Awesome Open Source — croc Alternatives (sish listed in TCP/networking alternatives context). https://awesomeopensource.com/project/schollz/croc

Primary sources:

• GitHub repository and README: https://github.com/antoniomika/sish (4,560 stars, MIT license)
• Documentation: https://docs.ssi.sh
• Managed service: https://tuns.sh
• Sponsor: https://pico.sh