O localhostly é uma alternativa ao Pinggy com a URL que fica

Os números da conta

Os cinco números abaixo são os limites da conta; o tráfego é contado nos dois sentidos, e o mês recomeça no dia 1, em UTC. Num limite, o visitante recebe uma página 429 que o nomeia e diz quando ele acaba.

• 2 túneis abertos ao mesmo tempo numa conta
• 1000 requisições por minuto, contadas numa janela deslizante de 60 segundos
• 25 GiB de tráfego por mês, somando os dois sentidos
• 1 e-mail para digitar no cadastro
• 429 ao passar de um limite, com o cabeçalho Retry-After preenchido

Um comando, uma URL pública

Nada é baixado à mão: npx localhostly 3000 busca o agente no npm e o roda. O agente abre uma conexão WebSocket de saída para o servidor do localhostly e a mantém, então nenhuma porta é aberta no seu roteador nem no firewall. Quando um visitante carrega a sua URL, o servidor acha o nome no endereço, entrega a requisição a essa conexão, e o agente a executa contra a sua porta local e devolve a resposta em stream. HTTP e WebSocket passam os dois.

1. Pegue um token. Digite seu e-mail no formulário de cadastro; o token é mostrado na página, e nenhum e-mail de confirmação é enviado.
2. Salve o token. localhostly login <token> o guarda em ~/.localhostly/config.json, legível só pelo seu usuário.
3. Abra o túnel. npx localhostly 3000, ou localhostly 3000 depois de instalar com npm i -g localhostly. A primeira linha é a URL pública; abaixo dela, uma linha por requisição com hora, método, caminho, status e milissegundos.

O seu app recebe o método, o caminho, os cabeçalhos e o corpo do visitante, mais X-Forwarded-For, X-Forwarded-Proto: https e X-Forwarded-Host; --host meuapp.test:3000 aponta o túnel para outro endereço e manda esse Host. O nome são 3 palavras em inglês sorteadas, adjetivo, cor e animal, e ninguém o escolhe.

A URL que você recebe no início é a URL até o Ctrl+C

O nome é sorteado uma vez, quando o agente conecta, e a URL escrita na primeira linha é onde toda requisição seguinte chega, enquanto a conexão durar. O servidor pinga o agente a cada 30 segundos e fecha a conexão depois de 60 segundos sem resposta; numa medição, um túnel ocioso por 620 segundos ficou de pé. É o Ctrl+C que o fecha.

Quando a conexão cai no caminho, o agente reconecta sozinho, esperando 1 segundo e dobrando até 60, e pede o nome dele de volta; o servidor o guarda para ele por 10 minutos, então a URL volta a responder sem nada mudar do lado do visitante. Depois de uma queda mais longa o agente volta com um nome novo e escreve name changed.

Webhooks e clientes de API não recebem página de aviso

A primeira visita de um navegador mostra uma página de aviso que diz que o site é servido do computador de alguém; o botão dela grava um cookie que a afasta por 24 horas. Uma entrega de webhook, uma chamada de curl ou qualquer outro cliente de API não é um navegador, então nunca vê essa página: a requisição vai direto ao seu app, e um cliente que não consegue clicar manda o cabeçalho X-Localhostly-Skip-Warning no lugar.

Cadastre https://<nome>.localhostly.iblabs.io/<seu caminho> no provedor do webhook; cada entrega escreve uma linha no seu terminal com método, caminho, status e tempo, e a entrega que chega com o seu app parado recebe uma página 502 que diz isso.

Respostas em stream e uploads grandes passam

Os corpos andam em pedaços de até 64 KiB, nos dois sentidos, então nenhuma requisição fica inteira na memória; na medição, um upload de 20 MiB cruzou o túnel com o pico de memória abaixo de 100 MiB, e um download de 20 MiB chegou a um visitante lento pedaço a pedaço.

Uma resposta que o seu app escreve ao longo do tempo chega ao visitante conforme é escrita: Server-Sent Events mandados em 0, 3 e 6 segundos chegaram em 0,6, 3,6 e 6,6 segundos num stream medido. O único relógio é o do primeiro byte, 60 segundos; depois dele, um download leva o tempo que levar. O WebSocket do visitante é entregue ao seu app, e o upgrade completa quando o seu app o aceita com o subprotocolo que escolheu.

Tranque o túnel com senha ou lista de IPs

--password põe uma caixa de login na frente de todo visitante; deixe o valor vazio e o localhostly cria uma senha de 12 caracteres e a escreve só no seu terminal. O cabeçalho Authorization que o visitante digita nunca chega ao seu app.

--allow 203.0.113.7,10.0.0.0/8 admite esses endereços IP ou faixas e mais ninguém, IPv4 ou IPv6, até 64 entradas: qualquer outro endereço recebe uma página 403 que mostra o endereço que o servidor viu, e o upgrade de WebSocket dele também recebe 403. Um túnel com --allow pula a página de aviso, e com --password por cima o visitante precisa do endereço e da senha.

• A linha de registro do servidor por visita guarda método, caminho sem a query, status, tempo, nome do túnel e conta, nunca um corpo nem um cookie.
• Do nosso lado o seu token existe só como o hash SHA-256 dele.
• O HTTPS termina no balanceador do localhostly: o servidor vê e repassa o seu tráfego, o que não é criptografia de ponta a ponta.

Deixe o túnel como serviço do sistema

localhostly service install 3000 faz do túnel um serviço do sistema: systemd no Linux, launchd no macOS, serviço do Windows. O serviço reconecta por conta própria, guarda o nome que recebeu, o pede de novo depois de reiniciar e continua tentando se o servidor o recusar; localhostly service status diz se ele está rodando e localhostly service uninstall o remove.

Instalar

O localhostly roda no Node.js 24 ou mais novo.

• Teste sem instalar: npx localhostly 3000
• Instale de vez: npm i -g localhostly

As duas linhas rodam o mesmo agente do registro do npm. Salve o token com localhostly login <token>; localhostly 3000 então abre o túnel.