Self-hosting começa quando a pergunta deixa de ser “posso hospedar?” e passa a ser “o que deve ficar junto?”
Self-hosting costuma ser apresentado como uma escolha binária: ou você entrega tudo para uma plataforma gerenciada, ou assume cada detalhe da operação.
Eu aprendi que a pergunta mais importante vem antes: quais serviços realmente precisam compartilhar recursos, quais merecem isolamento e quais podem falhar sem arrastar o restante do ambiente?
No meu caso, a infraestrutura reúne portfólio, automações, dados, cache e servidores de Minecraft. Não trato tudo como a mesma carga. Cada grupo tem um ciclo de vida, uma prioridade e uma forma diferente de ser exposto na internet.
A lógica é simples: entender o problema, tomar uma decisão, operar com disciplina e reconhecer os limites antes que eles virem surpresa.
Meu contexto: portfólio, automação e servidores de Minecraft
Eu uso n8n para automações, PostgreSQL como banco de dados e Redis somente para cache. Também mantenho servidores de Minecraft.
No Dokploy, organizo esses ambientes em projetos diferentes. O projeto Portfólio reúne aplicações e serviços relacionados ao meu trabalho. O projeto jogar concentra os componentes ligados aos servidores de Minecraft.
Essa separação não transforma automaticamente uma infraestrutura em um ambiente isolado. Se os projetos compartilham o mesmo host, CPU, memória, armazenamento ou rede, ainda existe uma dependência física comum. Mesmo assim, separar responsabilidades deixa a operação mais clara.
Quando uma aplicação web muda, eu sei qual grupo devo investigar. Quando um servidor de jogo consome recursos, a investigação começa em outro lugar. Quando preciso reiniciar algo, consigo pensar primeiro no impacto daquele projeto, e não em uma pilha indistinta de serviços.
Por que portfólio e Minecraft não são a mesma carga
Aplicações web normalmente precisam de exposição controlada, atualização cuidadosa, certificados, autenticação e proteção dos dados.
Servidores de Minecraft têm outro comportamento. São processos persistentes, dependem do protocolo específico do jogo e podem ter picos de uso diferentes dos de uma API ou de um site.
Eu posso até manter essas cargas na mesma infraestrutura física, mas não devo tratá-las como se fossem iguais. A separação por projetos é uma fronteira operacional. Ela ajuda a organizar atualizações, recursos, domínios e responsabilidades.
O ponto importante é não confundir organização com isolamento total. Para obter isolamento real, ainda é preciso definir limites de recursos, redes, permissões e políticas de segurança.
O papel de cada peça
Docker: empacotar sem fingir que a operação desapareceu
Docker me ajuda a transformar serviços em unidades previsíveis de execução. Com Compose, consigo descrever aplicações, dependências, redes, volumes e parâmetros de inicialização em uma estrutura que pode ser revisada e reproduzida.
Isso reduz a distância entre “o que deveria estar rodando” e “o que está rodando”. Também facilita separar grupos de serviços por projeto.
Mas container não é máquina virtual e não é backup. Docker não resolve sozinho contenção de CPU e memória, persistência correta, exposição acidental de portas, atualização de imagens, rotação de logs, restauração ou segurança do host.
Eu uso Docker porque a padronização do empacotamento compensa a camada adicional de operação. Não trato Docker como sinônimo de segurança.
n8n: automação com responsabilidade sobre o estado
O n8n entra como ferramenta de automação. O ganho não está apenas em desenhar fluxos, mas em poder operar esses fluxos dentro de uma infraestrutura que eu controlo.
Automação não é só interface e execução. Existem credenciais, histórico, estados e tarefas pendentes. Por isso, a escolha do banco de dados importa.
Eu uso n8n com PostgreSQL por causa da consistência, velocidade e escalabilidade dos dados. Para mim, o banco não é um detalhe invisível da automação: ele faz parte do sistema.
Se um fluxo é importante, também preciso saber como suas falhas serão observadas, como as credenciais serão protegidas e como uma execução poderá ser reprocessada.
PostgreSQL: o dado precisa de um lugar consistente
A escolha do PostgreSQL com n8n veio de uma necessidade prática: tratar os dados de execução com consistência e permitir que eles cresçam sem depender de um armazenamento improvisado.
Um banco relacional não garante velocidade por mágica. A vantagem aparece quando o sistema precisa preservar integridade, consultar histórico e manter relações entre dados.
O trade-off também é claro: PostgreSQL exige atenção a armazenamento, permissões, atualizações, retenção, backup e restauração. Mesmo rodando em container, continua sendo um banco que precisa ser operado.
Redis: cache, não fonte da verdade
No meu ambiente, Redis é usado somente para cache.
Essa fronteira é importante. Cache pode acelerar leituras e reduzir trabalho repetido, mas não deve virar silenciosamente o único lugar onde existe um estado essencial.
A pergunta que faço é: o que acontece se esse dado desaparecer ou ficar desatualizado? Se puder ser reconstruído, o uso como cache faz sentido. Se a perda quebrar uma parte essencial da operação, o dado precisa de outra estratégia de persistência.
Dokploy: uma camada de administração
O Dokploy organiza projetos, aplicações e composes. Isso me dá uma visão mais clara do que está implantado e reduz parte do trabalho manual de deployment e administração.
Mas um painel não substitui entendimento. Eu ainda preciso saber como funcionam os composes, volumes, redes, domínios e dependências por trás da interface.
O painel facilita a operação. A responsabilidade continua sendo de quem conhece o que está por trás dele.
DNS: a camada pequena que define o caminho
Uma das coisas que aprendi foi que DNS configurável não é detalhe cosmético. DNS define como os nomes chegam aos serviços, como mudanças de destino são propagadas e quanto controle existe sobre diferentes ambientes.
Mais flexibilidade ajuda a organizar subdomínios, separar aplicações e mudar destinos sem reconfigurar cada cliente. Também aumenta a chance de erro com TTLs, registros conflitantes, proxies, certificados e exposição pública.
Para mim, o DNS faz parte da arquitetura. Não é apenas o lugar onde coloco um registro e esqueço.
Distribuir recursos é mais importante do que empilhar ferramentas
O principal aprendizado não foi simplesmente “hospedar meus próprios serviços”. Foi aprender a isolar e distribuir melhor os recursos.
O host é finito. CPU, memória, armazenamento e atenção operacional precisam ser divididos entre cargas diferentes.
Na prática, isso significa:
- limitar o que cada serviço pode consumir quando necessário;
- evitar que logs ou volumes de uma aplicação ocupem o armazenamento de todas as outras;
- observar quais serviços têm carga contínua e quais são intermitentes;
- separar componentes públicos de dependências que deveriam ficar em redes internas;
- pensar no impacto de um restart antes de executá-lo;
- registrar decisões para que a operação não dependa somente da memória de uma pessoa.
Organização visual ajuda. Limites reais protegem o restante do ambiente.
Expor menos é uma decisão de arquitetura
Outra parte importante do meu aprendizado foi entender que cada serviço exposto é uma responsabilidade adicional.
Eu uso proxy reverso com Traefik, Nginx ou Caddy para concentrar a entrada HTTP/HTTPS, fazer o roteamento por domínio e organizar certificados.
Também aprendi a configurar certificados de origem no servidor e usar a Cloudflare na frente das aplicações web. Sempre que possível, a comunicação entre serviços e aplicações acontece por redes internas. O domínio público não precisa apontar diretamente para tudo que existe no ambiente.
A regra que sigo é expor somente o que realmente precisa ser exposto. No meu caso, os servidores de Minecraft são a exceção: ficam com domínio sem proxy por causa das exigências do protocolo do jogo.
Para os demais serviços, a pergunta é outra: esta aplicação precisa mesmo ser pública? Qual protocolo ela usa? Por qual camada deve entrar? A resposta define se ela ficará atrás de proxy, certificado, autenticação e controle de acesso — ou apenas em uma rede interna.
Operação: o painel não substitui rotina
Self-hosting cobra atenção. Eu não estou falando de um custo mensal específico, porque não tenho esses números fechados. Estou falando do trabalho de acompanhar atualizações, validar mudanças, investigar falhas e manter um caminho de recuperação.
Uma operação saudável precisa responder perguntas como:
- Como saber que n8n, PostgreSQL, Redis e as aplicações estão funcionando?
- Quais logs são mantidos e por quanto tempo?
- Como uma atualização é revertida?
- Quem recebe o alerta quando uma automação falha?
- Como domínios e certificados são renovados?
- O que pode ser reiniciado sem interromper o restante?
Essas perguntas fazem parte da arquitetura, não de uma etapa opcional depois do deploy.
Backups e segurança não podem ficar implícitos
Backups precisam ser definidos por serviço e por tipo de dado. Um dump do PostgreSQL não substitui necessariamente o backup de volumes de aplicações. Redis, por ser cache, pode ter outra prioridade. Configurações, credenciais, arquivos de Compose e dados de jogos podem exigir estratégias diferentes.
Antes de chamar algo de backup, eu preciso saber:
- o que é copiado;
- para onde vai a cópia;
- com que frequência ela é feita;
- por quanto tempo é mantida;
- se existe uma cópia fora do host principal;
- se a restauração já foi testada.
A mesma lógica vale para segurança: portas públicas, autenticação, permissões de volumes, segredos, atualizações de imagens, acesso ao PostgreSQL e ao Redis e separação entre redes internas e serviços expostos.
Quando essa decisão deixa de fazer sentido
Self-hosting deixa de ser uma boa escolha quando o controle desejado exige mais atenção do que o projeto consegue oferecer.
Docker pode adicionar camadas demais para uma aplicação pequena. Dokploy pode ser desnecessário para quem tem um único serviço. Redis pode ser ruído quando não existe um problema de cache. PostgreSQL pode exigir mais operação do que um projeto simples precisa.
Separar projetos melhora a clareza, mas não cria recursos físicos nem elimina pontos únicos de falha.
A abordagem faz mais sentido quando existem vários serviços, necessidades de automação, dados que merecem consistência, cargas com perfis diferentes e uma razão concreta para controlar recursos, DNS e exposição pública.
O critério não é usar todas as ferramentas. É saber por que cada uma está ali e o que acontece quando ela falha.
Conclusão
Eu vejo minha infraestrutura como uma divisão de responsabilidades: Docker empacota, Dokploy organiza, n8n automatiza, PostgreSQL sustenta os dados e Redis atende ao cache.
O projeto Portfólio concentra aplicações e serviços de trabalho. O projeto jogar concentra a frente ligada aos servidores de Minecraft. Proxy reverso, certificados de origem, Cloudflare e redes internas reduzem a exposição desnecessária. Os servidores de Minecraft ficam como exceção por causa do protocolo que precisam atender.
Isso não é uma receita universal. É a direção que faz sentido para mim enquanto administro cargas diferentes e tento usar melhor os recursos disponíveis.
Self-hosting com critério não é acumular componentes. É entender as decisões, limitar o impacto de cada serviço e continuar sabendo o que está acontecendo quando o painel deixa de mostrar apenas caixas verdes.