Vaultwarden ou Bitwarden self-hosted: qual escolher?

O que o Vaultwarden e o Bitwarden self-hosted realmente são

Vaultwarden vs Bitwarden self-hosted é uma escolha entre dois servidores que falam a mesma API de cliente, não uma escolha entre dois gestores de palavras-passe. A stack oficial do Bitwarden executa cerca de uma dúzia de contentores atrás do nginx, armazena tudo no Microsoft SQL Server e está associada a um ID de instalação que regista com um endereço de e-mail. O Vaultwarden é uma reimplementação não oficial da API de cliente do Bitwarden, escrita em Rust, que executa como um único contentor e utiliza um único ficheiro SQLite. A extensão do navegador e o telefone não conseguem distingui-los, porque ambos respondem aos mesmos endpoints.

A encriptação é idêntica nos dois casos. Os clientes Bitwarden encriptam o cofre antes de qualquer dado sair do dispositivo. Por isso, o servidor armazena blobs que não consegue ler, e o formato do cofre pertence ao Bitwarden em ambos os casos. O que muda é a quantidade de recursos que precisa de alugar, quem mantém o código, quais funcionalidades têm custos e o que precisa de incluir nas cópias de segurança.

O README do Vaultwarden é claro sobre o seu estado: "This project is not associated with Bitwarden or Bitwarden, Inc." É um projeto mantido por voluntários, sem serviço de suporte e sem garantia. Um dos maintainers ativos trabalha na Bitwarden e contribui no seu tempo pessoal. Isso é uma cortesia, não um endosso.

As três stacks que você pode instalar

Muitas comparações não consideram que a Bitwarden oferece dois produtos self-hosted diferentes.

Bitwarden standard. A implantação do fornecedor, executada por um script shell.

curl -Lso bitwarden.sh "https://func.bitwarden.com/api/dl/?app=self-host&platform=linux" \
  && chmod 700 bitwarden.sh
./bitwarden.sh install

O instalador solicita seu domínio, se deve solicitar um certificado Let's Encrypt, um ID e uma chave de instalação que você obtém em https://bitwarden.com/host informando um endereço de email, e sua região (US ou EU). Em seguida, ./bitwarden.sh start baixa as imagens e inicia a stack. A Bitwarden documenta 2 GB de RAM e 12 GB de armazenamento como requisitos mínimos, 4 GB e 25 GB como valores recomendados, além do Docker Engine 26 ou mais recente com o plugin Compose. O banco de dados é uma imagem MSSQL Express, que a Bitwarden documenta como tendo um tamanho máximo de banco de dados relacional de 10 GB. Se isso for insuficiente, você pode apontar a implantação para um banco de dados externo.

Bitwarden lite. Esta é a implantação que antes se chamava Bitwarden Unified. Ela saiu da fase beta e foi renomeada em dezembro de 2025. Um contêiner de aplicação e um banco de dados à sua escolha:

services:
  bitwarden:
    depends_on:
      - db
    env_file:
      - settings.env
    image: ghcr.io/bitwarden/lite
    restart: always
    ports:
      - "80:8080"
    volumes:
      - bitwarden:/etc/bitwarden
  db:
    environment:
      MARIADB_USER: "bitwarden"
      MARIADB_PASSWORD: "super_strong_password"
      MARIADB_DATABASE: "bitwarden_vault"
      MARIADB_RANDOM_ROOT_PASSWORD: "true"
    image: mariadb:10
    restart: always
    volumes:
      - data:/var/lib/mysql
volumes:
  bitwarden:
  data:

Ela aceita MariaDB ou MySQL, PostgreSQL, SQLite e MSSQL, e solicita 200 MB de RAM e 1 GB de armazenamento. Duas ressalvas vêm da própria documentação da Bitwarden. Ela é documentada para uso pessoal e home labs, não para uso empresarial, e não faz backups automáticos do banco de dados. Portanto, essa tarefa é inteiramente sua.

Vaultwarden. Um contêiner, diretamente do README do projeto:

docker run --detach --name vaultwarden \
  --env DOMAIN="https://vw.domain.tld" \
  --volume /vw-data/:/data/ \
  --restart unless-stopped \
  --publish 127.0.0.1:8000:80 \
  vaultwarden/server:latest

A linha publish associa a porta 8000 somente ao loopback, e isso é intencional. O Vaultwarden oferece HTTP sem criptografia e espera que um reverse proxy faça a terminação TLS (transport layer security) na frente dele. O TLS não é opcional neste caso: o web vault faz a criptografia usando a WebCrypto API do navegador, que os navegadores expõem somente em um contexto seguro. Por isso, com http sem criptografia, a página de login falha no navegador antes mesmo de solicitar qualquer coisa ao servidor. O guia completo de instalação do Vaultwarden explica a configuração do proxy e do certificado.

Quanta RAM o Vaultwarden usa em comparação com o Bitwarden self-hosted?

Os requisitos mínimos indicados pelo fornecedor mostram abaixo de que limite o instalador recusa executar, não quanto espaço o software ocupa. As linhas abaixo vêm de docker stats --no-stream em instalações inativas, com um utilizador cada, um cofre pequeno e sem anexos, numa máquina Ubuntu 24.04 com 4 GB de RAM. O espaço em disco corresponde às imagens mais o diretório de dados depois do primeiro arranque bem-sucedido.

[
  {
    "label": "Vaultwarden (SQLite)",
    "idle_ram_mb": 58,
    "containers": 1,
    "disk_gb": 0.4
  },
  {
    "label": "Bitwarden lite + MariaDB",
    "idle_ram_mb": 470,
    "containers": 2,
    "disk_gb": 1.6
  },
  {
    "label": "Bitwarden standard (MSSQL)",
    "idle_ram_mb": "2,400",
    "containers": 12,
    "disk_gb": 6.5
  }
]

O Vaultwarden manteve-se em 58 MB em inatividade, num único contentor. A stack padrão do Bitwarden manteve-se perto de 2,400 MB em 12 contentores, e o contentor MSSQL representa a maior parte desse consumo. O Bitwarden lite ficou entre os dois, com 470 MB e o respetivo contentor MariaDB. Execute o mesmo comando na sua própria máquina antes de confiar nestes valores, porque eles variam com o número de utilizadores, os anexos e o tráfego de sincronização, e o MSSQL aumenta o conjunto de trabalho quanto mais tempo estiver em execução.

Para um VPS pequeno, a conclusão prática é esta: o Vaultwarden com SQLite funciona confortavelmente num plano de 1 GB, mas a stack padrão do Bitwarden não arranca nesse plano. Num plano de 2 GB, a stack padrão cumpre o mínimo documentado e deixa muito pouca memória para o sistema operativo, pelo que o out-of-memory killer do kernel passa a ser um risco real. Quando é acionado, dmesg imprime uma linha com o processo que terminou e, nesta stack, esse processo costuma ser sqlservr. Atribua 4 GB à implementação padrão. Se o mesmo VPS também tiver de alojar mais do que um cofre, calcule os requisitos mínimos dos outros serviços antes de escolher o plano, porque um servidor de fotografias como o PhotoPrism ou o Immich precisa de muito mais memória do que o Vaultwarden. No entanto, nem todos os serviços vizinhos consomem tanto: algo como o Halcyon, que transforma uma biblioteca Jellyfin numa loja de aluguer dos anos 90 é um frontend no browser que depende do servidor multimédia indicado, em vez de trazer a sua própria base de dados. A memória também não é o único requisito mínimo que deve verificar, porque um relay RustDesk para sessões de ambiente de trabalho remoto quase não aparece em docker stats e depois consome a largura de banda incluída no seu plano.

Quais funcionalidades pagas são gratuitas no Vaultwarden?

Executar o servidor do Bitwarden não tem custos, mas as funcionalidades pagas permanecem bloqueadas até carregar um ficheiro de licença. As contas individuais Premium e os planos de organização pagos que podem ser alojados por si, Families e Enterprise (o Bitwarden não oferece a opção de alojamento próprio para Teams), precisam desse ficheiro. Pode descarregá-lo do cofre web na cloud, em Settings e depois Subscription para uma conta individual, ou na Admin Console, em Billing e depois Subscription, para uma organização, e carregá-lo na sua própria instância. As licenças de organizações são emitidas com base no ID de instalação armazenado em ./bwdata/env/global.override.env. Assim, uma organização alojada por si continua a ter uma subscrição paga e continua a contactar a cloud do Bitwarden para efeitos de faturação.

O Vaultwarden ativa as mesmas funcionalidades sem licença e sem subscrição. O wiki do projeto lista-as:

• organizações, coleções e grupos
• anexos de ficheiros
• início de sessão em duas etapas com email, Duo, YubiKey e FIDO2
• Emergency Access
• Bitwarden Send
• chaves de API pessoais
• SSO através de OpenID Connect

O SSO é a mais recente destas funcionalidades e é configurado com SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID e SSO_CLIENT_SECRET. Apenas autentica o início de sessão. O wiki indica explicitamente que continua a ser necessária uma palavra-passe principal e que esta não é controlada pelo fornecedor de identidade, porque essa palavra-passe deriva a chave que desencripta o cofre. Aponte SSO_AUTHORITY para o emissor de descoberta de um fornecedor de identidade Authentik alojado por si para que os utilizadores iniciem sessão nesse serviço e, em seguida, desbloqueiem o cofre com a palavra-passe principal. O valor tem de corresponder ao campo issuer devolvido pelo endpoint de descoberta, sem o sufixo /.well-known/openid-configuration no final.

O que não obtém com o Vaultwarden é um fornecedor. O Bitwarden possui as certificações SOC 2 Type 2 e ISO 27001, publica relatórios de auditorias realizadas por terceiros e mantém um programa privado de recompensa por vulnerabilidades no HackerOne. Estas garantias abrangem o código e o serviço do Bitwarden, não o servidor que instalou, mas, se um auditor exigir um fornecedor identificado por trás do seu gestor de palavras-passe, uma reimplementação mantida por voluntários é difícil de justificar.

Os aplicativos oficiais do Bitwarden funcionam com o Vaultwarden?

Sim. O Vaultwarden implementa a API de cliente, por isso as extensões do navegador, os aplicativos para desktop, os aplicativos móveis e o cofre web incluído funcionam com ele. Em cada cliente, defina o URL do servidor self-hosted no ecrã de ambiente antes de iniciar sessão, e não depois.

É necessária configuração adicional para uma funcionalidade: as notificações push para os aplicativos móveis. Sem elas, o aplicativo sincroniza quando é aberto ou de acordo com o seu próprio temporizador. Por isso, uma palavra-passe alterada no portátil não aparece no telemóvel até abrir o aplicativo. O Vaultwarden pode usar o relay push do Bitwarden. Para isso, precisa de um ID de instalação e de uma chave obtidos na mesma página https://bitwarden.com/host que o instalador oficial utiliza.

PUSH_ENABLED=true
PUSH_INSTALLATION_ID=<your installation id>
PUSH_INSTALLATION_KEY=<your installation key>

Os servidores na região da UE também precisam de PUSH_RELAY_URI=https://api.bitwarden.eu e PUSH_IDENTITY_URI=https://identity.bitwarden.eu. A wiki documenta duas situações que deve conhecer antes de passar uma hora a investigar o problema. Um aplicativo instalado a partir do F-Droid ou da Neo Store não tem suporte para Firebase e nunca receberá notificações push, independentemente do que o servidor fizer. Um aplicativo que tenha estabelecido ligação antes do Vaultwarden 1.30.2 precisa de ter os seus dados apagados para poder registar um token push.

Quão segura é uma reimplementação?

O histórico de auditorias do Bitwarden é longo e público. A Cure53 analisou-o em 2018, 2021, 2022, 2023, 2024 e 2025. A análise de 2025 abrangeu a extensão do navegador e a sobreposição de preenchimento automático, a aplicação principal, a aplicação de desktop, o cofre Web e o crate e a biblioteca RustCrypto. A IOActive e a Mandiant analisaram clientes em 2024. A Fracture Labs realizou avaliações Web e de rede em 2024 e 2025. A Unit 42 avaliou as aplicações móveis em 2025. O Applied Cryptography Group da ETH Zurich analisou a criptografia em 2025.

O Vaultwarden também foi analisado por entidades externas, o que surpreende quem presume que ninguém o verifica. O Federal Office for Information Security (BSI) da Alemanha contratou a mgm security partners para o testar entre fevereiro e maio de 2024, no âmbito do projeto de análise de código Caos 3.0. Essa análise classificou duas descobertas como de gravidade alta. Separadamente, a ERNW comunicou uma falha de bypass de autenticação que afetava versões anteriores à 1.32.5 (CVE-2024-55225), corrigida em novembro de 2024. A versão 1.37.0, lançada em julho de 2026, corrigiu SSRF (server side request forgery) através do endpoint de ícones, acesso entre organizações a cifras e um bypass da política da organização durante importações de diretórios. A versão 1.37.4, lançada em outubro de 2026, corrigiu outro conjunto de problemas. O principal era uma falha de gravidade alta na revogação de membros de organizações. O conjunto também incluía problemas na autenticação de dois fatores, nos convites de organizações e nos anexos.

Este histórico mostra um projeto com um processo de comunicação de vulnerabilidades funcional. Também aponta para a superfície que aparece repetidamente: a página de administração. Trate essa página como o componente sensível que é. Ela permanece desativada enquanto ADMIN_TOKEN não estiver definido. Deve armazenar um hash, não o token em texto simples.

docker run --rm -it vaultwarden/server /vaultwarden hash

Isto imprime uma string PHC do Argon2 (password hashing competition format) para colar em ADMIN_TOKEN. Ative HTTPS antes de ativar a página de administração. O token é enviado no pedido, e um token em texto simples numa ligação HTTP simples pode ser lido por qualquer componente no caminho. O risco prático está nesse token e no ficheiro de backup, não na criptografia. Uma revisão de hardening numa instância em execução trata dos dois aspetos. Mantenha /admin fora da Internet pública sempre que possível e combine-o com hardening normal do host, como restringir o acesso SSH no servidor.

O que falha quando a API oficial muda

Este é o risco que as pessoas subestimam. A Bitwarden distribui os clientes, e esses clientes são atualizados automaticamente pelas lojas de aplicativos durante a noite. O Vaultwarden precisa acompanhá-los. Quando uma versão do cliente altera o contrato da API, um Vaultwarden não atualizado encontra um cliente que já mudou, e os logins ou a sincronização começam a falhar nos dispositivos que você não alterou.

As notas da versão trazem um exemplo concreto. O Vaultwarden 1.37.0 informa: "Esta atualização é necessária para oferecer suporte a clientes com a versão 2026.7.0 ou posterior; atualize antes de relatar qualquer problema com eles." Um mês depois, o 1.37.2, publicado em 22 de agosto de 2026, repetiu o aviso para clientes na versão 2026.8.0 e posteriores. Portanto, um servidor deixado na versão 1.37.0 ou 1.37.1 já está atrás dos aplicativos. Em 27 de outubro de 2026, a versão atual é a 1.37.4, publicada em 5 de outubro de 2026, depois da 1.37.3, publicada em 13 de setembro de 2026.

Dois hábitos mantêm esse problema sob controle. Fixe uma tag de imagem específica em vez de latest, para que um pull não supervisionado não atualize seu servidor às 3am. Depois, monitore o feed de versões e atualize deliberadamente, lendo primeiro as notas, porque é nelas que as alterações incompatíveis são anunciadas. O aviso da versão 1.37.2 também foi publicado no GitHub Discussions do projeto, junto com as etapas de recuperação para clientes que ainda apresentam problemas depois da atualização do servidor: sair e entrar novamente, limpar o cache do aplicativo ou da extensão e reinstalar o aplicativo móvel ou a extensão somente como último recurso. A versão 1.35.5, por exemplo, invalidou todos os tokens existentes de lembrança da autenticação de dois fatores durante a atualização, fazendo com que as pessoas saíssem de uma etapa que pensavam ter salvado.

A implantação padrão da Bitwarden tem o problema inverso. As atualizações são executadas por meio de ./bitwarden.sh updateself e ./bitwarden.sh update, e a atualização aplica migrações ao banco de dados. Um backup feito antes da migração não reverte o schema posterior. Portanto, faça o backup e registre a versão em que ele foi criado.

Backups, onde as pessoas realmente perdem os cofres

O diretório de dados do Vaultwarden é o servidor. Preserve estes itens:

• db.sqlite3
• todos os ficheiros rsa_key*, incluindo rsa_key.pem e rsa_key.der
• attachments/
• config.json
• sends/

Não copie db.sqlite3 com cp enquanto o contentor estiver em execução. O SQLite pode estar a escrever nesse momento, pelo que a cópia pode ser uma base de dados corrompida que parece correta até ser restaurada. Use a API de backup online:

sqlite3 data/db.sqlite3 ".backup '/path/to/backups/db-$(date '+%Y%m%d-%H%M').sqlite3'"

Desde a versão 1.32.1, a imagem também inclui o comando /vaultwarden backup. Em ambos os casos, o snapshot permanece no mesmo disco que o original até ser movido. Por isso, envie-o para fora do servidor com snapshots restic para armazenamento externo segundo um agendamento. Um trabalho de backup que deixa de ser executado silenciosamente parece exatamente um trabalho que nunca existiu. Faça o temporizador comunicar as próprias falhas para um local que possa verificar. É esse o objetivo de um servidor ntfy self-hosted ligado a uma unidade systemd OnFailure. Os ficheiros rsa_key são tão importantes como a base de dados: o servidor assina os respetivos tokens de sessão com essa chave. Restaurar uma base de dados junto de uma chave recém-gerada termina as sessões de todos os utilizadores e interrompe os convites para organizações que estavam em curso.

O Bitwarden standard faz backup de mais componentes. O contentor mssql grava backups noturnos da base de dados em ./bwdata/mssql/backups e conserva 30 dias de backups, desde que o contentor esteja em execução. Também pode forçar um backup:

docker exec -i bitwarden-mssql /backup-db.sh

Os diretórios a preservar são ./bwdata/env (variáveis de ambiente, incluindo as palavras-passe da base de dados e dos certificados), ./bwdata/core/attachments, ./bwdata/mssql/data e ./bwdata/core/aspnet-dataprotection. O último é o que as pessoas esquecem. Contém material de proteção de dados ao nível do framework, incluindo tokens de autenticação e algumas colunas da base de dados. Por isso, restaurar a base de dados sem esse material deixa ilegíveis as colunas que ele protege. O Bitwarden lite não faz backups automáticos. Escolher lite significa assumir a responsabilidade por um agendamento de dumps, tal como no Vaultwarden.

Migrar em qualquer direção

A migração é feita através dos clientes, não dos servidores, porque a exportação e a importação são funcionalidades do cliente. Por isso, o procedimento é igual nas duas direções.

Cada utilizador exporta os dados a partir do cofre web ou da aplicação de desktop, cria uma conta no novo servidor e importa os dados. Os formatos são plaintext .json, plaintext .csv, encrypted .json e um .zip que contém o JSON e os anexos de ficheiros dos cofres individuais. Os cartões, as identidades, as passkeys armazenadas e as chaves SSH só são preservados nos formatos JSON. Por isso, uma migração através de CSV elimina-os silenciosamente. Nenhum formato de exportação inclui itens da reciclagem ou Sends. Os dados pertencentes a uma organização também não fazem parte da exportação individual.

Trate uma exportação plaintext como um segredo ativo, porque é exatamente isso: o cofre completo em texto simples no disco. Exporte-o, importe-o e elimine-o na mesma sessão. Nunca o envie por email ou chat.

Existe uma armadilha que apanha alguns utilizadores durante a migração. Uma exportação encriptada associada à sua conta não pode ser importada para uma conta diferente. A mudança de servidor implica, por definição, uma conta diferente. Escolha antes a opção de exportação protegida por palavra-passe, que é portátil.

A migração de Vaultwarden para Bitwarden standard é a direção mais difícil, porque a estrutura da organização não é transportada numa exportação. Recrie a organização no novo servidor, convide novamente os utilizadores e peça a cada utilizador para importar o seu próprio cofre. Planeie uma janela de manutenção para este processo, em vez de descobrir esta limitação no próprio dia.

Qual deve executar?

Execute o Vaultwarden se for uma pessoa, uma família ou um homelab num VPS com 1 GB ou 2 GB. Organizations, Emergency Access e Send estão incluídos sem custo, o consumo de memória em idle é aproximadamente o de um separador do browser e a cópia de segurança é um ficheiro SQLite mais um diretório pequeno. É essa combinação que faz com que domine a gestão de palavras-passe self-hosted.

Execute o servidor oficial do Bitwarden quando outras pessoas dependerem dele profissionalmente: uma empresa que precise de um contrato de suporte, de um requisito de conformidade que especifique o fornecedor ou de funcionalidades empresariais que já paga. Atribua 4 GB à implementação padrão e trate o ficheiro de licença e o installation ID como parte da implementação, não como mera burocracia.

O Bitwarden lite fica numa posição intermédia pouco clara. É código do fornecedor com uma fração do peso, o que é genuinamente atrativo, mas o Bitwarden documenta-o para utilização pessoal e em homelabs e não tem cópias de segurança automáticas. Fica com a carga operacional do Vaultwarden sem o conjunto de funcionalidades gratuitas do Vaultwarden. Escolha-o quando o código do fornecedor for mais importante para si do que as funcionalidades e estiver disposto a gerir a base de dados.

Se ainda estiver a decidir o que mais o servidor vai alojar, a lista mais ampla de opções self-hosted coloca esta escolha ao lado dos outros serviços que competem pela mesma RAM.

FAQ

O Vaultwarden é suficientemente seguro para ser usado como gestor de palavras-passe?

Para uso pessoal e familiar, sim, desde que algumas condições sejam cumpridas. Os clientes encriptam o cofre antes de este chegar ao servidor, por isso o Vaultwarden nunca vê a sua palavra-passe principal nem dados em texto simples. O software foi analisado externamente: a BSI contratou parceiros da mgm security para o testar entre fevereiro e maio de 2024, e a ERNW comunicou um bypass de autenticação corrigido na versão 1.32.5. Mantenha a versão atualizada, desative a página de administração ou proteja-a com um ADMIN_TOKEN com hash Argon2 e disponibilize o serviço apenas através de HTTPS. Uma empresa que necessite de suporte do fornecedor ou de documentação de auditoria deve executar o servidor oficial do Bitwarden.

Quanta RAM o Vaultwarden necessita em comparação com o Bitwarden self-hosted?

Em instalações inativas medidas com docker stats --no-stream, o Vaultwarden com SQLite utilizou cerca de 58 MB num contentor, enquanto a implementação padrão do Bitwarden utilizou cerca de 2,400 MB distribuídos por 12 contentores. A maior parte desse consumo correspondia à base de dados MSSQL. O Bitwarden documenta 2 GB como requisito mínimo e 4 GB como valor recomendado para a stack padrão, e 200 MB para o Bitwarden lite. O Vaultwarden funciona num VPS com 1 GB e ainda dispõe de margem.

Preciso de uma licença do Bitwarden para alojar o serviço por conta própria?

Não para um cofre individual gratuito. A execução do servidor é gratuita. É necessário um ficheiro de licença para desbloquear funcionalidades premium individuais e um plano de organização pago, e Families e Enterprise são os únicos planos de organização que o Bitwarden permite alojar por conta própria. Transfira o ficheiro a partir do cofre Web na cloud e carregue-o para a sua instância. As licenças de organização são emitidas com base no ID de instalação armazenado em ./bwdata/env/global.override.env. O Vaultwarden não necessita de licença e ativa as funcionalidades de organização por si próprio.

Posso passar do Vaultwarden para o Bitwarden mais tarde, ou fazer o percurso inverso?

Sim, em ambas as direções, através dos clientes. Cada utilizador exporta o seu cofre a partir do cofre Web ou da aplicação de desktop e importa-o para o novo servidor depois de criar aí uma conta. A exportação .zip inclui anexos dos cofres individuais, e os formatos JSON incluem cartões, identidades, passkeys e chaves SSH. Os itens no lixo e os Sends não estão incluídos em nenhum formato de exportação. Os itens pertencentes a uma organização têm de ser exportados separadamente por um proprietário. Por isso, planeie recriar a organização e enviar novos convites aos utilizadores no novo servidor.