Dilnaka Cloud CLI
Development tunnels
Expose a local HTTP service through a temporary public Dilnaka URL without opening an inbound firewall port.
A tunnel is not a webhook
A provider webhook sends an event into Dilnaka Cloud, and a Dilnaka webhook delivers a Cloud event to your public endpoint. A development tunnel instead gives an ordinary HTTP client a temporary path to a server running on your computer.
The public request reaches Dilnaka Cloud, crosses the authenticated outbound connection held by the CLI, and is sent only to the loopback port you selected.
- Provider webhook: internet service → Dilnaka Cloud
- Dilnaka event webhook: Dilnaka Cloud → your public endpoint
- Development tunnel: internet client → Dilnaka Cloud → your local HTTP server
Start a free temporary tunnel
Sign in with the CLI, start your local HTTP server, and pass its port to the tunnel command. The public URL is printed only after the authenticated connector is ready.
npm install -g dilnaka-cli
dilnaka login
dilnaka tunnel 3000
# Tunnel ready: https://cloud.example/t/t-random-id
# Forwarding to http://127.0.0.1:3000Free development limits
Temporary HTTP tunnels are free in this first release. There is no billing call, subscription gate, or usage charge. The limits keep the service suitable for development while demand and operating cost are measured.
- Random temporary URL; no reserved hostname
- One-hour lifetime and three allocated tunnels per user by default
- Up to twenty in-flight requests per tunnel
- 2 MiB request body and 5 MiB response body defaults
- Thirty-second forwarding timeout
- Tunnel ends when the CLI disconnects or the relay restarts
- Request and response bodies are relayed but not stored
Connection and security model
The allocation request uses your existing CLI bearer token. Dilnaka then returns a separate high-entropy connector grant once; the relay retains only its SHA-256 hash. The grant is sent in the outbound WebSocket Authorization header and never appears in the public URL.
The CLI always forwards to 127.0.0.1 on the requested port. The remote request path cannot replace that fixed origin. Transport-only headers are removed, resource limits are enforced, and disconnecting releases the temporary allocation.
The public URL is a capability: anyone who has it can call the local service. Your application must still verify webhook signatures or require its own authentication when appropriate.
HTTP behavior
The relay supports GET, POST, PUT, PATCH, DELETE, OPTIONS, and HEAD. Paths, query strings, headers, status codes, and request or response bodies are carried across the connector. Redirects are returned to the caller rather than followed by the CLI.
An unknown or expired link returns 404. A newly allocated link returns 503 during the short interval before its connector arrives. Oversized requests return 413, while timeouts, disconnects, invalid connector responses, and oversized local responses return a bounded 5xx response.
POST /api/cli/tunnels # authenticated allocation
GET /api/tunnel/connect/{tunnel_id} # authenticated WebSocket upgrade
ANY /t/{random_slug}/{path} # temporary public HTTP linkCurrent scope and next phases
This release is an in-process development relay. Tunnel state is not stored in the database, so it does not survive a control-plane restart and does not provide a production SLA.
Persistent hostnames, shared relay workers, reconnectable sessions, higher limits, usage metering, and paid production guarantees are future HTTP-tunnel work. Database and raw TCP access are a separate track with project and service authorization; they will not reuse the public HTTP-link contract or expose database credentials.
- Not included: custom domains or stable URLs
- Not included: local WebSocket or SSE passthrough
- Not included: TCP, UDP, SSH, or database forwarding
- Not included: paid plans, metering, or production guarantees