
Sessenta contêineres em um servidor
Uma caixa bare-metal executa dezenas a centenas de contêineres Hoody. KSM e BTRFS dedup fazem o custo marginal próximo a zero.
O Slack rejeita. O Drive precisa de pedido de compartilhamento de pasta. O e-mail trava em 25 MB. Dois curls — um no seu notebook, um no dele — movem o arquivo de disco a disco. O pipe roteia os bytes; nada nunca é enviado para um servidor.
GET e PUT no mesmo caminho. O Hoody Pipe segura o lado que conectar primeiro por até cinco minutos; quando o outro aparece, os bytes passam direto. Nada é gravado em disco no servidor.
# from your laptopcurl -T dump.sql \ https://pipe.containers.hoody.com/api/v1/pipe/dump-yesterday[INFO] Waiting for 1 receiver to connect…[INFO] Streaming to 1 receiver…[INFO] Transfer complete.
PUT (ou POST) com body em streaming. O servidor imprime linhas de status conforme o pipe se estabelece — útil como sinal ao vivo de que o outro lado realmente atendeu.
# on their boxcurl \ https://pipe.containers.hoody.com/api/v1/pipe/dump-yesterday \ -o dump.sql# 4.2 GB · saved · done.
GET no mesmo caminho bloqueia até o remetente conectar. Os bytes que o remetente escreve aparecem como o body da resposta — direcione pra um arquivo com -o, ou pro stdin de qualquer programa que leia.
A ordem não importa. Se você roda o curl primeiro, a requisição bloqueia até ele conectar. Se ele roda o curl primeiro, a dele bloqueia. De qualquer jeito, no instante em que os dois lados estão conectados, os bytes começam a se mover.
Do ping no Slack ao arquivo aterrissando no disco dele — os quatro movimentos que o pipe faz acontecer.
“consegue me mandar o dump de prod de ontem?”O arquivo tem 4 GB. O Slack rejeita, o drive compartilhado precisa de ticket de compartilhamento de pasta. Você para de tentar os dois.
curl -T dump.sql …/pipe/dump-yesterdaySeu terminal imprime “Waiting for 1 receiver to connect…” e fica parado. Você cola a URL no chat: “roda isso.”
curl …/pipe/dump-yesterday > dump.sqlO pipe se estabelece no instante em que ele conecta. Os bytes começam a fluir do seu disco pelo pipe até o arquivo no dele.
Transferência completa · 0 bytes no servidorUso de disco no lado servidor permanece zero. O caminho do pipe esquece que a transferência aconteceu no momento em que os dois lados desconectam.
Mesma quantidade de comandos que você digitaria pra um round-trip no Drive — menos o login, menos a barra de upload, menos o link, menos a limpeza.
Hoody Pipe é um intermediário de streaming, não um serviço de arquivos. O arquivo existe no seu disco e no dele. No meio, são só bytes em voo na velocidade que as duas redes sustentarem — o pipe só encaminha.
Caminhos de pipe não exigem autenticação na implantação pública. São URLs endereçáveis com escopo de uma única transferência; quando os dois lados desconectam, o caminho some. Nada pra o destinatário cadastrar.
A transferência nunca pousa no disco do servidor. Nada pra limpar, nada pra vazar, nada pra expirar. Os bytes estão no seu notebook; depois também no dele; o caminho esquece que existiu.
Dois curls. Sem login. Sem barra de upload. Pronto.
“Me manda esse arquivo” já significou uma aba, um login, um upload, um link, um colar, um download. Agora significa: digita curl, cola a URL, roda curl. A versão mais rápida disso que você vai digitar.
A maior parte das ferramentas que usávamos pra mandar um arquivo de 4 GB são sobras de quando não dava pra fazer streaming de bytes entre dois terminais por HTTP. O pipe torna todas elas desnecessárias.
Dois curls. O arquivo está no disco dele. Nada nunca foi enviado.