Comprei uma VPS de €14 para programar. Os 200 ms quase me fizeram desistir.

TL;DR: aluguei uma VPS com 8 vCPU e 24 GB de RAM por €14/mês pensando em desenvolvimento e self-hosting, mas os ~200 ms de latência tornaram o trabalho via SSH bem desagradável. T3 Code + Tailscale mudaram a dinâmica: hoje o código e os agentes ficam rodando na VPS, enquanto eu acesso as mesmas sessões pelo Windows, Linux ou celular. Com o tempo, a mesma máquina acabou concentrando meus ambientes pessoal, profissional e de produção, cada um separado, e boa parte dessa infraestrutura passou a ser versionada e reproduzível.

Já fazia algum tempo que eu tinha vontade de centralizar melhor meu ambiente de desenvolvimento. Queria uma máquina que pudesse ficar ligada 24 horas, que eu conseguisse acessar de qualquer lugar e onde também pudesse hospedar meu projeto pessoal. Quando encontrei uma VPS com 8 vCPU, 24 GB de RAM, 300 GB de SSD e porta de 600 Mbit/s por €14 por mês, resolvi experimentar. Convertendo, fica na faixa dos R$ 80 e poucos, e para mim a quantidade de recursos pelo preço parecia boa o suficiente para justificar o teste.

Não vou entrar no provedor porque a ideia aqui não é fazer um review de hospedagem. Eu sabia que, pela localização do servidor, teria uma latência considerável, provavelmente próxima dos 200 ms, mas nunca tinha tentado usar uma máquina assim como ambiente de desenvolvimento de verdade. Uma coisa é olhar um ping e saber teoricamente que aquilo vai incomodar; outra é passar algumas horas trabalhando e descobrir quanto esse pequeno atraso aparece no dia a dia.

SSH com 200 ms funciona, mas eu não queria trabalhar o dia inteiro assim

Para manutenção pontual, SSH continua sendo completamente utilizável para mim. Se preciso entrar na máquina, olhar um log, executar alguns comandos, verificar um serviço ou resolver alguma coisa rapidamente, aqueles 200 ms não são um problema relevante.

A experiência muda quando esse mesmo acesso vira o lugar onde você pretende passar várias horas desenvolvendo. Testei terminal, VS Code remoto e algumas formas diferentes de trabalhar via SSH. Tecnicamente tudo funcionava, mas eu sentia aquele pequeno atraso em praticamente toda interação: digitar, navegar, executar comandos e esperar a resposta da interface. Não era impossível programar daquela forma, eu só percebi rapidamente que não queria fazer isso todos os dias.

Nesse ponto comecei a aceitar que a VPS talvez continuasse sendo ótima para hospedar serviços e aplicações, mas que o desenvolvimento provavelmente ficaria local. Foi aí que me lembrei de uma ferramenta que eu já tinha visto algumas vezes nos vídeos do Theo: o T3 Code.

Eu já conhecia o T3 Code, só ainda não tinha encontrado um problema para ele resolver

Eu acompanho bastante o conteúdo do Theo e já tinha visto ele utilizando o T3 Code, principalmente naquele cenário de ter várias máquinas, projetos e sessões acontecendo ao mesmo tempo. Sempre achei interessante, mas até então não enxergava muito bem onde aquilo se encaixaria no meu fluxo. Se eu já podia abrir um terminal e rodar Claude Code, Codex ou qualquer outra CLI, adicionar uma interface no meio parecia mais uma camada que eu não precisava.

Quando comecei a enfrentar a latência da VPS no uso diário, finalmente entendi onde o T3 Code poderia fazer sentido para mim. Eu não precisava de um terminal diferente; precisava parar de tentar utilizar uma máquina a milhares de quilômetros como se ela estivesse embaixo da minha mesa.

No meu uso, o T3 Code virou uma interface para as sessões e agentes que estão rodando na própria VPS. O backend continua lá, usando tmux, enquanto eu posso acessar e interagir com ele pelo dispositivo que estiver utilizando naquele momento. O código, o Git, as ferramentas e o agente ficam próximos uns dos outros dentro da VPS, enquanto meu computador passa a ser principalmente a interface para dizer o que quero fazer e acompanhar o resultado.

De forma bastante simplificada, antes eu estava tentando trabalhar mais ou menos assim:

Meu computador
      |
   ~200 ms
      |
     SSH
      |
editor / terminal
      |
     VPS

Hoje a experiência está mais próxima disto:

Windows / Linux / celular
          |
      Tailscale
          |
       T3 Code
          |
        tmux
          |
   Codex / agente
          |
 código e ferramentas
       na VPS

A VPS continua fisicamente distante e a latência obviamente continua existindo. O que mudou foi a necessidade de sentir essa latência em cada pequena interação, porque boa parte do trabalho agora acontece do lado da própria VPS.

A máquina continua trabalhando mesmo quando eu fecho o computador

Esse foi o ponto em que a experiência começou a ficar realmente interessante para mim. Se mando uma tarefa para um agente e ela demora alguns minutos, não existe motivo para eu ficar com o terminal aberto olhando o processo acontecer. Posso fechar o computador, fazer outra coisa e voltar mais tarde, porque a sessão não depende da máquina que estou usando para acessá-la.

Também posso começar algo no Windows, depois abrir pelo Linux ou pegar o celular apenas para conferir o resultado e responder alguma pergunta do agente. Como o estado da sessão está no backend, trocar de dispositivo deixa de significar trocar de ambiente de desenvolvimento.

Isso combina bastante com a forma como meu desenvolvimento já vinha mudando por causa dos agentes de IA. Boa parte do meu trabalho hoje começa com um problema, passa por investigação e planejamento, depois vem implementação, testes e revisão. Eu ainda estou acompanhando e tomando as decisões, mas não preciso mais estar fisicamente preso ao terminal durante todo o processo.

Com o tempo, meu computador local deixou de ser necessariamente o lugar onde está o meu desenvolvimento. Ele passou a ser uma das interfaces pelas quais eu acesso um ambiente que continua existindo independentemente dele.

Tailscale e a separação dos ambientes

O Tailscale é outra peça importante dessa experiência. Hoje tenho meu Windows, meu Linux e meu celular conectados, enquanto na VPS mantenho contextos separados para uso pessoal, trabalho e administração. Fisicamente é a mesma máquina, mas esses ambientes aparecem separadamente para mim e cada um possui seu próprio backend do T3 Code, seus projetos e suas ferramentas.

A organização atual fica aproximadamente assim:

                 Meus dispositivos
             Windows / Linux / celular
                       |
                   Tailscale
                       |
          +------------+------------+
          |            |            |
       pessoal      trabalho       admin
          |            |            |
       T3 Code       T3 Code      T3 Code
          |            |            |
    meus projetos    trabalho    administração
                                  da VPS

No ambiente pessoal ficam meus próprios projetos. É onde desenvolvo o Bulletflow, que é uma aplicação minha, além do dev-workspace, onde fui centralizando boa parte da configuração, dos patches e da automação desse ambiente. Também mantenho uma frente separada para as operações relacionadas à produção do Bulletflow.

O ambiente de trabalho fica separado e utiliza somente as ferramentas e credenciais relacionadas ao meu emprego. A empresa disponibiliza Claude Code para desenvolvimento, então naquele contexto eu mantenho esse fluxo isolado do meu ambiente pessoal. Já a parte administrativa da VPS fica em outro espaço, utilizado quando realmente preciso realizar alguma operação privilegiada na máquina.

Essa divisão não existia assim quando comecei. Ela apareceu aos poucos, conforme fui percebendo que estava colocando responsabilidades diferentes demais dentro do mesmo lugar e que separar os contextos tornava o ambiente mais previsível.

No fim, consegui juntar desenvolvimento pessoal, trabalho e produção na mesma infraestrutura

Quando comecei essa experiência eu já tinha algumas ideias soltas. Queria desenvolver meus projetos de qualquer lugar, queria uma máquina para hospedar minha aplicação e imaginava que seria interessante levar também meu ambiente de trabalho para esse mesmo modelo remoto. Eu ainda não sabia exatamente como essas peças iriam se encaixar, mas hoje a mesma infraestrutura acaba cobrindo esses três casos.

Tenho meu ambiente pessoal de desenvolvimento, meu ambiente profissional e a produção do Bulletflow rodando na mesma VPS, cada um com suas próprias responsabilidades e níveis de acesso. Os usuários que utilizo normalmente para desenvolvimento ficam sem sudo, e onde faz sentido utilizo Docker rootless. A administração privilegiada continua em um contexto separado, justamente para evitar que uma experiência ou erro dentro de um projeto tenha liberdade desnecessária sobre o restante da máquina.

A parte de produção também foi ganhando sua própria estrutura com o tempo. Tenho containers, deploy automatizado e backups, porque a partir do momento em que meu próprio projeto começou a depender daquela máquina, ela deixou de ser apenas um laboratório. Passei a me preocupar não somente em fazer as coisas funcionarem, mas também em conseguir recuperar o ambiente caso alguma coisa desse errado.

Boa parte dessa configuração acabou indo para Git. Hoje tenho scripts que ajudam a reconstruir o ambiente em outra máquina caso eu precise fazer isso no futuro. Ainda existem partes manuais, claro, mas é bem diferente de depender de uma sequência de comandos que executei meses atrás e que só existe na minha memória.

Ser open source acabou sendo mais importante do que eu esperava

Outro aspecto do T3 Code que passei a valorizar bastante foi ele ser open source. Quando comecei a utilizar a ferramenta com mais frequência, naturalmente apareceram algumas coisas que eu preferia que funcionassem de outro jeito. Alguns casos pareciam bugs ou comportamentos que poderiam ser úteis para outras pessoas, então cheguei a comentar ou abrir issues no projeto. Outros são simplesmente preferências minhas e não faria sentido esperar que o projeto oficial mudasse por causa delas.

Nesses casos eu consigo manter meus próprios patches, continuar acompanhando as atualizações do projeto e ajustar aquilo que realmente faz diferença no meu fluxo. Isso mudou um pouco a maneira como passei a enxergar ferramentas open source: quando algo resolve quase todo o meu problema, os últimos detalhes que me incomodam não precisam necessariamente ser limitações permanentes.

Essa mesma ideia acabou aparecendo em outras partes do ambiente. Também utilizo um gateway para os modelos de IA e, em alguns momentos, precisei ajustar pequenas incompatibilidades entre CLIs, APIs e alguns modelos que estava testando. Não são modificações particularmente revolucionárias; são principalmente aqueles pequenos problemas que só começam a aparecer quando uma ferramenta deixa de ser uma curiosidade e vira parte do seu uso diário.

A combinação de open source com agentes de IA deixou esse tipo de customização muito mais acessível para mim. Se encontro um comportamento estranho, posso usar o próprio agente para investigar o projeto, entender onde aquilo acontece, propor uma alteração, testar e depois decidir se faz sentido manter a mudança apenas para mim ou contribuir com o projeto original. Parte do ambiente que uso para desenvolver com IA acabou sendo construída e continua sendo mantida com ajuda da própria IA.

Mas isso não precisa acontecer em uma VPS

Apesar de toda essa história ter começado em uma VPS, não acho que todo mundo precise sair alugando um servidor para trabalhar dessa forma. Um mini PC em casa poderia cumprir um papel muito parecido, assim como um desktop antigo ou até um notebook parado. Se a máquina estiver ligada, tiver uma conexão suficientemente estável e recursos para rodar Git, containers e as CLIs que você utiliza, boa parte desse modelo continua funcionando.

No meu caso a VPS fez sentido porque eu queria disponibilidade 24 horas, boa conectividade e uma quantidade razoável de CPU e RAM por um preço que considerei interessante. Além disso, eu já pretendia hospedar minha aplicação, então juntar desenvolvimento e infraestrutura na mesma máquina, mantendo as devidas separações, acabou sendo conveniente.

Também é importante notar que a VPS não está executando localmente os grandes modelos que uso para programar. As chamadas continuam indo para serviços externos, então a máquina precisa principalmente executar meu código, containers, Git, testes e as ferramentas que conversam com esses modelos. Dependendo do tipo de projeto, isso torna o requisito de hardware bem mais modesto do que alguém poderia imaginar quando ouve falar em um “servidor para trabalhar com IA”.

Para mim, a descoberta mais interessante foi perceber que a máquina onde o desenvolvimento acontece não precisa mais ser necessariamente a mesma máquina que está na minha frente. O dispositivo que estou usando pode mudar sem que o ambiente de trabalho precise mudar junto.

Comecei querendo uma coisa bem menor

Quando aluguei a VPS não existia um grande plano de arquitetura. Eu queria uma máquina com bastante recurso por um preço razoável, queria colocar meu projeto no ar e queria descobrir se seria viável desenvolver remotamente nela. A primeira experiência via SSH quase me fez abandonar essa última parte, mas o T3 Code acabou encaixando muito bem no problema que eu tinha encontrado.

A partir daí o ambiente foi crescendo conforme novas necessidades apareciam. O Tailscale facilitou o acesso pelos diferentes dispositivos, os ambientes foram separados quando comecei a misturar responsabilidades demais, a configuração passou a ser versionada quando percebi que não queria reconstruir tudo manualmente no futuro e a produção ganhou mais isolamento quando meu próprio projeto começou a depender da máquina.

O resultado ficou bem maior do que eu imaginava no começo, mas o uso diário curiosamente ficou mais simples. Hoje eu abro o T3 Code, escolho o ambiente e o projeto em que quero trabalhar, encontro minhas sessões e continuo de onde parei. Se eu fechar o notebook, nada deixa de existir por causa disso, porque o ambiente continua rodando do outro lado.

Quando comecei, eu achava que estava simplesmente alugando um servidor com bastante recurso por um preço interessante. Ao longo do processo, aquela máquina acabou se tornando um ambiente de desenvolvimento que continua disponível independentemente do computador ou celular que estou utilizando para acessá-lo, e essa acabou sendo uma das partes que mais gostei da experiência.

No próximo post quero entrar na outra metade dessa história: como meu jeito de programar com IA foi mudando desde aquele fluxo de mandar arquivos para um chat, discutir uma solução e copiar o resultado de volta para o editor, até chegar num processo em que passo muito mais tempo especificando problemas, revisando resultados, criando testes e melhorando o próprio ambiente em que os agentes trabalham.