Transformei meu notebook antigo em uma alternativa ao Google Drive

Opa, prova de vida. Ainda estou vivo.

Desde quando comecei minha jornada na computação, tive curiosidade de saber como funcionam os serviços por trás dos panos. Desde simples sites web estáticos até SaaS complexos. Queria sempre aprender quais tecnologias usam, como configuraram, a infraestrutura utilizada, etc.

Também nunca fui muito fã em como confiamos em empresas e big techs para gerenciar nossos dados. Sites como OneDrive, Google Drive e Dropbox são excelentes e até os planos são em conta. Mas é meio estranho e bizarro saber que eles estão escaneando nossas fotos, arquivos e etc para seja lá qual o propósito deles.

E eu tenho um notebook velho de guerra aqui a muito tempo parado. Uma verdadeira máquina do apocalipse, uma besta esperando ser libertada para ser a próxima devoradora de mundos. Pensei: por que não unir o útil (privacidade) ao agradável? Aí que nasceu meu primeiro self-hosted.

O primeiro substituto foi o Google Drive. O plano por 100GB custava R$9,99 mensal, o que é uma pechincha. Mas o negócio aqui não foi por dinheiro, foi para manter controle dos meus próprios dados. Então foi meu primeiro substituto.

Podemos matar facilmente com várias alternativas: pensei em um FreeNAS, embora não tenha experiência alguma em configura-lo. Mas vi também o NextCloud, uma suíte completa que vai além de ser um servidor de arquivos. Conseguimos configurar Arquivos, Emails, Contatos, até um OnlyOffice via rede (semelhante ao Google Docs). Uma suíte workspace plenamente funcional e local.

Decidi seguir por esse caminho. O NextCloud pode ser instalado via docker/podman ou bare metal. Decidi pelo podman pois já tinha uma experiência e seria um caminho mais fácil. O sistema base escolhido foi o bom e velho Arch Linux (seria um crime eu escolher qualquer outro).

Optei por Podman rootless ao invés do Docker tradicional por alguns motivos: não existe um daemon rodando com privilégios root, de forma que os containers rodam com o meu próprio usuário; os containers são gerenciados por units do systemd --user (com loginctl enable-linger, sobem automaticamente mesmo sem login interativo); há menos overhead, ideal para um servidor headless com apenas 4 GB de RAM; e não há necessidade do daemon Docker, tornando tudo mais enxuto e alinhado com a filosofia do Arch Linux.

O Arch foi instalado para funcionar completamente headless — tudo será acessível via SSH, sem interface gráfica nem nada físico conectado. A vantagem é que, como ele é um notebook, se o acesso falhar, basta abrir a tela e debugar.

A máquina do apocalipse contém um Celeron N3060 dual core e 4 GB de RAM DDR3 soldados (sem capacidade de expansão). No início duvidei que ele aguentaria o Nextcloud, mas pra minha surpresa tudo funcionou perfeitamente após ajustar a infraestrutura.

A arquitetura roda em um único pod do Podman (pod_nextcloud), interligando dois containers principais:

• nextcloud-app: A aplicação Nextcloud rodando sobre a imagem oficial nextcloud:apache (com o Nextcloud na versão 35.0.1.1), acessível via LAN, mDNS (nextcloud.local) e Tailscale. O código do core fica desacoplado em um volume anônimo gerenciado pela própria imagem, enquanto os dados sensíveis, banco e configurações residem em bind mounts seguros no host (~/containers/nextcloud/), permitindo atualizações limpas via podman pull.
• nextcloud-redis: Um container Redis (redis:alpine) atuando como cache local/distribuído e controle de locking (memcache.locking), o que elimina os engasgos de file locked e acelera drasticamente a navegação e o carregamento de miniaturas, consumindo quase nada de memória (~1,73 MB).

Para o banco de dados, fui na contramão de SGBDs pesados e mantive o SQLite3 em modo WAL (journal_mode=wal). Para um uso doméstico com meus cerca de 54 mil arquivos indexados (~98 GB de dados), ele entrega simplicidade absurda (os backups resumem-se a copiar o arquivo ou usar VACUUM INTO) sem o peso de um daemon dedicado — embora eu saiba que ele cobra o preço se houver muitas escritas concorrentes, o que não é o caso aqui.

As rotinas de manutenção e background rodam pontualmente através de timers do systemd --user disparando o cron.php a cada 5 minutos via podman exec, garantindo que os afazeres pendentes do sistema não engasguem a interface web. Além disso, criei um pequeno watchdog L3 via systemd para monitorar a interface Wi-Fi (uma placa Atheros ath10k que às vezes perdia o pé no DHCP/ARP após quedas transitórias): caso a rota para o gateway falhe por três verificações consecutivas, ele força um religamento limpo via iwctl, contornando quedas longas e mantendo o acesso estável.

Também precisei definir um IP estático no roteador (infelizmente, sem cabos por enquanto). O processo varia de roteador para roteador, mas felizmente o processo aqui foi simples. Bastou ter o endereço mac e voilá

E para fechar o acesso sem depender de portas abertas no roteador ou IPs públicos dinâmicos, entra em cena o Tailscale. Como o servidor fica na minha rede doméstica mas eu vivo saindo, configurar uma VPN mesh baseada em WireGuard mudou completamente o jogo.Instalar e autenticar o Tailscale no Arch Linux foi questão de segundos, e o melhor de tudo é que ele cria uma rede privada segura que me acompanha em qualquer lugar do mundo. Basta bater no IP do Nextcloud na VPN que a conexão é estabelecida de ponta a ponta com criptografia forte, sem precisar de NAT forwarding maluco ou exposing na internet aberta. É basicamente ter meu próprio data center privado no bolso, acessível com um clique e com zero dor de cabeça de configuração de rede externa.

No fim das contas, consegui um drive local com 500GB, totalmente funcional e com controle absoluto, focado em privacidade digital. Até o próximo post, falou.