Hospedagem própria e independência tecnológica: a alegria de construir com as próprias mãos
(ssp.sh)- Enfatiza a experiência e a importância da independência tecnológica e da hospedagem própria
- Explica que a posse do domínio e a operação autônoma de um blog trazem grandes benefícios de longo prazo para a carreira e o crescimento pessoal
- Menciona o valor da comunidade e do aprendizado obtidos ao compartilhar seu conhecimento e código em um ecossistema aberto de código aberto
- Apresenta a montagem de um Homelab e várias ferramentas open source de hospedagem própria, destacando a liberdade sentida ao usá-las de fato e se afastar das limitações dos serviços por assinatura
- Destaca o impacto positivo do compartilhamento de conteúdo baseado em Markdown e do espírito open source no ecossistema de software e no fortalecimento das capacidades individuais
Introdução: o valor da independência tecnológica e de construir por conta própria
- Ao ver um vídeo do PewDiePie sobre instalação do Arch Linux e criação direta de produtos baseados em open source, o autor voltou a refletir sobre a importância da hospedagem própria e da independência tecnológica para criar algo seu
- O domínio, o blog e os serviços que a pessoa administra diretamente tornam-se ativos acumulados no longo prazo, com um significado maior do que simplesmente mudar de plataforma
A força de ter seu próprio domínio e operar seu blog de forma independente
- Para quem vai começar a escrever algo novo ou está pensando em procurar emprego, recomenda primeiro comprar seu próprio domínio e manter um blog
- Como a perda de conteúdo valioso e de domínios se repete a cada mudança de plataforma, é importante possuir o próprio domínio e continuar acumulando conteúdo no mesmo endereço
- Com o tempo, backlinks, posts antigos e o histórico de investimento se conectam à credibilidade de longo prazo
A experiência do autor com hospedagem própria e aprendizado
- O autor hospeda diretamente vários serviços, como blog, segundo cérebro, livro e lista de assinaturas, usando GoHugo, Listmonk, Memberstack e outros
- Vai ampliando gradualmente sua capacidade técnica com montagem de ambiente Homelab, SSH, backups, gerenciamento de fotos, Gitea e automação de proxy/certificados SSL
- Mesmo que no começo pareça difícil, a maior recompensa no processo é o aprendizado e a sensação de realização
O valor do open source e da comunidade
- O uso e a contribuição para software open source tornam possível a independência tecnológica, e o autor também publica seus conhecimentos e ferramentas no GitHub
- No caso do open source, diversas licenças permitem que todos usem livremente, além de ampliar as oportunidades de feedback da comunidade e colaboração
- O autor começou a se encantar pelo ecossistema open source ao usar uma ferramenta de BI open source e, hoje, a maior parte de sua atividade online e de seus textos sobre engenharia de dados se baseia nisso
Linux e Linus Torvalds
- O Linux está no centro dos dispositivos digitais do mundo todo, e o fato de Linus Torvalds não tê-lo comercializado permitiu sua ampla disseminação global
- Torvalds também criou o git, que se tornou uma ferramenta essencial para todos os desenvolvedores de software no mundo
- Ao publicar seu trabalho em open source, é possível obter aprendizado, feedback, contribuições e conexões com outras pessoas, ajudando não só no crescimento individual como também no desenvolvimento da comunidade
Gratidão e ferramentas open source
- Há algumas ferramentas open source que o autor usa com frequência e pelas quais é grato
- Quartz: alternativa open source ao Obsidian Publish
- GoatCounter: ferramenta anonimizada de análise de tráfego de sites
- Listmonk: sistema open source de listas para newsletter
- listmonk-rss: envio automático de e-mails ao escrever no blog
- Exemplos de software open source recomendados para Homelab:
- Paperless: digitalização e gerenciamento de documentos
- PhotoPrism: gerenciamento de fotos com IA e hospedagem própria
- Pi-hole: bloqueio de anúncios em toda a rede
- Nginx Proxy Manager: roteamento de domínio e automação de SSL
- Audiobookshelf: servidor de audiolivros/podcasts
- Calibre: gerenciamento de e-books
- Syncthing: sincronização distribuída de arquivos
- Gitea: serviço próprio de Git leve
Experimentação suficiente mesmo com equipamentos baratos
- Mesmo sem um servidor novo e caro, é possível montar um Homelab suficiente apenas com um servidor cliente usado e um bom sistema operacional
- Valoriza-se a alegria de aprender e a independência adquirida no processo de construir e operar tudo diretamente
Independência tecnológica e risco de plataforma
- Ao construir e hospedar por conta própria, a pessoa se livra de riscos como mudanças de funcionalidade ou encerramento de serviços de grandes plataformas como Google e Apple
- O verdadeiro benefício da independência tecnológica é conquistar a liberdade de projetar e modificar diretamente seu próprio ambiente e suas características
Encerramento e a importância do Markdown
-
Reforça a alegria do open source, da criação própria e do compartilhamento de experiências, destacando também que toda a base de produção de soluções e conteúdo está unificada em Markdown
-
O Markdown garante compatibilidade entre várias plataformas e se tornou uma ferramenta padrão da cultura de open source e compartilhamento de conhecimento
-
Mais blogs sobre engenharia de dados, notas do segundo cérebro e o livro que está sendo escrito publicamente podem ser encontrados em ssp.sh e no GitHub
-
O compartilhamento de experiências e a discussão com leitores são sempre bem-vindos
1 comentários
Comentários do Hacker News
Desculpem pela autopromoção, mas queria comentar sobre a realidade de que, ao fazer self-hosting, não é obrigatório comprar hardware novo. Depois de alguns anos, notebooks antigos que ficaram lentos demais para usar com Windows ainda oferecem desempenho mais do que suficiente como servidores Linux. Há uma boa chance de encontrar um notebook velho encostado em casa ou entre amigos, e eu mesmo uso tranquilamente um notebook i3 de 2011 com duas pessoas, e agora em 2025 ainda não parece haver necessidade de upgrade. Notebooks também são eficientes em consumo de energia em estado de espera, então no longo prazo podem ser uma escolha ainda mais racional que desktops. Acho que notebook é um excelente candidato a primeiro servidor para quem está começando no self-hosting. (Só um detalhe: notebooks já têm UPS embutido, então, se for deixar ligado 24 horas por dia na tomada, recomendo fortemente remover a bateria.)
Texto sobre reutilização de hardware antigo
Confesso que estou escrevendo este texto agora mesmo em um notebook Acer de 13 anos rodando Linux Mint XFCE. Sempre achei um desperdício jogar fora equipamentos antigos, então mesmo depois de comprar um notebook novo, deixei o antigo conectado por HDMI à TV da sala com um teclado/trackpad sem fio Logitech K400+ de US$ 25. Dá para navegar na web, usar YouTube e Netflix sem problemas, às vezes abrir VS Code ou Thunderbird para trabalhar e até rodar jogos indie da Steam com controle sem dificuldade. Se os notebooks da Framework chegassem ao meu país, acho que esse tipo de reaproveitamento aumentaria ainda mais — infelizmente ainda não entregam aqui.
Aqui na minha região (um conjunto de apartamentos na Suécia com 250 unidades), é rotina as pessoas jogarem computadores antigos na área de lixo eletrônico. Eu vasculho isso várias vezes por dia quando passeio com o cachorro, quase como um personagem de Mad Max. Junto peças de várias máquinas, instalo debian, rodo containers Docker e uso para todo tipo de propósito. Já até dei de presente para meus pais, primos e amigos servidores Frankenstein montados assim. É impressionante o quanto de equipamento ainda utilizável as pessoas descartam. Também encontro com certa frequência notebooks sem senha, e ao entrar no Windows estão cheios de fotos de família. Às vezes até aparece um iPhone de uns 5 anos atrás ainda desbloqueado. Não dá para não achar o mundo um lugar estranho.
Também tenho em casa um Mac-Mini de 2012. Ganhei de presente, então nunca pensei em migrar para Mac, e embora não seja potente, ainda tem um desempenho decente. No último Natal liguei a máquina, mas mesmo com o sistema padrão estava lenta demais, e depois de atualizar o macOS ficou praticamente impossível de usar. Segui um vídeo no YouTube, troquei para SSD, instalei Debian e depois CasaOS (um SO/UI de home server baseado na web). Desde então montei um ambiente em que acesso de fora via Wireguard e faço streaming de música com Navidrome. Ainda não entendo muito bem Docker, mas estou aprendendo várias coisas como mapeamento de PATH e afins.
Se você não tiver problema em comprar no mercado de usados, no momento estou montando um nó Proxmox por menos de 2.000 euros com Threadripper de 3ª geração, 32 núcleos/64 threads, 256GB de ram, 2x10G, 2x2.5G, interface dedicada de gerenciamento IPMI 1G e 64 lanes PCIe gen 4.
Em setups abaixo de RAID6/RAIDZ2, existe um risco considerável de perda de dados. A maioria dos notebooks não tem portas SATA/M.2 suficientes para montar uma configuração com paridade, então se você quer tolerância a falhas em nível de RAID, no fim vai precisar de hardware novo. Se você seguir o princípio de distribuir os backups em pelo menos dois locais físicos, o ideal é ter redundância em dobro.
Entendo por que alguém quer fazer self-hosting, mas também entendo perfeitamente por que não quer. Self-hosting dá trabalho: você precisa atualizar Docker, se algo quebrar só você resolve, e mesmo quando funciona bem muitas vezes a sensação é de algo meio improvisado, não exatamente polido. Hoje a lista de ferramentas self-hosted que realmente me poupam tempo e funcionam bem é muito pequena (a primeira é firefly), e em muitos casos eu tentava configurar, quebrava e no fim desistia. Hoje em dia, quando encontro empresas que respeitam privacidade e têm preço razoável, simplesmente pago.
Acho que Docker é a origem do problema. Docker adiciona camadas desnecessárias de indireção em armazenamento, rede etc., e para atualizar por segurança e outras razões muitas vezes você precisa reconstruir o container ou esperar que outra pessoa faça isso. Se possível, vale insistir em serviços que possam ser distribuídos como pacote nativo do sistema operacional upstream ou como binário único (algo comum em projetos baseados em Go), porque isso tende a ser mais fácil de operar no longo prazo.
Fico na dúvida sobre por que seria obrigatório atualizar Docker com tanta frequência. No meu caso, faz mais de um ano que opero sem atualizar o Docker em si. O upgrade das imagens Docker me toma algo como 15 minutos por mês. E a realidade é que empresas que realmente respeitam a privacidade são extremamente raras, além de ser difícil confiar que continuarão mantendo políticas independentes ao longo dos anos.
A situação é tão ruim que é extremamente difícil até encontrar uma empresa que respeite privacidade e tenha preço bom.
Fiquei curioso para saber em quais projetos você teve problema. Na minha experiência, quando o projeto já oferece até Docker Compose, quase tudo funciona sem dor de cabeça. E acho que quase toda empresa eventualmente trai a confiança do usuário. Então a ideia é justamente não dar essa oportunidade. Eu faço self-hosting do Home Assistant, e essa empresa é incomum por ter até mecanismos legais para impedir operar contra os interesses do usuário.
Eu faço self-hosting da maior parte do que preciso, mas recentemente passei por uma crise de verdade quando a internet começou a cair de forma intermitente. Isso me fez perguntar a mim mesmo
No fim, percebi que preciso arquivar mais documentação, e que o NixOS é praticamente inútil offline se você não mantiver seu próprio servidor de cache — e isso é muito inconveniente. O resultado desse desafio foi descobrir que, ao fazer self-hosting da maior parte do que eu preciso para funcionar sem internet, minha produtividade acabou aumentando bastante.
Depois que comecei a hospedar meu próprio
devdocse usar o zeal no Linux (visualizador de documentação offline), resolvi boa parte do problema de documentação offline.devdocs github
página oficial do zealdocs
Sempre que tenho downtime, tento transformar as fraquezas do meu sistema em novas oportunidades. Se for algo inevitável por causa de problemas upstream, paciência; mas quando existe contramedida possível, gosto de montar cenários equilibrando custo e probabilidade, e o próprio processo me diverte.
Eu já levei essa busca pelo offline ao extremo. Os períodos de desconexão total da internet foram justamente os momentos em que minha produtividade bateu recordes. Tenho um alias em bash para salvar sites inteiros recursivamente com wget, baixo os vídeos que quero com yt-dlp, mantenho uma cópia offline completa da Wikipédia com Kiwix, armazeno meus e-mails localmente com suporte a fila de envio offline, salvo páginas individuais com eficiência usando a extensão SingleFile, e também recomendo o Zeal como navegador de documentação open source.
Concordo com o problema de que “NixOS não serve offline sem cache próprio”. Em qualquer software distribuído via gerenciador de pacotes, é essencial ter cache ou backup de repositório. O fato de que o sistema inteiro depende de que todas as pessoas na ponta da árvore de dependências continuem fazendo sua parte é, para mim, o ponto mais inquietante da forma moderna de desenvolver software. Para software de usuário final, prefiro muito mais pacotes individuais com todas as dependências embutidas. Afinal, é isso que acaba sendo armazenado no disco real.
Kiwix (solução offline para Wikipédia) e várias configurações de jellyfin são recursos offline muito fortes. Mas distribuições como NixOS e Gentoo tendem a exigir conectividade contínua com a internet. Espelhar todos os pacotes é praticamente inviável na prática.
Sobre o conselho “compre primeiro um domínio”, na verdade domínio é algo que você aluga; não dá para realmente comprar. Basta um pagamento falhar e você é expulso na hora. A fugacidade dessa identidade online chega a ser triste.
A parte de “domínio é só alugado” é verdade se você usa apenas root zones/registries aprovados pela ICANN, mas eu opero há anos, como experimento, meu próprio registry e uma root zone customizada que não compartilho com terceiros. Também experimentei usar TLDs customizados para embutir sistemas inteiros de classificação global de produtos/serviços em nomes de domínio, e isso me fez sentir na prática o quanto os TLDs da ICANN podem ser ambíguos e inadequados.
Isso é uma limitação meio técnica. Se eu configurar todos os meus dispositivos (ou seja, os consumidores de nomes de domínio) para reconhecer qualquer coisa assinada por uma determinada chave pública como “XorNot.com”, então dá para substituir o sistema. Com mais suporte técnico, acho totalmente possível trocar a estrutura atual inteira por uma “lista confiável de chaves e nomes”.
Estamos vivendo uma fase em que o ecossistema de ferramentas para self-hosting evoluiu muito. Dá para começar com componentes hospedados e ir substituindo cada peça, uma por uma, por alternativas self-hosted. Meu blog também é self-hosted em um servidor em casa.
Na frente uso Cloudflare Tunnel, mas antes já usei nginx+letsencrypt+public_ip, e o armazenamento de dados também pode ser trocado entre Cloudflare R2, S3 ou um NAS local (com FUSE, até o modo de acesso fica igual).
Em compensação, os únicos recursos que realmente precisam ser alugados são domínio (apesar da aparência de compra, é só aluguel) e conexão com a internet; o resto hoje em dia é quase todo opcional. Claro que desligar um serviço traz inconveniência, mas a operação básica continua.
Ficou absurdamente mais fácil do que antes. Nos anos 90 e no começo dos anos 2000, um ambiente de ferramentas assim era inimaginável.
A única desvantagem é que os requisitos anti-spam para e-mail ficaram muito mais rigorosos. Até uns 8 anos atrás eu ainda operava meu próprio e-mail, mas hoje uso G Suite.
Para mim, a questão não é “fazer ou não self-hosting”, mas sim ter a capacidade de fazer self-hosting. É uma visão mais inclusiva: se faltar conhecimento técnico ou se você quiser pagar, pode delegar para outros. Quem pensa “é só pagar” acaba correndo os maiores riscos no longo prazo. Hoje muitos negócios são desenhados para capturar o cliente transformando dependência técnica de longo prazo em refém. Mesmo quem não liga para FOSS deveria reconhecer que a possibilidade de trocar de fornecedor é importantíssima. Quando você fica preso em lock-in, pode ser tratado de forma abusiva a qualquer momento. Há muitas empresas que pensam apenas dentro dessa lógica.
Tenho muita consideração pelo Zulip por ser open source, permitir self-hosting, oferecer serviço em nuvem e também suportar migração nos dois sentidos.
Numa era em que há desenvolvedores de sobra e a qualidade do código gerado por IA em casa varia cada vez mais, self-hosting certamente pode virar tendência.
Mesmo aprendendo só o básico de Linux, muita gente acaba se interessando por self-hosting não porque precise, mas pelo prazer e pela sensação de realização de “rodar o próprio serviço”.
Um efeito ainda maior é eliminar o risco real de ser expulso sem motivo de uma plataforma da qual você depende completamente. Se a pessoa perder até a conta do Gmail, um “usuário comum” pode ficar travado de acessar sua identidade online, reset de senha e até login em aplicativos. Com certeza existe gente no Hacker News cuja vida ficaria complicada se perdesse a conta do Gmail. Por isso, defendo que pelo menos a identidade de e-mail precisa ser sua. E esse princípio deve ser repetido para hospedagem web, AWS, Spotify, Netflix e todos os demais serviços online; “trocar por outro host de nuvem” não resolve o problema.
Instalar um servidor de e-mail é fácil e tem bastante informação disponível, mas pessoalmente sinto falta de material sobre operar isso de verdade por conta própria (especialmente problemas de compatibilidade ou resposta a incidentes). Por exemplo: se o Google colocar meu servidor em blacklist, com quem eu falo? Existe um procedimento para lidar com a mensagem de erro? Na prática, falta onde buscar ajuda. Precisamos de um manual sobre como responder adequadamente a fatores externos irracionais, como blocos globais de IP. O problema não é DKIM, DNS ou o protocolo em si, e sim diretrizes para lidar com outros provedores na operação real do serviço.
O certo é possuir o seu domínio e vinculá-lo ao provedor de e-mail que quiser; se der problema, basta migrar imediatamente para outro. O domínio em si é barato, e a resposta correta é nunca usar o endereço de e-mail proprietário do provedor.
E esse princípio vale tanto se você operar seu próprio servidor de e-mail quanto se usar um serviço comercial. São questões separadas.
O risco é real e claro, mas fico em dúvida se é um risco que realmente afeta muita gente. A maioria dos primeiros usuários do Gmail o adotou porque as alternativas da época eram muito ruins. E-mail de ISP, universidade ou trabalho era do tipo que podia desaparecer a qualquer momento se necessário. Self-hosting pode resolver esse problema “parcialmente”, mas se você não tem capacidade de manter a segurança, nem um servidor de e-mail gerido por você significa controle total. Há muitas coisas para acompanhar, como renovação de domínio, e se você negligenciar isso sua conta também desaparece aqui. Eu entendo por que Gmail e outros poucos grandes provedores são tão populares. Para a maioria das pessoas, no curto e médio prazo, essa ainda é a melhor escolha na prática.
Quando faço self-hosting em casa, sempre me pergunto qual risco é maior: o de um HDD falhar ou o de eu perder minha conta do Gmail. Quando você começa a hospedar por conta própria, de repente precisa se preocupar com espaço para equipamento, estratégia de backup, gestão de atualizações e até introduzir UPS por causa de quedas de energia durante update/backup. No meu caso, já tive um UPS defeituoso que acabou danificando até os discos do NAS. No fim, são tarefas demais e sobra menos tempo para focar na vida cotidiana.
Há quem defenda que self-hosting pode, na verdade, introduzir riscos críticos. Se você perder sua private key local ou o domínio principal do seu e-mail, não há recuperação possível. 2FA e recuperação de conta são muito mais convenientes em serviços externos. Não sou contra self-hosting em si, mas para a maioria das pessoas o caminho bem mais seguro é garantir a possibilidade de recuperação de conta.
Desde o surgimento do instalador oficial do Arch Linux, acho exagero dizer que ainda é difícil. Você ainda entra pelo terminal, mas comparado à época em que precisava quebrar a cabeça com cálculos complicados de blocos de partição, ficou muito mais fácil.
Em casa eu gerencio com Portainer um cluster Kubernetes de 4 nós em Raspberry Pi junto com um mini PC Intel N150.
Entre as ferramentas open source de operação, senti um grande ganho de produtividade com as seguintes (todas rodam em ambiente de containers):