Por que escolhi Ubuntu Server numa VM local (VirtualBox) pra próxima fase

Ainda não configurei a automação técnica desse projeto — isso vem depois do décimo post, por decisão minha, pra validar o conteúdo antes de investir tempo na engenharia por trás. Mas já defini onde ela vai rodar, e quero explicar essa escolha aqui antes de chegar na hora de executar, porque foi uma decisão que exigiu entender algumas coisas que eu não sabia.

A pergunta inicial: onde essa automação vai morar

Automação de conteúdo com IA — gerar textos, publicar em blog e redes sociais de forma programada — precisa rodar em algum lugar que fique ligado, de preferência o tempo todo, sem depender do meu notebook estar aberto. As opções que considerei foram basicamente três: rodar direto no meu sistema operacional (Windows), contratar um servidor na nuvem desde já, ou criar uma máquina virtual no meu próprio computador.

Por que não direto no Windows

A maior parte das ferramentas de automação que pretendo usar (como o n8n, que orquestra os fluxos de geração e publicação) foram pensadas primeiro pra ambientes Linux. Dá pra rodar no Windows via Docker Desktop, mas ambientes Linux nativos costumam ter menos atrito — menos incompatibilidade de biblioteca, menos "funciona diferente aqui". Como eu vou precisar mexer bastante com linha de comando durante o aprendizado, preferi já treinar direto no sistema que a maioria dos tutoriais e documentações realmente usa como referência.

Por que não contratar servidor na nuvem ainda

Essa foi a decisão mais fácil: contratar um servidor pago agora, antes de validar se o fluxo de automação funciona como eu espero, seria gastar dinheiro num teste. Um servidor rodando 24 horas custa por mês, mesmo que eu ainda esteja quebrando a cara aprendendo a configurar. Faz mais sentido errar de graça primeiro.

Por que VirtualBox, especificamente

VirtualBox é gratuito, roda em qualquer sistema operacional (o que significa que essa parte do aprendizado não fica presa a um hardware específico), e tem um recurso que valorizei bastante assim que entendi pra que serve: snapshots. Antes de qualquer mudança arriscada — tipo instalar uma ferramenta nova ou mexer numa configuração que eu não domino ainda — dá pra "salvar o estado atual" da máquina virtual e, se algo quebrar, voltar pra esse ponto em segundos. Isso tira boa parte do medo de testar e errar, que é exatamente o tipo de ambiente que eu preciso agora.

Por que Ubuntu Server, e não uma versão com interface gráfica

A versão "Server" do Ubuntu não tem interface visual — só terminal. Pode parecer mais difícil pra quem nunca usou, e de fato é uma curva de aprendizado a mais. Mas é também o padrão real usado em ambientes de produção profissionais: a maioria dos servidores que rodam automações de verdade no mercado são configurados assim, sem tela, só comando. Se meu objetivo é aprender isso de verdade — inclusive pra eventualmente oferecer como serviço —, faz mais sentido treinar direto no formato que vou usar depois pra valer, em vez de aprender um atalho visual que não existe fora do ambiente de testes.

O que isso significa na prática

Configurei a VM com recursos modestos — o suficiente pra rodar Docker e as ferramentas de automação sem travar, mas nada exagerado. A ideia é usar essa máquina local enquanto ainda estou testando e ajustando o fluxo, e só migrar pra um servidor na nuvem quando o processo já estiver validado e eu quiser deixar rodando de forma permanente, sem depender do meu computador ligado.

Próximo passo

No próximo post, viro pra outro assunto que também precisei mapear antes de automatizar qualquer coisa nas redes sociais: a diferença entre usar as APIs oficiais de cada plataforma e usar ferramentas de terceiros que prometem simplificar esse processo — e por que decidi seguir o caminho mais trabalhoso.

Se você já mexeu com VirtualBox ou outra ferramenta de virtualização, deixa nos comentários: teve algum obstáculo específico na configuração que valeria eu documentar aqui quando chegar a hora de instalar tudo?