Como escolher VPS para Immich self-hosted

Resposta direta

Para hospedar o Immich self-hosted com folga, o ponto de partida mais equilibrado é uma VPS com 4 vCPUs, 8 GB de RAM, 80 GB de SSD ou NVMe para sistema e banco, além de um volume separado dimensionado para a biblioteca. Uma instalação pequena pode funcionar com 2 vCPUs e 4 GB, mas importações grandes, reconhecimento facial, geração de miniaturas e transcodificação de vídeos elevam o consumo temporariamente. O backup deve incluir o banco PostgreSQL, os arquivos enviados e a configuração, sempre com uma cópia fora da VPS e testes periódicos de restauração.

O ponto de partida mais seguro

O Immich não é apenas uma galeria que lê arquivos estáticos. Durante uma importação, ele grava metadados no banco, cria miniaturas, analisa imagens e pode converter vídeos para formatos mais compatíveis. Uma biblioteca de 20 GB usada por uma pessoa exige pouco no uso diário, mas pode pressionar CPU e memória durante a carga inicial. Já um acervo familiar de 500 GB, com vídeos em 4K e vários celulares sincronizando, pede mais espaço livre, melhor conectividade e uma política de backup bem definida.

Pense na VPS como o núcleo da aplicação, não como a única cópia das lembranças. Por exemplo, 4 vCPUs e 8 GB de RAM podem atender uma família com uso moderado, enquanto 8 vCPUs e 16 GB fazem mais sentido quando há importações frequentes ou muitos vídeos. Se o armazenamento crescer mais rápido que o processamento, mantenha sistema e banco em disco rápido e avalie um volume adicional. O dimensionamento final deve partir do acervo atual, do crescimento mensal e do tempo aceitável para restaurar tudo após uma falha.

Resumo rápido

• Use 2 vCPUs e 4 GB de RAM apenas para bibliotecas pequenas ou ambientes de teste.
• Prefira 4 vCPUs e 8 GB para uma instalação familiar com fotos, vídeos e tarefas de machine learning.
• Mantenha sistema operacional, contêineres e PostgreSQL em SSD ou NVMe com baixa latência.
• Calcule o disco incluindo originais, miniaturas, vídeos transcodificados, banco, logs e pelo menos 20% de espaço livre.
• Faça backup separado dos arquivos e do banco, mas preserve pontos de recuperação compatíveis entre eles.
• Confirme limite de tráfego, velocidade da porta, custo de saída e expansão de volumes antes da contratação.
• Teste a restauração em outro diretório ou servidor, pois sincronização de arquivos não substitui um backup versionado.

Como interpretar as recomendações

Os números deste artigo são referências de planejamento, não garantias de quantidade de usuários ou fotos. Duas bibliotecas de 300 GB podem produzir cargas bem diferentes. Uma delas pode ser composta por JPEGs de 5 MB, enquanto a outra reúne vídeos HEVC de vários gigabytes que precisam de transcodificação. A primeira tende a consumir mais operações de indexação por quantidade de itens. A segunda exige mais CPU, banda e espaço temporário.

Considere três momentos separados. A importação inicial costuma ser o período mais pesado. O uso diário é mais leve, com uploads incrementais, busca e visualização. A recuperação de desastre exige leitura e transferência intensas, podendo revelar limites de banda que não aparecem durante a rotina. Um servidor doméstico migrando 300 GB por uma conexão efetiva de 30 Mbps levaria cerca de 22 horas apenas para transmitir os dados em condições ideais. Na prática, protocolo, latência e oscilações aumentam esse prazo.

Antes de escolher um plano, registre quantos gigabytes existem hoje, quanto o acervo cresce por mês e qual janela de indisponibilidade é aceitável. Esses três dados orientam melhor a decisão do que uma recomendação genérica baseada apenas no número de usuários.

CPU e RAM para indexação, busca e transcodificação

A CPU entra em ação quando o Immich gera miniaturas, extrai metadados, processa recursos de busca, executa tarefas de machine learning e lida com vídeos. Para uma instalação pessoal com até algumas dezenas de milhares de fotos, 2 vCPUs podem sustentar a navegação diária. O problema aparece durante uma importação extensa. Os trabalhos em segundo plano disputam processamento com o banco de dados e a interface, deixando a abertura de álbuns mais lenta.

Quatro vCPUs oferecem uma margem mais confortável para uma família ou pequena equipe. Um exemplo prático é a importação de 30 mil imagens acompanhada pela sincronização de dois celulares. Com apenas 2 vCPUs compartilhadas, pode ser necessário limitar a concorrência dos trabalhos para preservar a interface. Com 4 vCPUs, as tarefas ainda levam tempo, mas há mais capacidade para processar requisições interativas. O desempenho exato depende da geração do processador, do nível de compartilhamento do host e dos limites impostos pelo provedor.

Quando quatro vCPUs fazem diferença

Vídeos mudam bastante o cenário. Um acervo com clipes H.264 curtos pode exigir pouca conversão, enquanto arquivos HEVC em 4K pressionam a CPU por períodos longos. Quem pretende importar centenas de vídeos deve consultar também o conteúdo sobre processamento de vídeo com FFmpeg em VPS, pois codec, resolução e aceleração por hardware alteram o dimensionamento. Uma VPS convencional nem sempre oferece GPU ou acesso a dispositivos de vídeo, portanto isso precisa ser confirmado antes da contratação.

Para memória, 4 GB representam o piso prático de um ambiente pequeno. O sistema operacional, Docker, Immich, PostgreSQL e os componentes auxiliares compartilham esse espaço. Com 8 GB, o banco mantém mais páginas em cache e as tarefas simultâneas têm menor chance de acionar swap. Ambientes com 100 mil itens, vários usuários ou importações paralelas podem justificar 16 GB.

Como detectar falta de memória

Use docker stats, free -h e os gráficos do provedor durante importações. Swap crescendo continuamente, contêineres reiniciando e mensagens de processo encerrado por falta de memória indicam pressão real. Não aumente recursos às cegas. Primeiro reduza a concorrência das tarefas, observe por algumas horas e só então compare o resultado com um upgrade.

Como calcular o armazenamento da biblioteca

O cálculo de disco começa pelo tamanho dos originais, mas não termina nele. O Immich precisa guardar dados gerados pela aplicação, banco, miniaturas, imagens de pré-visualização, perfis de pessoas e, conforme a configuração, versões transcodificadas de vídeos. Logs, atualizações de imagens Docker e arquivos temporários também ocupam espaço. Planejar o volume apenas com base na pasta atual cria uma margem pequena demais.

Considere uma biblioteca com 25 mil fotos de 6 MB em média. Os originais ocupam aproximadamente 150 GB. Some mil vídeos com média de 250 MB, equivalentes a outros 250 GB. O acervo inicial chega a 400 GB antes dos arquivos derivados. Para planejamento, reservar de 15% a 30% para derivados é uma aproximação prudente até que o comportamento real seja medido. Com mais 25% de espaço livre para manutenção e crescimento, esse caso pede algo próximo de 600 GB utilizáveis, não apenas 400 GB.

Espaço para arquivos derivados

A proporção varia conforme resolução, duração, codec e política de transcodificação. Uma coleção quase toda composta por fotos pode gerar derivados relativamente pequenos. Um conjunto com vídeos longos pode crescer muito mais. Após uma importação de teste com 5% do acervo, compare o uso de du -sh nas pastas persistentes e projete a expansão. Também acompanhe df -h, pois um banco sem espaço para gravar pode deixar a aplicação indisponível.

SSD, NVMe e volumes separados

O PostgreSQL e os diretórios de trabalho se beneficiam de baixa latência e boas operações aleatórias. NVMe pode reduzir filas de I/O, mas a etiqueta NVMe não garante desempenho constante em infraestrutura compartilhada. Uma arquitetura comum usa 60 a 100 GB de disco rápido para sistema, banco e contêineres, com um volume de 500 GB ou mais para a biblioteca. Confirme se o volume pode ser expandido sem recriação e se o snapshot cobre discos adicionais.

Armazenamento compatível com S3 pode funcionar como destino de cópia ou camada auxiliar, desde que a estratégia respeite o suporte oficial do Immich. Ele não deve substituir silenciosamente o sistema de arquivos principal sem validação. O artigo sobre MinIO e armazenamento S3 compatível em VPS ajuda a avaliar essa camada, incluindo versionamento, capacidade e risco operacional.

Rede, localização e tempo de upload

A localização do datacenter afeta a resposta percebida ao abrir álbuns, buscar imagens e carregar miniaturas. Para usuários no Brasil, um servidor no país costuma reduzir a latência em comparação com regiões distantes, mas isso não garante maior velocidade de transferência. Rota da operadora, capacidade da porta, congestionamento e limite mensal de tráfego também pesam. A decisão deve combinar medições de rede com o custo e a disponibilidade de armazenamento.

Uma foto de 8 MB enviada por uma conexão doméstica de 20 Mbps de upload leva pouco mais de três segundos em uma condição ideal. Mil fotos desse tamanho representam 8 GB e exigiriam cerca de 53 minutos apenas pela divisão matemática. Retransmissões, criptografia e concorrência com outros dispositivos ampliam o tempo. Para uma carga inicial de 500 GB a 100 Mbps efetivos, o limite teórico fica próximo de 11 horas. A 30 Mbps, sobe para aproximadamente 37 horas.

Latência percebida no aplicativo

Uma latência de 20 ms ou 30 ms ajuda nas interações com várias requisições pequenas. Ela importa menos durante uma transferência contínua de centenas de gigabytes, na qual throughput e estabilidade dominam. Por isso, teste os dois comportamentos. Faça upload de um conjunto de 5 GB e navegue por um álbum enquanto as tarefas de segundo plano estão ativas. O teste mostra se CPU, disco ou rede vira o gargalo primeiro.

Bandwidth e restauração

Leia as condições do plano para descobrir a franquia mensal, a velocidade nominal da porta e o tratamento dado ao tráfego excedente. Uma biblioteca de 1 TB restaurada duas vezes no mesmo mês pode consumir mais banda do que o uso normal de um ano. Backups externos também geram tráfego contínuo. Se forem enviados 10 GB por dia, serão aproximadamente 300 GB mensais apenas nessa rotina.

Não escolha uma região apenas pela proximidade. Um datacenter remoto com rota estável e banda suficiente pode funcionar melhor que uma opção local congestionada. Sempre que possível, rode ping, mtr e uma transferência real a partir das redes usadas pelos celulares e computadores da equipe.

Backup do Immich sem falsa sensação de segurança

Um snapshot isolado da VPS não constitui uma estratégia completa. Ele pode estar no mesmo domínio de falha do servidor, ter retenção curta ou não produzir um estado consistente do PostgreSQL. O backup do Immich precisa considerar três grupos: arquivos da biblioteca, banco de dados e configuração de implantação. Sem o banco, os originais podem sobreviver, mas álbuns, usuários, relações e metadados gerenciados pela aplicação podem não ser recuperados de forma íntegra.

A regra 3-2-1 continua útil: três cópias, em pelo menos dois tipos ou sistemas de armazenamento, com uma cópia fora da infraestrutura principal. Um exemplo doméstico seria manter a biblioteca ativa na VPS, uma cópia versionada em um NAS local e outra em armazenamento de objetos. Uma pequena empresa pode usar volume primário, backup diário em região distinta e exportação periódica para mídia controlada pela organização.

O que precisa entrar no backup

Inclua um dump lógico ou o método recomendado pela documentação oficial para o PostgreSQL, os diretórios persistentes indicados pelo Immich, o arquivo Compose e uma cópia protegida das variáveis necessárias à recuperação. Segredos não devem ser publicados em repositórios nem inseridos diretamente em scripts compartilhados. O backup do banco e dos arquivos precisa representar uma janela compatível. Copiar arquivos hoje e restaurar um banco de três semanas atrás pode criar registros ausentes ou referências inconsistentes.

Para uma biblioteca de 600 GB que muda pouco, faça backup incremental diário dos arquivos e retenha múltiplas versões. Gere cópias regulares do banco com retenção diária, semanal e mensal. Se o acervo recebe 20 GB por semana, monitore o destino para que a retenção não consuma todo o espaço. O conteúdo sobre VPS com backup automático explica como separar snapshots, cópias agendadas e retenção, sem tratar esses mecanismos como equivalentes.

Como testar uma restauração

A cada mês ou trimestre, restaure o banco e uma amostra da biblioteca em um diretório isolado. Em intervalos maiores, recrie o serviço inteiro em outra VPS. Confirme login, abertura de álbuns, busca e reprodução de vídeos. Registre o tempo gasto. Se 1 TB leva dois dias para retornar, esse prazo precisa fazer parte do plano de continuidade, mesmo que todos os arquivos estejam preservados.

Implantação, segurança e manutenção

A instalação oficial baseada em Docker Compose simplifica a reprodução do ambiente, mas não elimina trabalho operacional. A VPS precisa de um sistema Linux suportado, Docker atualizado, DNS, HTTPS, firewall e monitoramento básico. Antes da primeira carga, confirme os caminhos dos volumes persistentes. Um erro de montagem pode gravar centenas de gigabytes no disco do sistema e lotá-lo durante a madrugada.

Comece com uma instalação limpa e um lote pequeno de teste. Execute docker compose ps para verificar o estado dos serviços, docker compose logs --since 30m para analisar falhas recentes e df -h para acompanhar volumes. Importe mil fotos e alguns vídeos de codecs diferentes. Depois, reinicie a pilha e confirme se os dados permanecem. Esse teste simples identifica permissões, volumes efêmeros e limites de disco antes da migração completa.

Docker Compose e exposição segura

Não exponha PostgreSQL ou componentes internos diretamente à internet. Publique apenas o ponto de entrada necessário, de preferência atrás de um proxy reverso com TLS. Restrinja o acesso SSH por chave, desative autenticação por senha quando a operação permitir e aplique firewall para liberar somente portas indispensáveis. O painel do provedor e o registrador de domínio também devem usar autenticação multifator.

Uma VPN como WireGuard ou Tailscale pode limitar o acesso a uma instalação privada. Para compartilhamento com familiares fora da VPN, use HTTPS público, atualizações frequentes e controles de conta. Proteção de borda reduz ruído automatizado, mas não corrige uma aplicação desatualizada ou credenciais fracas.

Atualizações sem improviso

Não use comandos automáticos que atualizem todos os contêineres sem leitura das notas da versão. Registre a versão em uso, faça backup do banco e verifique mudanças de configuração antes de baixar novas imagens. Em uma atualização relevante, clone a implantação em uma VPS temporária ou restaure uma cópia reduzida para testar.

Monitore disponibilidade, ocupação de disco, memória e falhas de backup. Alertas em 70%, 80% e 90% de uso permitem agir antes de o volume lotar. Uma janela mensal de manutenção para atualizar o sistema, validar backups e revisar logs costuma ser suficiente para ambientes pequenos.

Comparação de recursos por tamanho de biblioteca

A tabela abaixo organiza configurações de referência por perfil. Ela não associa desempenho garantido a um provedor específico, pois vCPUs compartilhadas podem variar de comportamento e o volume de vídeos altera bastante a carga. Os números servem para filtrar planos e criar uma margem inicial. Após a implantação, métricas reais devem orientar ajustes.

Perfil	Biblioteca estimada	CPU e RAM sugeridas	Disco de sistema e banco	Volume da biblioteca	Rede e backup recomendados
Laboratório pessoal	Até 100 GB e 1 usuário	2 vCPUs, 4 GB de RAM	50 a 80 GB SSD	150 a 250 GB	Porta de 100 Mbps ou mais, backup diário fora da VPS
Família	100 a 750 GB e 2 a 6 usuários	4 vCPUs, 8 GB de RAM	80 a 120 GB SSD ou NVMe	500 GB a 1 TB expansível	Franquia compatível com uploads, cópia incremental e teste trimestral
Equipe pequena	750 GB a 2 TB e até 15 usuários	8 vCPUs, 16 GB de RAM	120 a 200 GB NVMe	2 a 3 TB em volume separado	Porta de 1 Gbps, monitoramento e backup em região distinta
Acervo intensivo em vídeo	A partir de 1 TB	8 a 16 vCPUs, 16 a 32 GB de RAM	150 GB ou mais em disco rápido	Capacidade calculada com derivados e 25% livre	Alta franquia, restauração ensaiada e avaliação de aceleração por hardware

Como usar a tabela

Uma biblioteca de 300 GB composta quase toda por fotos pode começar no perfil familiar. Se os usuários importam apenas 5 GB por mês, um volume de 500 GB ainda oferece margem por algum tempo. Já 300 GB de vídeos 4K podem exigir o perfil superior por causa da transcodificação, mesmo com a mesma capacidade ocupada.

Separe capacidade de crescimento de potência computacional. É possível aumentar o volume para 2 TB sem dobrar a RAM, desde que o número de usuários e a carga de processamento permaneçam baixos. O inverso também ocorre: uma equipe que importa 100 mil fotos em poucos dias pode precisar de mais CPU temporariamente, embora o acervo final ocupe menos de 1 TB. Provedores com redimensionamento simples ajudam nesses picos, mas é preciso confirmar se a redução posterior de CPU e RAM é permitida e se o disco pode ser reduzido, algo que geralmente possui restrições.

Recomendações por perfil

A escolha final deve combinar carga de trabalho, tolerância a indisponibilidade e capacidade de administrar Linux. Immich self-hosted entrega controle sobre os dados, mas transfere para o responsável tarefas como atualização, backup, segurança e investigação de falhas. Quem não consegue reservar tempo para isso deve considerar uma implantação gerenciada por um profissional, mesmo que o servidor continue sob controle próprio.

Dev solo e laboratório doméstico

Para aprender e manter até 100 GB, comece com 2 vCPUs, 4 GB de RAM e 80 GB de SSD para o sistema. Use um volume de 200 GB para a biblioteca e mantenha uma cópia dos originais em outro equipamento. Importe primeiro 10 GB, observe docker stats e meça quanto espaço os derivados consomem. Se houver swap constante ou a interface travar durante a indexação, passe para 8 GB antes de adicionar otimizações complexas. Esse perfil aceita manutenção manual e alguma indisponibilidade, mas ainda precisa de backup do banco. Um snapshot semanal não cobre exclusões acidentais ocorridas antes da captura.

Família ou pequena equipe

Para dois a seis usuários, 4 vCPUs e 8 GB de RAM formam uma base mais equilibrada. Reserve de 80 a 120 GB para sistema e banco, além de um volume expansível calculado para dois ou três anos de crescimento. Se o acervo atual tem 400 GB e cresce 15 GB por mês, serão mais 360 GB em dois anos, antes de derivados e folga. Nesse caso, 1 TB é mais coerente do que 500 GB. Configure upload incremental, alertas de disco e backup externo diário. Teste o acesso a partir de Wi-Fi, 4G e redes de operadoras diferentes, pois a experiência dos familiares depende do caminho completo até o datacenter.

Produção com crescimento contínuo

Uma instalação usada como serviço interno, com até 15 usuários e importações regulares, pode começar com 8 vCPUs, 16 GB de RAM, 150 GB de NVMe para sistema e banco e 2 TB ou mais para a biblioteca. Separe ambientes de teste e produção. Antes de cada atualização relevante, restaure uma cópia recente no ambiente de teste e valide login, busca, upload e reprodução. Monitore tempo de resposta do banco, fila de tarefas, reinicializações de contêineres e crescimento diário do volume.

Nesse perfil, a escolha entre VPS tradicional, Cloud Server e cloud instance deve considerar recuperação e expansão, não apenas o nome comercial. Confirme snapshots, volumes anexáveis, limites de tráfego, região dos backups e procedimento de suporte. Recursos como NVMe, backup automático e snapshots variam por plano e localidade, inclusive entre ofertas do mesmo provedor. Registre as condições verificadas na contratação e revise-as quando houver migração ou renovação.