A melhor stack de privacidade auto-hospedada em cinco camadas

Em março de 2025, o Krebs on Security relatou que investigadores federais dos EUA tinham ligado diretamente um roubo de US$ 150 milhões em criptomoedas à violação do LastPass em 2022. O mecanismo era simples: alguns clientes armazenaram frases-semente nas Secure Notes do LastPass, atacantes obtiveram backups criptografados dos cofres, e proteções de cofre fracas ou antigas permitiram que parte do conteúdo dos cofres fosse quebrada offline.

A lição não é que o LastPass foi excepcionalmente descuidado. A lição é que toda violação sobre a qual você lê é o dado de outra pessoa sendo monetizado enquanto o e-mail de desculpas fica na sua caixa de entrada. A auto-hospedagem muda quem pode fazer isso com os seus dados. Ela não muda o fato de que alguém sempre pode.

Este post é para leitores cujo modelo de ameaça é a exposição comercial de dados, ou seja, a monetização pelas Big Techs e as violações de fornecedores, não a vigilância de nível estatal, o jornalismo de alto risco, o ativismo ou a descoberta judicial. A arquitetura abaixo é uma stack de cinco camadas para esse modelo de ameaça específico.

A versão curta

Esta stack tem cinco camadas. Cada camada remove uma dependência comum das Big Techs, mas nenhuma delas te torna invisível.

• Rede: o WireGuard substitui uma VPN comercial e limita a visibilidade do provedor de internet ou da rede local.
• Identidade: o Vaultwarden substitui gerenciadores de senha hospedados e reduz a exposição a violações do lado do fornecedor.
• Busca: o SearXNG reduz a perfilagem de busca ao intermediar suas pesquisas pela sua VPS e mantê-las fora da sua conta de busca logada.
• Arquivos e fotos: o Nextcloud AIO e o Immich substituem o Google Drive e o Google Photos, cortando a varredura de conteúdo na nuvem e o cruzamento de dados entre produtos.
• Comunicações de equipe: o Mattermost ou o Rocket.Chat tiram o histórico de chat de equipe do Slack, do Discord ou do Teams.
• Principais limites: seu provedor de VPS ainda pode ver metadados de infraestrutura, seu provedor de internet ainda pode ver que você se conecta ao seu servidor, e esta stack não foi construída para adversários de nível estatal.
• Nota sobre jurisdição: hospedar na UE fortalece o argumento de soberania de dados, mas não é um escudo mágico.

A auto-hospedagem desloca a confiança, não a remove

Há um argumento de longa data no Hacker News, e ele está correto na sua aparência: "auto-hospedar em uma VPS não resolve a privacidade, você só passa a confiar em outro fornecedor." Qualquer pessoa que projete uma arquitetura de privacidade deveria encarar isso diretamente, não contornar. A resposta honesta é que o deslocamento de confiança é assimétrico. Ele não é equivalente.

Comece pelo que a auto-hospedagem reduz. O modelo de negócio do seu provedor de SaaS não é mais minerar seus dados, porque o provedor se foi. A exposição a violações do lado do fornecedor muda de forma: o cofre do Vaultwarden é criptografado no lado do cliente, mas serviços legíveis pelo servidor, como Nextcloud, Mattermost e Rocket.Chat, ainda precisam de fortalecimento, backups e controle de acesso adequados.

A lição do LastPass não foi que a criptografia do cofre nunca existiu. Foi que backups criptografados de cofre roubados, metadados não criptografados, configurações antigas de KDF e senhas mestras fracas criaram um caminho de quebra offline. A perfilagem comportamental entre serviços também encolhe, porque há menos dados entre serviços para uma única empresa juntar. O aprisionamento por assinatura cai.

Agora, o que a auto-hospedagem não elimina. O hipervisor do seu provedor de VPS pode, em princípio, ler a memória da sua VM. Seu provedor de VPS vê seus metadados de nível de infraestrutura: a quais IPs você se conecta, quando e quanto dado se move.

Seu provedor de internet ainda vê que você está se conectando ao seu servidor. Pedidos legais jurisdicionais ainda se aplicam no nível do provedor de VPS, e uma ordem judicial ainda é uma ordem judicial. Uma VPS, app, banco de dados ou conta de administrador comprometidos ainda podem expor dados.

A matemática da confiança é o que importa. Um provedor de VPS tem menos incentivo comercial para minerar seus dados do que o Google ou a Meta, porque a mensalidade é o modelo de negócio, e seus dados não. Um provedor de VPS tem menos dados agregados sobre você, ou seja, o seu único servidor, não o seu histórico de busca, histórico de localização e caixa de entrada combinados.

Na UE, o provedor opera sob o GDPR e termos contratuais específicos. Nada disso torna uma VPS mais segura que o Google em todas as dimensões. É um modelo de ameaça diferente com um perfil de exposição diferente, e para o modelo de ameaça que este post aborda, é uma melhoria significativa.

Há mais uma distinção que vale a pena ser preciso. Privacidade é "eles não sabem o que estou fazendo". Anonimato é "eles não sabem que sou eu fazendo". Auto-hospedar em uma VPS comercial melhora a privacidade em relação a fornecedores de SaaS e plataformas de terceiros.

Ela não te dá anonimato em relação ao seu provedor de VPS. Se você precisa de anonimato, você está usando Tor, não uma VPS, e o resto deste post é a ferramenta errada.

Principal conclusão da seção: uma VPS desloca sua confiança de um fornecedor de SaaS cujo modelo de negócio é monetizar seus dados para um provedor de infraestrutura cujo modelo de negócio é vender um servidor para você. Para o modelo de ameaça da maioria dos leitores, isso é uma melhoria significativa, mas não é invisibilidade.

A stack de cinco camadas em resumo

Cinco camadas, implantadas nesta ordem: rede, identidade, busca, arquivos, comunicações. Cada uma aborda uma ameaça distinta. Você pode implantá-las em etapas, e pode pular camadas que não se aplicam a você. O modelo é mais útil que uma lista de apps porque escala com as suas preocupações, e não com a quantidade de serviços rodando no seu servidor.

Principal conclusão da seção: Comece com WireGuard, Vaultwarden e SearXNG se você quer a stack de privacidade mais leve. Adicione Nextcloud, Immich e chat de equipe só depois de estar pronto para maior uso de RAM, planejamento de armazenamento, backups e mais trabalho de administração.

Camada 1: a camada de rede (WireGuard)

O arquivo de configuração do WireGuard para um setup típico de usuário único tem doze linhas. Seu handshake se completa em uma única ida e volta e usa o framework do protocolo Noise. O módulo do kernel está no Linux mainline desde a 5.6, o que significa que o protocolo que você implanta em 2026 é o mesmo que vem sendo auditado e estável há anos. Este é o padrão certo.

O que esta camada aborda: observadores do provedor de internet e da rede local que de outra forma veriam cada domínio ao qual você se conecta, atacantes em Wi-Fi público, e seu IP doméstico sendo exposto a cada serviço que você visita. Seu tráfego sai da sua VPS, em vez de sair do seu apartamento.

O que ela não aborda: a visão do seu provedor de VPS sobre a saída do seu tráfego. Eles veem a que o seu endpoint de VPN se conecta, quando e quanto. O WireGuard esconde o tráfego do seu provedor de internet. Ele não esconde o tráfego do servidor que opera a saída.

Vazamentos de DNS também são um problema separado e não são tratados automaticamente; você precisa apontar seus clientes de VPN para um resolvedor em que você confia. Rode o Unbound na mesma VPS, ou use um upstream confiável via DoT ou DoH. O bloqueio de anúncios de camada DNS completa com o Pi-hole é um assunto à parte e não é a coisa certa para combinar com uma saída de VPN para a maioria dos usuários (mais sobre isso abaixo).

WireGuard versus as alternativas, em resumo. O OpenVPN ainda funciona. O handshake é maior, a pegada de metadados é maior, e a taxa de transferência é menor. Não há razão para escolhê-lo para uma nova implantação a menos que você precise especificamente de um recurso que o WireGuard não oferece.

O Tailscale é uma ferramenta diferente: é uma malha de configuração zero construída sobre o WireGuard e é excelente para costurar seus próprios serviços auto-hospedados entre máquinas. Não é o que você quer como saída de privacidade para a internet, porque o plano de coordenação é hospedado pela Tailscale.

Nota: mudar a porta padrão 51820/UDP pode reduzir varreduras de baixo esforço, mas não faz o WireGuard parecer tráfego HTTPS comum nem contorna filtragem séria. Trate isso como redução de varredura, não como camuflagem.

Para a implantação, temos um guia passo a passo de configuração do WireGuard para Ubuntu que combina com esta arquitetura.

Principal conclusão da seção: O WireGuard na sua VPS te dá uma saída de rede privada que o seu provedor de internet não consegue inspecionar, mas não esconde seu tráfego do provedor de VPS que opera a saída.

Camada 2: a camada de identidade (Vaultwarden)

O Vaultwarden roda em menos de 200 MB de RAM. É uma reimplementação em Rust da API do Bitwarden, compatível com todos os clientes oficiais do Bitwarden (extensões de navegador, apps de desktop, apps de celular), e não exige a pesada imagem de referência do servidor Bitwarden. Para um único usuário ou um lar, este é o tamanho certo.

O que esta camada aborda: violações de senha do lado do fornecedor, como a falha no estilo do LastPass, em que o conteúdo dos cofres vazou e acabou sendo descriptografado offline. A reutilização de credenciais entre serviços fica mecanicamente mais difícil depois que você tem um gerenciador de senhas que de fato usa. A agregação de perfil de identidade entre serviços cai, porque nenhum terceiro vê a lista.

O que ela não aborda: a sua própria segurança operacional. Uma senha mestra fraca, sem 2FA no cofre, ou um ataque de phishing bem-sucedido contra você derrota esta camada por completo. Um dispositivo comprometido com uma extensão de navegador logada a derrota ainda mais por completo. O Vaultwarden é um cofre, não um substituto para o básico.

Há um aviso operacional que importa mais do que qualquer outro nesta stack. Auto-hospedar seu gerenciador de senhas significa que você é responsável pelos backups. Uma VPS que falha no momento errado, ou um servidor que você apaga por acidente, te tranca para fora de cada conta que esta camada protege.

A XDA Developers também cobriu esse risco diretamente, alertando que um gerenciador de senhas auto-hospedado pode te trancar para fora de contas importantes se o acesso, os backups ou o planejamento de recuperação falharem.

Aviso: rode backups automatizados e criptografados do diretório de dados do Vaultwarden. Mantenha uma exportação criptografada offline, guarde os códigos de recuperação separadamente, e teste a restauração em um dispositivo reserva ou contêiner temporário. Não dependa de um único backup da VPS. Isso não é opcional. Este é o preço de tirar o cofre da infraestrutura do fornecedor.

Se você for centralizar o login único entre vários serviços auto-hospedados mais tarde, o Authentik é o provedor de identidade de código aberto onde a maioria das pessoas acaba parando. Essa é uma camada avançada e fora do escopo da stack principal.

Para a implantação, nosso guia de auto-hospedagem do Vaultwarden é o companheiro de implantação. Para um olhar mais profundo sobre o cenário de gerenciadores de senha, veja nosso guia dos melhores gerenciadores de senha auto-hospedados.

Principal conclusão da seção: O Vaultwarden tira seu cofre de senhas da infraestrutura de fornecedores propensa a violações, mas coloca sobre você o fardo do backup e da recuperação, e esse fardo é real.

Camada 3: a camada de busca e navegação (SearXNG)

Uma instância do SearXNG recebe sua consulta, a distribui para motores upstream (Google, Bing, DuckDuckGo, outros que você habilitar), retira alguns parâmetros identificadores e retorna uma página de resultados unificada.

Suas consultas chegam ao Google, mas chegam ao Google como consultas da sua VPS, não da sua conta de busca logada. Uma instância de usuário único não cria um grande conjunto de anonimato, então motores upstream ainda podem associar padrões de consulta a esse IP da VPS.

O que esta camada aborda: perfilagem de consultas de busca, segmentação comportamental de anúncios atrelada ao seu histórico de busca logado, e a longa memória de uma conta de busca. O problema do "por que estou vendo anúncios da coisa que pesquisei ontem" é reduzido no nível da conta de busca.

O que ela não aborda: o rastreamento pelos sites em que você de fato clica. Cookies, fingerprinting e rastreadores em páginas de terceiros são um problema do lado do navegador, não do lado da busca. Use uma configuração de navegador fortalecida para resolver isso.

O SearXNG também não te anonimiza em relação ao motor de busca upstream se a sua VPS envia apenas as suas consultas para ele; o tráfego agregado de uma instância movimentada esconde usuários individuais no ruído, mas uma instância de usuário único ainda pode parecer o padrão de busca de um único usuário.

O Whoogle Search é a alternativa mais leve. É um front-end do Google, mais simples, e faz uma coisa só. O SearXNG agrega vários motores, o que é mais útil se o seu motivo para sair do Google não era especificamente o Google. Escolha com base em quantas fontes você de fato quer.

Uma nota operacional para instâncias de usuário único. O SearXNG encaminha consultas para motores upstream, e o Google pode limitar a taxa de padrões de tráfego suspeitos. Um único usuário raramente atinge isso. Uma pequena instância pública pode atingir. Se as consultas começarem a falhar, reduza a contagem de motores upstream, ajuste as configurações do limitador do SearXNG, ou apoie-se mais em motores upstream menos hostis.

Principal conclusão da seção: O SearXNG intermedia suas buscas pela sua VPS e as mantém fora da sua conta de busca logada. Ele reduz a perfilagem direta de busca, mas uma instância privada de usuário único não cria um grande conjunto de anonimato.

Camada 4: a camada de arquivos e fotos (Nextcloud AIO + Immich)

O Nextcloud AIO é a implantação tudo-em-um em Docker do Nextcloud e é o caminho de menor resistência para um servidor funcional de sincronização de arquivos, calendário, contatos e colaboração em documentos.

O Immich é a contraparte de fotos: visualização em linha do tempo, upload automático no celular a partir de iOS e Android, reconhecimento facial no estilo do Google Photos processado no seu próprio servidor ou no host de ML escolhido, e um consenso honesto da comunidade de que é o substituto mais utilizável do Google Photos disponível atualmente.

Estes não são aplicativos leves. O Nextcloud AIO deve ser tratado como uma base de 4 GB / 2 vCPU; o aprendizado de máquina do Immich, a geração de miniaturas e a primeira varredura da biblioteca vão usar o que você der.

O que esta camada aborda: a varredura pelo fornecedor de armazenamento na nuvem, o reconhecimento de conteúdo de fotos, e o processamento do lado da nuvem que mantêm uma biblioteca pessoal sensível dentro de uma conta de fornecedor, e a centralização de dados no nível da conta que mantém arquivos, fotos, busca, histórico de localização e sinais de identidade sob a conta de uma única empresa.

Substituir isso por um servidor que você controla quebra essa centralização.

O que ela não aborda: os bytes ainda ficam em um volume de armazenamento que o seu provedor de VPS opera. A criptografia em repouso é responsabilidade sua, não deles por padrão. O comprometimento do lado do dispositivo é um problema separado; se o seu celular estiver com root, o cliente do Nextcloud nele fica exposto independentemente de onde o servidor mora.

Se a sua única necessidade é "manter essas pastas sincronizadas entre meus dispositivos", o Syncthing é a ferramenta mais simples. É ponto a ponto, não tem servidor no meio, e faz esse único trabalho bem. Não é um substituto para os recursos de calendário, contatos e colaboração que o Nextcloud oferece; é um substituto para o subconjunto de sincronização de arquivos.

Para o Immich especificamente, uma regra prática de dimensionamento importa. O Nextcloud AIO deve ser tratado como uma base de 4 GB / 2 vCPU. O Immich não é um complemento leve de fotos uma vez que o aprendizado de máquina, as miniaturas e a primeira varredura da biblioteca entram em cena. Planeje em torno de 6 a 8 GB de RAM para setups com forte uso do Immich, especialmente durante a migração.

Para a implantação, temos uma comparação entre Nextcloud e ownCloud para usuários que ainda estão escolhendo entre os dois, e uma visão geral mais ampla das plataformas de nuvem auto-hospedadas com interface web se você está sondando o espaço.

Principal conclusão da seção: O Nextcloud e o Immich podem mover arquivos e fotos para fora de contas de nuvem no estilo do Google, mas são a primeira camada nesta stack que precisa de RAM séria, planejamento de armazenamento, backups e paciência na migração.

Camada 5: a camada de comunicações (Mattermost ou Rocket.Chat)

Workspaces do Slack são pesquisáveis pelo Slack. O Discord varre o conteúdo em busca de violações dos Termos de Serviço. O Microsoft Teams retém os registros de chat sob as políticas do seu tenant, que são políticas que a sua organização de TI pode ver.

Para chat de equipe ou de família que não deveria morar em nenhum desses lugares, um Mattermost ou Rocket.Chat auto-hospedado é a resposta padrão. Esta camada é sobre manter os arquivos da equipe fora do SaaS, não sobre chat privado de ponta a ponta.

O que esta camada aborda: o arquivamento de mensagens do lado do fornecedor, a varredura de conteúdo do lado do fornecedor, e a perda de acesso que acontece quando o fornecedor decide que a sua conta é um problema. O histórico de mensagens da sua equipe fica no seu servidor.

O que ela não aborda, e isso importa: a criptografia de ponta a ponta. O Mattermost e o Rocket.Chat não são E2EE por padrão. O administrador do servidor pode ler as mensagens. O administrador do servidor agora é você, o que é melhor do que ser um funcionário de um fornecedor de SaaS, mas o princípio ainda importa para o modelo de ameaça da sua equipe.

Para mensagens seguras um a um, o Signal é a resposta certa, não um servidor auto-hospedado. Se a camada de comunicação precisa ser E2EE por padrão, olhe para o Matrix/Element ou use o Signal para conversas pessoais. A auto-hospedagem resolve as mensagens de equipe sem um fornecedor; ela não substitui o Signal para modelos de ameaça pessoais.

Mattermost versus Rocket.Chat. Ambos são válidos. O Mattermost é mais enxuto, mais no formato corporativo, e tem menos recursos opcionais ligados por padrão. O Rocket.Chat é mais amplo, integra mais tipos de canais, e tem um ecossistema de plugins maior. Qualquer um serve para o caso de uso típico de stack de privacidade de uma equipe pequena ou chat de família.

Ressalva de 2026: verifique a edição gratuita exata antes de implantar o Mattermost. O Mattermost Entry tem um limite de histórico de 10.000 mensagens, enquanto o Team Edition evita esse limite, mas tem os seus próprios limites. Para o Rocket.Chat, reserve mais do que uma VPS minúscula de 1 GB, porque o MongoDB, os uploads e as integrações adicionam sobrecarga.

Principal conclusão da seção: Um Mattermost ou Rocket.Chat auto-hospedado tira o arquivo de chat da sua equipe de um fornecedor de SaaS, mas se você precisa de verdadeira criptografia de ponta a ponta entre duas pessoas, o Signal ainda é a ferramenta certa.

O que NÃO auto-hospedar (e por quê)

Algumas coisas que parecem pertencer a uma stack de privacidade não pertencem. Listá-las faz parte de construir uma stack digna de confiança.

E-mail. Não auto-hospede e-mail se você ainda não é um operador Linux experiente que especificamente quer fazer isso. O PrivacyGuides tem uma posição clara e bem conhecida sobre isso, e é a posição certa: só usuários avançados deveriam rodar o próprio servidor de e-mail. As razões não são curiosidade técnica. SPF, DKIM e DMARC precisam ser configurados e mantidos corretos.

A reputação de IP precisa ser conquistada e mantida. A filtragem de spam é um estado permanente das coisas. A luta de entregabilidade com o Gmail não é uma etapa de configuração; é uma condição contínua. Para todo o resto, um provedor gerenciado que respeita a privacidade é genuinamente a resposta certa para esta camada.

Proton Mail, Tuta (antes Tutanota) e Mailbox.org são todas boas escolhas. Esta é uma regra rígida deste post: não auto-hospede e-mail para privacidade de público geral.

Pi-hole como resolvedor de DNS primário da sua rede doméstica, em uma VPS. O Pi-hole é ótimo. Colocá-lo em uma VPS como o resolvedor recursivo para a internet de toda a sua casa é um único ponto de falha que quebra a internet para todo mundo na casa quando a VPS engasga. O Pi-hole pertence a um Raspberry Pi em casa. Ele não faz parte desta stack.

Mídias sociais federadas. Mastodon, Pleroma e o resto são interessantes e adjacentes. A adoção é a principal restrição, não a privacidade. Elas são a resposta certa para algumas pessoas, mas não são centrais para uma stack de privacidade focada em tirar os seus próprios dados dos servidores das Big Techs.

Ferramentas de anonimato. Tor, I2P, mixnets. Modelo de ameaça diferente, post diferente. Se você precisa delas, você já sabe.

O resumo: o Proton Mail ou um equivalente é uma alternativa gerenciada para uma camada específica, e reconhecer isso faz parte de uma stack digna de uso. A auto-hospedagem ajuda onde esses provedores não cobrem o fluxo de trabalho completo: fotos, busca, análises personalizadas e chat de equipe. Para privacidade de público geral, o e-mail é a única camada que esta stack deveria terceirizar.

Principal conclusão da seção: A maioria dos usuários não deveria auto-hospedar e-mail. Um provedor gerenciado que respeita a privacidade, como o Proton Mail, é genuinamente a melhor resposta para essa única camada, e reconhecer isso faz parte de construir uma stack confiável.

Onde rodá-la: dimensionamento de VPS e jurisdição

A questão do dimensionamento não é abstrata. Esta stack tem três formatos práticos: o núcleo leve de privacidade, a camada de arquivos, e a versão pesada em fotos que traz o aprendizado de máquina do Immich para a mistura. O salto de um para o próximo não é cosmético. Arquivos, miniaturas, reconhecimento facial e a migração da primeira biblioteca são o que transformam uma VPS pequena em um orçamento de servidor de verdade.

Leia a tabela assim:

• A stack mínima cobre as três camadas de maior retorno: rede, identidade e busca.
• Base do Nextcloud precisa de mais folga porque PHP, trabalho de banco de dados, indexação de arquivos, jobs de sincronização e a interface web rodam todos juntos.
• Stack de arquivos e fotos precisa de um orçamento maior porque o aprendizado de máquina do Immich, as miniaturas, o reconhecimento facial e a primeira varredura da biblioteca de fotos podem sobrecarregar o servidor durante a migração.
• O armazenamento importa porque o poder de computação é só metade do plano. Arquivos e fotos precisam de espaço para crescer, backups longe da VPS, e um caminho de recuperação que ainda funcione se o servidor desaparecer.

Depois há a jurisdição. Em junho de 2025, a Microsoft testemunhou ao Parlamento francês que não podia garantir que dados hospedados na UE estariam protegidos do acesso legal dos EUA. Esse testemunho tirou o argumento da soberania de dados da teoria e o levou para a conversa de política mainstream.

Para usuários que priorizam a soberania de dados, a jurisdição da empresa, a localização do datacenter, os contratos, o modelo de criptografia e a localização dos backups, tudo importa.

If CLOUD Act a exposição faz parte da preocupação, não trate um datacenter na UE sozinho como a resposta completa. Um provedor sem sede nos EUA com uma região europeia é uma opção mais limpa que a região da UE de um hyperscaler com sede nos EUA, mas isso ainda não torna os dados legalmente intocáveis.

A ressalva: a jurisdição é fricção, não invulnerabilidade. Uma ordem judicial alemã ainda é uma ordem judicial. Uma holandesa também. Assim como um pedido legal suíço. A hospedagem europeia pode reduzir parte da exposição direta a provedores de nuvem com sede nos EUA e adicionar processo legal local, mas não torna os dados legalmente intocáveis.

Para o modelo de ameaça da maioria dos leitores, a fricção adicional é útil. Ela não é um escudo mágico.

Principal conclusão da seção: A stack leve pode rodar em uma VPS pequena, mas arquivos e fotos mudam o orçamento. Use 4 GB / 2 vCPU como base só para o Nextcloud, e planeje algo mais perto de 8 GB / 4 vCPU para um setup do Immich pesado em fotos. A Cloudzy Marketplace reduz o esforço de configuração para os apps principais, enquanto a jurisdição adiciona fricção legal, não invisibilidade.

Como implantar a stack sem transformar a configuração no projeto

Você pode construir cada camada manualmente. Tudo bem se o trabalho de configuração faz parte da graça. Para a maioria dos leitores, não faz. O ponto desta stack é se afastar da gravidade de dados das Big Techs, não passar uma semana depurando Docker, portas, DNS e arquivos de serviço antes mesmo de o primeiro app rodar.

O caminho de menor fricção é começar a partir de uma imagem de VPS funcional e fortalecer a partir dali. A Cloudzy Marketplace inclui imagens de VPS de um clique para WireGuard, Vaultwarden, SearXNG, Nextcloud AIO e outras ferramentas auto-hospedadas, para que a implantação base não seja a parte que come o fim de semana.

O trabalho que ainda importa é o trabalho que nenhuma marketplace pode fazer por você: DNS, regras de firewall, backups, controles de acesso, atualizações e testes de recuperação.

O servidor por baixo também importa. Esta stack é armazenamento, rede, escolha de região e folga, não só nomes de apps em uma tabela. A Cloudzy te dá infraestrutura de VPS com NVMe, acesso root completo, 13 regiões, rede de 40 Gbps, 99,95% de uptime e uma garantia de reembolso de 14 dias.

Comece pequeno para WireGuard, Vaultwarden e SearXNG. Suba para o Nextcloud. Planeje com mais seriedade para o Immich uma vez que o aprendizado de máquina, as miniaturas e a migração de fotos entram em cena.

Como começar

Cinco camadas, cada uma abordando uma ameaça específica. Nenhuma delas afirma te tornar invisível. Todas elas reduzem uma exposição comercial de dados específica que você atualmente aceita por padrão.

Escolha a única camada que aborda a sua dor concreta mais atual. Se você já abriu um e-mail de notificação de violação, essa é a camada de identidade. Se você notou anúncios te seguindo por sites que nunca visitou, essa é a camada de busca. Implante essa. A arquitetura escala. A decisão de começar não precisa escalar.

A configuração de qualquer camada isolada leva no máximo um fim de semana. Os arquivos de configuração são curtos. Não há razão para isso ser mais complicado do que isto.

Perguntas frequentes

A auto-hospedagem em uma VPS realmente protege a minha privacidade, ou eu só estou confiando em outro fornecedor?

Sim, para este modelo de ameaça. Ela desloca a confiança de fornecedores de SaaS que monetizam os dados dos usuários para um provedor de VPS que vende infraestrutura. Isso reduz a exposição comercial e a perfilagem entre serviços, mas não esconde os metadados da VPS, os registros de conexão do provedor de internet, dispositivos comprometidos ou a vigilância de nível estatal.

Qual é a stack de privacidade auto-hospedada mínima com que eu deveria começar?

Comece com WireGuard, Vaultwarden e SearXNG. Eles cobrem a visibilidade de rede, o risco de violação do fornecedor de senhas, e a perfilagem de busca logada em uma VPS de 2 GB de RAM. Adicione o Nextcloud depois; adicione o Immich só depois de ter mais RAM, armazenamento e disciplina de backup.

Hospedar em Frankfurt ou Amsterdã é realmente melhor para a privacidade do que nos EUA?

Regiões europeias podem reduzir parte da exposição direta a provedores com sede nos EUA, mas não tornam os dados legalmente intocáveis. A jurisdição da empresa, a localização do datacenter, os contratos, a criptografia e a localização dos backups, tudo importa. Pedidos legais alemães, holandeses ou suíços ainda podem se aplicar.

Eu deveria auto-hospedar meu e-mail por privacidade?

Para quase todo mundo, não. A auto-hospedagem de e-mail exige SPF, DKIM, DMARC, reputação de IP, filtragem de spam e trabalho constante de entregabilidade. Use um provedor gerenciado que respeita a privacidade, como Proton Mail, Tuta ou Mailbox.org. O PrivacyGuides recomenda e-mail auto-hospedado só para usuários avançados.

Do que o WireGuard realmente me protege?

O WireGuard roteia o tráfego pela sua VPS, limitando o que o seu provedor de internet e a sua rede local conseguem ver. Ele não esconde o tráfego de saída do provedor de VPS. Eles ainda podem ver metadados de conexão, IPs de destino, tempos e volume. É privacidade em relação ao seu provedor de internet, não invisibilidade.