dalang tunnel trydalang.io

A public URL for the server on your laptop.

One command gives you an HTTPS address that anyone can open. Requests arrive at your machine, your code answers them, and nothing is built, uploaded or deployed anywhere. 

$ dalang tunnel --url http://localhost:8000
  tunnel open  https://kucing-makan-ikan.trydalang.io
  forwarding   http://localhost:8000
  expires      in 2h 00m · ctrl-c to stop

Point --url at whatever port you are already running.

Install

The tunnel is part of the dalang CLI. If you already have it, skip this.

Linux, macOS, Termux

$ curl -fsSL https://trydalang.io/install.sh | sh

Windows

PS> irm https://trydalang.io/install.ps1 | iex

Then run dalang tunnel --url http://localhost:8000. No account, no config file, no signup form. Run dalang auth first if you want the longer limits below.

What you get

An address on trydalang.io, over HTTPS, pointing at one port on your machine.

The label in front is three ordinary Indonesian words — subject, verb, object. kucing-makan-ikan is "cat eats fish". It is readable over a phone call, which a string of hex is not. You can ask for a specific one with --subdomain if it is free.

The URL lives as long as the tunnel does. Close the terminal and it stops resolving; a request to a label with nobody behind it gets a plain 404, not a stale page. If your connection drops, the CLI reconnects and keeps the same address.

How a request reaches you

Your machine never accepts an inbound connection. The CLI dials out, and everything rides back down that one connection.

Someone's browser GET https://kucing-makan-ikan.trydalang.io/

Over HTTPS. Cloudflare terminates TLS and hands the request to the tunnel server as plain HTTP.

Tunnel server looks up the label, finds your open tunnel

Down one WebSocket that your CLI opened outbound. Nothing to port-forward, nothing to open in your firewall.

Your laptop dalang tunnel → http://localhost:8000

The response takes the same path back. Each request and response is carried whole rather than streamed, which is where most of the limits below come from. If your local server is not running, the visitor gets a 502 that names the URL the CLI could not reach, so you know it is your app and not the tunnel.

Limits

These are v1 scoping decisions, not surprises. Better to read them now than to spend an afternoon debugging your own code.

Body size 10 MB per request and per response. Anything larger gets a 413, and the CLI prints why.
Streaming and SSE Not supported. Bodies are buffered whole in both directions, so chunked responses and server-sent events will not behave.
WebSockets through the tunnel Not supported. A request carrying Upgrade: websocket gets a 501. Your app's own WebSockets will not work over a tunnel in v1.
How long it lives 2 hours anonymous. 8 hours after dalang auth. Then it closes and the URL stops resolving.
Tunnels at once 1 per IP anonymous. 3 per account after dalang auth.
Requests in flight 32 per tunnel. Past that the server returns 503 rather than queueing until the browser gives up.

What it is for

A tunnel is a way to show someone something. It is not a way to run something.

Good fit

  • Showing a colleague the thing you are in the middle of building.
  • Giving a payment gateway or a Git host somewhere to send a webhook while you watch it arrive.
  • Demoing from a laptop without deploying first.
  • Checking how your work in progress behaves on a real phone, on real mobile data.

Wrong tool

  • Anything that has to stay up. The tunnel ends with your terminal session.
  • Large uploads or downloads, video, or any long-lived stream.
  • An app whose core feature is a WebSocket.
  • Production traffic, or a URL you put in front of customers.

If what you actually need is hosting, that is the rest of the company: dalang.io runs VPS, containers and dedicated servers out of Indonesian data centers, with a fixed address that survives you closing your laptop.