Mosh SSH: feche o notebook sem perder o trabalho

Por que isso importa

Um build demorado, um servidor de desenvolvimento e um agente de programação têm algo em comum: podem continuar trabalhando enquanto você faz outra coisa. Quando tudo depende do notebook aberto, sair da mesa vira uma decisão sobre quais processos você aceita interromper. A proposta discutida no Syntax é colocar esse trabalho em outra máquina, inclusive um computador que você já tem em casa.

O que me interessa nessa arquitetura é poder retomar uma tarefa sem reconstruir o ambiente a cada troca de dispositivo. Mas eu avaliaria a solução pela recuperação de falhas: consigo voltar depois que a conexão cai? Consigo entender o que terminou? Sei o que fazer se o servidor reiniciar? A demonstração fica muito mais útil quando essas perguntas entram no teste.

O roteiro abaixo acrescenta esse critério ao episódio: começar com um projeto, separar as responsabilidades das ferramentas e provocar pequenas falhas antes de depender do ambiente para uma entrega.

Pontos principais

• 02:19 Fechar o notebook passa a ser possível porque o processamento acontece em outra máquina. A autonomia depende de manter o computador remoto ligado, conectado e disponível.
• 07:50 Scott organiza o fluxo com pastas de projetos, portas distintas e domínios. Esse inventário merece atenção: sem ele, a confusão das abas apenas muda de endereço.
• 10:02 Mosh melhora a experiência de terminal quando o cliente dorme ou troca de rede. Ele atende à conexão interativa; outras partes do ambiente continuam usando SSH.
• 10:36 Caddy recebe as requisições e encaminha cada endereço para a aplicação correspondente. Isso permite acessar projetos por nomes reconhecíveis e centralizar o HTTPS.
• 12:18 Tailscale conecta os dispositivos, enquanto nomes curtos facilitam o acesso. No arranjo apresentado, os projetos ficam acessíveis pela rede privada, chamada de tailnet.
• 15:05 A conversa compara alternativas como Portless e Cloudflare. A escolha útil depende de qual trabalho precisa ser resolvido: endereçamento, acesso privado ou exposição de uma aplicação para terceiros.
• 19:28 Zed mantém o editor local e acessa o projeto remoto por SSH. O próprio episódio esclarece que Mosh é usado nos terminais, separadamente dessa conexão do editor.
• 21:41 tmux e Herdr mantêm sessões às quais é possível se reconectar. O diferencial destacado do Herdr é mostrar o estado dos agentes, reduzindo a necessidade de visitar cada terminal.
• 28:47 Termius permite acompanhar as sessões pelo celular. As dificuldades com toque e atalhos mostram que conseguir acessar o terminal ainda deixa espaço para melhorar a operação.
• 32:32 Testar pelo navegador remoto introduz dúvidas sobre visibilidade e autenticação. O episódio levanta o problema, mas não apresenta uma solução completa para os logins.
• 38:38 Worktrees aparecem como opção para trabalhos paralelos e implementações alternativas. Para uma única tarefa, os apresentadores ainda encontram utilidade em uma branch convencional.
• 44:19 Um computador próprio e uma máquina alugada são opções viáveis. A qualidade da conexão e o esforço de manutenção entram nessa escolha junto com o preço.

Como aplicar

Mosh SSH: comece separando as responsabilidades

A combinação faz mais sentido quando cada peça tem uma função definida. Tailscale fornece o caminho privado até o servidor. SSH permite entrar nele e atende ao editor. Mosh torna o terminal mais tolerante às interrupções de rede. tmux ou Herdr preservam o ambiente de trabalho quando você se desconecta. Caddy organiza o acesso às aplicações web.

Eu começaria com um computador disponível e um projeto de baixo risco. Anotaria pasta, porta, comando de inicialização e endereço de acesso em um pequeno arquivo operacional. Também definiria como parar o processo: conseguir iniciar dez agentes é menos interessante quando ninguém sabe encerrar o que ficou sobrando.

Monte primeiro uma sessão que você consegue recuperar

Instale Tailscale no servidor e no notebook, habilite a resolução de nomes e confirme que o acesso SSH funciona pelo endereço privado. Para este primeiro teste, basta o serviço SSH habitual passando pela rede Tailscale; o recurso específico chamado Tailscale SSH é uma decisão adicional.

Com Mosh instalado nas duas pontas e tmux no servidor, substitua o usuário e o nome da máquina nos comandos:

mosh dev@devbox
tmux new-session -A -s projeto

O primeiro comando abre a conexão. O segundo cria a sessão projeto ou se conecta à existente. Inicie nela uma tarefa observável, como o servidor de desenvolvimento ou um build com saída em log. Para sair preservando a sessão, use Ctrl+b e depois d; ao retornar, execute novamente o comando do tmux. Esse comportamento está descrito no manual do tmux.

Mosh inicia a autenticação por SSH e depois usa UDP. Se o login funciona, mas a tela fica esperando resposta, confira o firewall e as regras da tailnet para o tráfego necessário. A instalação deve existir no cliente e no servidor. A documentação do Mosh explica esses requisitos e a faixa padrão de portas UDP.

Provoque as falhas que realmente podem acontecer

Antes de migrar outros projetos, registre o resultado destes testes:

| Teste | O que verificar | | --- | --- | | Fechar e reabrir o notebook | A tarefa continuou e o terminal voltou? | | Trocar de Wi-Fi para outra conexão | Foi possível retomar sem reiniciar o trabalho? | | Encerrar o aplicativo de terminal | Uma nova conexão recuperou a sessão do tmux? | | Reiniciar o servidor deliberadamente | Você conseguiu reconstruir os serviços e identificar o trabalho interrompido? |

O último teste exige outro tipo de recuperação. Uma sessão persistente não preserva processos através de um reboot. Guarde os comandos necessários para reconstruir o ambiente e configure inicialização automática para os serviços que precisam voltar sozinhos. Para tarefas longas, procure também checkpoints ou resultados intermediários que evitem começar do zero.

Resolva o HTTPS com um caminho explícito

Para o primeiro projeto, eu usaria o nome completo .ts.net da máquina. Habilite os certificados HTTPS na tailnet e siga a integração oficial: Caddy pode buscar o certificado no daemon local do Tailscale, com a permissão adequada para o usuário que executa o serviço. Veja a integração entre Caddy e Tailscale.

Depois disso, configure o proxy para a porta da aplicação. Mantenha o acesso restrito à tailnet pelas regras de rede e pelo firewall. Ter um certificado válido resolve a identidade HTTPS; quem consegue chegar ao serviço continua sendo uma configuração separada.

Se preferir nomes internos com a autoridade certificadora local do Caddy, os dispositivos clientes precisarão confiar nessa autoridade. O certificado confiável no servidor não fica automaticamente confiável no celular. Essa diferença está na documentação de HTTPS automático do Caddy.

Use o celular para acompanhar e decida com números

Eu reservaria o celular para consultar logs, identificar bloqueios e interromper uma tarefa. Revisão de alterações extensas ficaria para uma tela em que eu consiga avaliar o contexto. Para automação de navegador, começaria com um perfil separado e uma conta de teste, documentando como autenticar novamente quando a sessão expirar.

Durante uma semana, anotaria tempo de reconexão, minutos gastos refazendo sessões e interrupções do servidor. Na comparação de custos, incluiria energia, hardware, backup e manutenção, além das assinaturas. O plano pessoal do Tailscale é gratuito para uso não comercial; uma equipe precisa conferir o enquadramento adequado.

Também separaria o custo do computador do custo dos modelos: executar um agente nessa máquina não significa executar a inferência localmente. Meu critério para ampliar o arranjo seria conseguir interromper o acesso, voltar ao trabalho e explicar o estado de cada tarefa sem investigação demorada.