Vaultwarden em VPS: cofre self-hosted seguro

Resposta direta

Para hospedar Vaultwarden com segurança, escolha uma VPS para Vaultwarden com pelo menos 1 vCPU, 1 GB de RAM, 20 GB de SSD e tráfego estável, mas trate backup, firewall e restauração como requisitos principais, não como extras. O serviço consome poucos recursos em uso normal, porém guarda senhas, tokens, chaves de recuperação e dados de autenticação, então a decisão não deve ser guiada apenas pelo menor preço. Para uso individual, uma instância pequena pode funcionar bem. Para equipe, prefira 2 vCPUs, 2 GB de RAM, snapshots testáveis, backup externo e datacenter próximo dos usuários. Latência baixa melhora a experiência no app e nas extensões do navegador, mas segurança operacional, atualização contínua e plano de recuperação pesam mais que CPU bruta.

Resumo rápido

• Vaultwarden costuma rodar bem com 1 vCPU e 1 GB de RAM para uso individual ou familiar.
• Para equipes, 2 vCPUs, 2 GB de RAM e 40 GB de SSD deixam margem para proxy, logs, monitoramento e backup local temporário.
• O dado mais crítico é o volume persistente, geralmente o diretório data, onde ficam banco SQLite, anexos e configurações.
• Use HTTPS obrigatório, firewall restritivo, SSH por chave e atualizações automáticas de segurança no sistema operacional.
• Backup sem teste de restauração é só uma esperança. Agende cópias externas e valide a recuperação em outra instância.
• Snapshots ajudam em rollback rápido após atualização, mas não substituem backup versionado fora da VPS.
• Datacenter no Brasil ou próximo do público reduz latência nas extensões, apps móveis e sincronização entre dispositivos.
• Provedores e planos mudam com frequência. Preço, região, tipo de disco, backup e snapshots precisam ser conferidos nas páginas oficiais antes da contratação.

Por que rodar Vaultwarden em uma VPS própria

Vaultwarden é uma implementação leve e compatível com clientes Bitwarden, muito usada por quem quer um gerenciador de senhas self-hosted sem carregar toda a pilha oficial. A vantagem prática é simples: você controla o servidor, o domínio, a política de backup, os logs e o ciclo de atualização. Para um usuário avançado, isso pode significar independência. Para uma pequena empresa, pode significar controle operacional sobre um ativo sensível, desde que exista disciplina técnica.

Vaultwarden não é pesado, mas é sensível

O erro comum é olhar apenas para consumo de CPU. Em repouso, Vaultwarden pode usar pouca memória e quase nada de processamento. Mesmo com Docker, Caddy ou Nginx como proxy reverso e banco SQLite, uma VPS pequena costuma dar conta de poucas dezenas de usuários. O problema é que a aplicação guarda dados de alto impacto. Se o servidor for invadido, ficar sem backup ou perder o volume persistente, o prejuízo não se mede em páginas fora do ar, mas em credenciais, segredos e acesso a outros sistemas.

Pense em um cenário doméstico: 2 usuários, 500 itens no cofre, 5 MB de anexos e sincronização por celular e navegador. A carga é baixa. Agora imagine uma equipe de 25 pessoas usando coleções compartilhadas, anexos, logins frequentes e autenticação em dois fatores. O consumo ainda é modesto, mas a necessidade de logs, backup, controle de acesso e disponibilidade cresce bastante.

VPS tradicional, Cloud Server e instância cloud

Uma VPS tradicional costuma ser uma máquina virtual em um host físico, com recursos definidos por plano. Um Cloud Server normalmente oferece provisionamento mais flexível, painel com snapshots, rede cloud e upgrades menos traumáticos. Já uma instância cloud em provedores globais pode trazer ecossistema maior, regiões variadas e integração com serviços de monitoramento, storage e firewall gerenciado.

Para Vaultwarden, todos os modelos podem funcionar. A diferença aparece na operação. Se você precisa restaurar rápido depois de uma atualização ruim, snapshots importam. Se precisa trocar de plano sem migração manual, elasticidade ajuda. Se o time está no Brasil, uma região local ou próxima reduz atrasos perceptíveis ao desbloquear o cofre e sincronizar extensões.

Requisitos de CPU, RAM, disco e rede para Vaultwarden

Vaultwarden tem perfil de carga previsível. A maior parte das requisições envolve autenticação, leitura e escrita de registros pequenos no banco, sincronização de itens e envio de notificações via WebSocket quando configurado. Isso não exige uma máquina grande, mas exige recursos estáveis. Em gerenciador de senhas, lentidão intermitente passa uma sensação ruim. O usuário abre a extensão para preencher um login e espera resposta quase imediata.

Configuração mínima realista

Para uso individual, familiar ou laboratório bem cuidado, use como ponto de partida 1 vCPU, 1 GB de RAM e 20 GB de SSD. Essa configuração comporta o container do Vaultwarden, um proxy reverso leve, logs moderados e banco SQLite. Se a imagem Docker, o sistema e logs forem mantidos sob controle, 20 GB sobram para anos de uso sem anexos grandes. Com anexos, exportações e backups locais temporários, 40 GB fica mais confortável.

Para uma pequena equipe, o salto natural é 2 vCPUs, 2 GB de RAM e 40 GB a 80 GB de SSD. Não é porque Vaultwarden sozinho precise disso o tempo todo. A folga evita que uma atualização do sistema, uma rotação de logs, um backup compactado ou um proxy com TLS derrube a experiência. Se você usa monitoramento com Prometheus node exporter, agente de logs e ferramentas de segurança, os 2 GB deixam de ser luxo.

Em produção mais séria, considere 2 a 4 vCPUs, 4 GB de RAM, disco SSD ou NVMe e backup externo. NVMe pode acelerar operações de I/O, mas não transforma uma configuração insegura em segura. Para Vaultwarden, a diferença entre SSD e NVMe tende a ser menor que a diferença entre ter ou não backup testado, firewall correto e restauração documentada.

Quando subir recursos

Você deve aumentar recursos quando encontrar sinais concretos: uso de RAM acima de 75 por cento por várias horas, swap constante, load average maior que a quantidade de vCPUs durante picos, latência alta no proxy, banco crescendo rápido por anexos ou logs ocupando disco. Um comando simples ajuda no diagnóstico inicial: docker stats, free -m, df -h e journalctl --disk-usage mostram se o gargalo está no container, na memória, no disco ou nos logs do sistema.

A rede também merece atenção. Vaultwarden não consome muita banda, mas precisa de conexão estável. Para equipes remotas, prefira provedores com boa conectividade para o país de uso. Um servidor nos Estados Unidos pode funcionar, mas usuários no Brasil podem sentir atrasos de 120 ms a 180 ms em operações que parecem pequenas, como desbloquear, sincronizar e pesquisar itens. Em datacenter nacional ou mais próximo, a latência pode cair bastante, dependendo da operadora e da rota.

Segurança: firewall, TLS, SSH e hardening do servidor

Hospedar um cofre de senhas próprio muda a régua de segurança. Não basta subir um container e apontar o domínio. A VPS precisa estar reduzida ao mínimo necessário, com portas controladas, atualizações aplicadas e acesso administrativo bem protegido. Vaultwarden pode ser leve, mas o servidor fica exposto à internet o tempo todo. Bots vão tentar varrer portas, testar credenciais fracas e explorar serviços esquecidos.

Portas, proxy reverso e HTTPS

A configuração mais comum usa Vaultwarden ouvindo internamente na porta 80 do container e um proxy reverso, como Caddy, Nginx Proxy Manager, Traefik ou Nginx puro, terminando TLS nas portas 80 e 443 da VPS. O firewall deve permitir somente o necessário: 22 para SSH, idealmente restrita por IP ou movida para uma política mais rígida, 80 para emissão e renovação do certificado, e 443 para acesso ao cofre. O restante deve ficar fechado.

Se você ainda não tem um padrão de proteção para servidores, vale conectar este projeto a uma rotina de VPS com firewall e hardening de segurança. Na prática, isso significa usar ufw default deny incoming, liberar apenas portas específicas, desabilitar login SSH por senha, criar usuário sem root direto, ativar fail2ban quando fizer sentido e manter pacotes atualizados. Em Ubuntu, um início razoável seria ufw allow 443/tcp, ufw allow 80/tcp, ufw allow from SEU_IP to any port 22 proto tcp e depois ufw enable.

Admin token e acesso restrito

Vaultwarden tem uma área administrativa opcional protegida por ADMIN_TOKEN. Se você habilitar esse recurso, trate o token como segredo de alta sensibilidade. Não use token curto, não salve em repositório Git e não compartilhe por chat. Em muitos ambientes, faz sentido desabilitar o painel administrativo depois da configuração inicial ou restringir o acesso por IP no proxy reverso. Um exemplo no Nginx seria permitir /admin apenas para o IP do escritório ou da VPN.

Outras medidas reduzem o risco: exigir 2FA nas contas, desabilitar novos cadastros públicos com SIGNUPS_ALLOWED=false, configurar domínio SMTP para alertas e convites, revisar organizações e coleções periodicamente, e manter uma conta de emergência com credenciais guardadas offline. Se o cofre for de uma equipe, documente quem pode criar usuários, remover acesso e recuperar dados. Segurança self-hosted não é só comando, também é processo.

Backup, snapshots e restauração do cofre

Backup é a parte menos glamourosa e mais decisiva do Vaultwarden. A aplicação pode ser reinstalada em minutos. O domínio pode ser recriado. O container pode ser baixado novamente. O que não pode desaparecer é o volume persistente, especialmente o banco de dados, anexos, chaves de configuração e arquivos usados pelo serviço. Um projeto self-hosted de senhas sem backup externo testado é frágil, mesmo rodando em uma VPS excelente.

O que precisa ser salvo

Em instalações Docker comuns, o diretório mais importante é algo como /opt/vaultwarden/data. Ali podem estar db.sqlite3, anexos, ícones em cache, arquivos de configuração e dados da aplicação. Se você usa PostgreSQL ou MariaDB em vez de SQLite, o backup precisa incluir dump consistente do banco, não apenas cópia bruta do volume em uso. Para SQLite, pare o container por alguns segundos ou use um método seguro de cópia para evitar arquivo inconsistente. Um fluxo simples seria parar o container, compactar o diretório data, criptografar o arquivo com age ou gpg, enviar para storage externo e subir o serviço novamente.

A frequência depende do uso. Para uso individual, backup diário com retenção de 7 a 30 dias pode bastar. Para equipe, considere backups a cada 6 ou 12 horas, retenção diária por 30 dias e retenção mensal por 6 a 12 meses. Se há muitos anexos, acompanhe crescimento de disco. Exportações manuais de senhas pelos usuários não substituem backup do servidor, porque organizações, coleções e configurações podem se perder.

Rotina prática de recuperação

Snapshots são ótimos para voltar rápido antes de uma atualização do sistema, mas não devem ser a única linha de defesa. Um snapshot fica associado ao provedor e à conta. Se houver bloqueio, erro humano ou falha regional, você precisa de uma cópia externa. Por isso, combine snapshot antes de mudanças importantes com backup versionado fora da VPS. O tema fica mais claro quando você separa VPS com snapshots para recuperação rápida de backup contínuo e independente.

Um teste de restauração precisa ser simples o bastante para virar rotina. Crie uma VPS temporária, instale Docker, restaure o diretório data, suba o mesmo docker-compose.yml e aponte um domínio de teste ou entrada local no arquivo hosts. Verifique login, sincronização, anexos, convites e painel administrativo. Faça isso a cada trimestre ou depois de mudanças grandes. Se você quer escolher provedor pensando nesse processo desde o início, avalie recursos de VPS com backup automático, mas confirme retenção, escopo, custo e possibilidade real de restauração antes de depender do recurso.

Comparação de perfis e provedores para hospedar Vaultwarden

A escolha da VPS para Vaultwarden deve começar pelo perfil de uso, não pelo nome do provedor. Um cofre individual precisa de previsibilidade, backup e baixo custo operacional. Uma equipe pequena precisa de controle de acesso, restauração rápida e folga de recursos. Um ambiente corporativo, mesmo pequeno, precisa de processo: mudança planejada, auditoria, logs, criptografia de backups e documentação para troca de responsáveis.

Tabela de referência

Cenário ou provedor	Configuração de referência	Pontos fortes para Vaultwarden	Atenções antes de contratar
Uso individual em VPS pequena	1 vCPU, 1 GB RAM, 20 GB SSD	Custo baixo, manutenção simples, recursos suficientes para poucos usuários	Backup externo obrigatório, cuidado com swap e logs, evitar painel pesado
Pequena equipe em Cloud Server	2 vCPUs, 2 GB RAM, 40 GB SSD	Folga para proxy, monitoramento, backups temporários e atualizações	Validar snapshots, região, tráfego incluso e política de restauração
Produção crítica com banco externo ou storage separado	2 a 4 vCPUs, 4 GB RAM, 80 GB SSD ou NVMe	Melhor separação de responsabilidades, mais espaço para logs e crescimento	Operação mais complexa, custo maior, exige teste de restore e documentação
DigitalOcean, Vultr, Linode ou Akamai	Planos cloud pequenos e médios, consultar página oficial	Ecossistema maduro, snapshots e regiões variadas conforme oferta	Preços, backup, região e tráfego mudam. Revisão humana necessária antes de publicar comparação
LetsCloud ou provedor com presença próxima ao Brasil	Cloud Server conforme plano disponível	Pode ser interessante por latência para público brasileiro e contratação local, quando aplicável	Confirmar localidade, tipo de disco, backup, snapshots, suporte e preço atual no site oficial

Dados de provedores são voláteis. A tabela usa perfis técnicos e exemplos de mercado, não uma recomendação fechada de preço. Última atualização dos dados de concorrentes e fontes: 2026-07-30. Antes de publicar qualquer comparação comercial, revise páginas oficiais, taxas, regiões, promoções e condições de renovação.

Como ler a tabela sem cair em promessa fácil

Para Vaultwarden, “mais CPU” raramente é a resposta principal. Se a instância trava, investigue primeiro memória, disco cheio, logs, proxy mal configurado, DNS instável ou backup rodando em horário de uso. Um plano com 4 vCPUs não compensa um firewall aberto, um ADMIN_TOKEN fraco ou um backup salvo apenas dentro da própria VPS. Da mesma forma, NVMe ajuda em I/O, mas a maior parte das instalações pequenas usa pouco disco por requisição.

Ao comparar provedores, faça perguntas objetivas. Existe snapshot sob demanda? Backup automático inclui todos os discos ou só o disco principal? A restauração cria nova instância ou sobrescreve a atual? Há região no Brasil, Miami ou outra localidade com boa rota para seus usuários? O painel permite console de emergência? Existe bloqueio de porta 25 que afete SMTP? A resposta a essas perguntas vale mais que uma diferença pequena de preço mensal.

Exemplo prático de configuração com Docker

Docker é a forma mais comum de instalar Vaultwarden em VPS, porque simplifica atualização, isolamento e portabilidade. Ainda assim, a simplicidade pode enganar. O arquivo docker-compose.yml precisa cuidar de volume persistente, variáveis de ambiente, reinício automático e integração com proxy. O segredo é separar o que pode ser recriado do que precisa sobreviver. Container pode morrer. Volume de dados não.

Compose básico com volumes persistentes

Um exemplo mínimo ficaria assim, assumindo que o proxy reverso está em outro container ou no host:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://cofre.exemplo.com"
      SIGNUPS_ALLOWED: "false"
      WEBSOCKET_ENABLED: "true"
    volumes:
      - /opt/vaultwarden/data:/data
    ports:
      - "127.0.0.1:8080:80"

A porta publicada em 127.0.0.1:8080 impede acesso direto externo ao container. O Nginx, Caddy ou Traefik recebe tráfego HTTPS na porta 443 e encaminha internamente para http://127.0.0.1:8080. Essa abordagem evita expor o serviço sem TLS por acidente. Para Caddy, um bloco simples poderia usar reverse_proxy 127.0.0.1:8080, com certificado automático via ACME. Para Nginx, configure proxy_set_header Host, X-Real-IP, X-Forwarded-For e X-Forwarded-Proto.

Não coloque segredos reais no exemplo versionado. Se usar ADMIN_TOKEN, prefira arquivo .env fora do repositório e permissões restritas, como chmod 600 .env. Para gerar um token forte, use ferramenta local segura, por exemplo openssl rand -base64 48, mas nunca publique o valor em documentação, issue, print de tela ou repositório.

Cuidados depois do primeiro deploy

Depois de subir, teste o domínio em HTTPS, crie a primeira conta, desabilite cadastro público e configure 2FA. Em seguida, verifique logs com docker logs vaultwarden --tail=100, uso de recursos com docker stats e espaço em disco com df -h. Se o proxy estiver correto, acessos externos devem aparecer na porta 443, não diretamente na porta do container.

Atualização também precisa de método. Antes de rodar docker compose pull e docker compose up -d, faça snapshot ou backup. Leia notas da versão quando houver mudança relevante. Em ambientes de equipe, agende janela curta, avise usuários e mantenha plano de rollback. Se algo quebrar, a sequência ideal é restaurar snapshot recente ou subir uma instância paralela com o backup do diretório data, testar login e só então apontar DNS.

Monitoramento simples já ajuda muito. Configure alerta de disco acima de 80 por cento, verificação HTTP do domínio a cada minuto e aviso se o certificado TLS estiver perto de expirar. Ferramentas como Uptime Kuma, Netdata, Grafana Agent ou alertas do próprio provedor podem cobrir esse básico. O objetivo não é montar uma plataforma complexa, mas descobrir problemas antes que a equipe perceba no momento de acessar uma senha urgente.

Recomendações por perfil

Dev solo ou usuário avançado

Para um dev solo, a melhor VPS para Vaultwarden costuma ser pequena, previsível e fácil de restaurar. Comece com 1 vCPU, 1 GB de RAM e 20 GB de SSD, usando Docker, Caddy ou Nginx e banco SQLite. Essa configuração atende bem um cofre pessoal, desde que você não transforme a VPS em servidor multiuso cheio de serviços paralelos. O maior risco é negligenciar backup porque “é só para mim”. Agende backup diário criptografado para um destino externo, mantenha uma cópia local ocasional e teste restauração em uma máquina temporária. Use SSH por chave, 2FA no cofre e cadastro público desativado.

Pequena equipe

Para uma equipe de 5 a 30 pessoas, suba a base para 2 vCPUs, 2 GB de RAM e 40 GB de SSD. A carga do Vaultwarden ainda não é alta, mas a operação precisa de margem. Você provavelmente terá convites, coleções compartilhadas, mudanças de acesso, anexos e mais dependência do serviço durante o expediente. Nessa fase, o ideal é ter snapshot antes de atualização, backup externo com retenção, monitoramento HTTP e alerta de disco. Também faz sentido restringir o painel administrativo por IP ou VPN. Se a equipe está no Brasil, teste latência de provedores com região nacional ou próxima, porque extensões de navegador ficam mais agradáveis quando a resposta é rápida.

Produção com dependência crítica

Quando o cofre vira peça crítica da operação, trate Vaultwarden como serviço de infraestrutura. Use 2 a 4 vCPUs, 4 GB de RAM, 80 GB de disco e rotina documentada de incidentes. Avalie separar banco, backup e monitoramento, mas não complique sem necessidade. O ganho real vem de processo: responsáveis definidos, rotação de credenciais, restauração testada, atualizações planejadas e auditoria de acesso. Para esse perfil, escolha provedor com painel confiável, console de emergência, snapshots, backup claro e região adequada. Qualquer dado de preço, SLA, localidade e armazenamento deve ser validado no site oficial antes de virar decisão final.

Checklist final antes de colocar o cofre em produção

Antes de usar Vaultwarden como cofre principal, faça uma revisão sem pressa. A aplicação pode estar funcionando no navegador e ainda assim faltar o essencial. O primeiro ponto é domínio e TLS. Acesse por HTTPS, confirme certificado válido e verifique se HTTP redireciona corretamente. Depois, confira o firewall: somente 80, 443 e SSH restrito devem estar expostos, salvo exceções justificadas. Use ss -tulpn para ver serviços ouvindo e um scanner externo confiável para confirmar a superfície pública.

O segundo ponto é persistência. Reinicie a VPS, suba os containers e verifique se os dados continuam disponíveis. Parece básico, mas muitos incidentes começam com volume Docker mal montado. Confirme que /opt/vaultwarden/data ou diretório equivalente existe no host, tem permissões adequadas e entra no backup. Rode uma cópia manual, criptografe, envie para fora da VPS e restaure em ambiente separado. Se você não sabe restaurar, ainda não tem backup de verdade.

O terceiro ponto é política de acesso. Desative cadastro público com SIGNUPS_ALLOWED=false, exija 2FA nas contas importantes, revise organizações e limite administradores. Se o painel /admin estiver ativo, proteja por IP, VPN ou desative quando não estiver em uso. Registre onde ficam as credenciais de emergência e quem pode usá-las. Em equipe, crie um procedimento simples para desligamento de colaborador: remover acesso, transferir coleções quando necessário e revisar itens compartilhados.

Por fim, monitore o básico. Alerta de disponibilidade, disco, CPU, memória e validade do certificado cobre a maior parte dos problemas pequenos antes que virem incidente. Agende atualização mensal do sistema e atualização controlada do container. Não rode dezenas de aplicações na mesma VPS do cofre se você não consegue isolar riscos. Um gerenciador de senhas self-hosted é perfeitamente viável, mas pede maturidade operacional proporcional ao valor dos segredos que ele guarda.