← Back

How Wormkey works — and why I built it

A short story about building a localhost tunnel that just works.

Why I built it

A friend of mine couldn't share his demo because of something to do with Vercel. I don't know why exactly, but we tried a lot of things and couldn't get it to work. So I built Wormkey.

It's much faster than ngrok or Cloudflare Tunnel. It's more accessible for non-developers — no signup, no dashboard, no DNS. Just run a command and share the link. Easy.

It's not a deploy platform. It's not a hosting provider. It's a controlled wormhole from your laptop to the internet. When you're done, you close the tunnel and it's gone.

How it works

When you run wormkey http 3000, three things happen:

  1. Session — The CLI talks to a control plane and gets a unique slug (e.g. quiet-lime-82). No auth, no signup. Just a slug.
  2. Tunnel — The CLI opens a WebSocket to an edge gateway and keeps it open. Traffic flows through that pipe: HTTP, WebSocket, everything. Your app stays on your machine.
  3. Public URL — Anyone can hit wormkey.run/s/quiet-lime-82 and reach your localhost. The gateway terminates TLS, routes by slug, and streams requests back and forth.

The protocol is simple: binary frames over WebSocket. Open stream, send data, close stream. HTTP requests become streams. WebSocket upgrades become duplex pipes. No magic, just plumbing.

Architecture

Here’s how the pieces fit together:

ViewerbrowserEdge GatewayTLS, routingCLIwormkeylocalhost:3000Control Planesession, slugHTTPSWebSocketHTTPget slug

If that sounds useful, give it a try:

npm i -g wormkey
wormkey http 3000

— Built for developers who just want to share.