Vaultwarden ou Bitwarden self-hosted: qual escolher?

O que o Vaultwarden e o Bitwarden self-hosted são na prática

A escolha entre Vaultwarden e Bitwarden self-hosted é uma escolha entre dois servidores que usam a mesma API de cliente, não entre dois gestores de palavras-passe. A própria stack 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 email. O Vaultwarden é uma reimplementação não oficial da API de cliente do Bitwarden, escrita em Rust, que executa como um único contentor e usa um único ficheiro SQLite. A extensão do browser e o telemóvel 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. Assim, o servidor armazena blobs que não consegue ler. O formato do cofre também pertence ao Bitwarden nos dois casos. O que muda é a quantidade de recursos que precisa de alugar, quem mantém o código, que funcionalidades têm custos e aquilo que precisa de incluir nas cópias de segurança.

O README do Vaultwarden é claro quanto ao 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 mantenedores ativos trabalha na Bitwarden e contribui no seu tempo pessoal. Isso é uma cortesia, não um endosso.

As três stacks que pode instalar

A maioria das comparações ignora que a Bitwarden disponibiliza dois produtos self-hosted diferentes.

Bitwarden standard. A implementaçã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 pede o seu domínio, se deve solicitar um certificado Let's Encrypt, um nome de base de dados e um ID e uma chave de instalação, que obtém em https://bitwarden.com/host ao introduzir um endereço de email. Em seguida, ./bitwarden.sh start obtém 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, e Docker Engine 26 ou mais recente com o plugin Compose. A base de dados utiliza uma imagem MSSQL Express. Essa edição limita a base de dados relacional a 10 GB, exceto se configurar a implementação para utilizar uma base de dados externa.

Bitwarden lite. Esta é a implementação anteriormente chamada Bitwarden Unified. Saiu da fase beta e foi renomeada em dezembro de 2025. Inclui um contentor de aplicação e uma base 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:

Aceita MariaDB ou MySQL, PostgreSQL, SQLite e MSSQL, e requer 200 MB de RAM e 1 GB de armazenamento. Há duas ressalvas na documentação da própria Bitwarden. É indicada para uso pessoal e laboratórios domésticos, não para uso empresarial, e não cria cópias de segurança automáticas da base de dados. Essa tarefa é inteiramente sua.

Vaultwarden. Um contentor, 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 de publicação associa a porta 8000 apenas ao loopback, por uma razão. O Vaultwarden disponibiliza HTTP simples e espera que um reverse proxy faça a terminação TLS (transport layer security) à frente dele. Neste caso, o TLS é obrigatório: o web vault faz a encriptação através da API WebCrypto do browser, que os browsers só disponibilizam num contexto seguro. Por isso, através de http simples, a página de início de sessão falha no browser antes de o servidor sequer receber o pedido. O guia completo de instalação do Vaultwarden explica a configuração do proxy e do certificado.

Quanta RAM o Vaultwarden utiliza em comparação com o Bitwarden auto-hospedado?

Os requisitos mínimos do fornecedor indicam abaixo de que limite o instalador recusa executar, não o espaço ocupado pelo software. As linhas abaixo vêm de docker stats --no-stream em instalações inativas, com um utilizador cada, um cofre pequeno e sem anexos, num sistema 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 ficou inativo com 58 MB num único contentor. A stack padrão do Bitwarden ficou perto de 2,400 MB distribuídos por 12 contentores, e o contentor MSSQL representa a maior parte desse consumo. O Bitwarden lite ficou entre os dois, com 470 MB, incluindo o seu contentor MariaDB. Execute o mesmo comando no seu próprio sistema antes de confiar nestes valores, porque eles variam com o número de utilizadores, os anexos e o tráfego de sincronização. O MSSQL também aumenta o conjunto de trabalho quanto mais tempo fica em execução.

A interpretação prática para um VPS pequeno é a seguinte: 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. Por isso, o kernel out of memory killer torna-se um evento real. Quando é acionado, dmesg imprime uma linha com o nome do processo que terminou. Nesta stack, esse processo costuma ser sqlservr. Reserve 4 GB para a implementação padrão.

Quais recursos pagos são gratuitos no Vaultwarden?

Executar o servidor do Bitwarden não tem custo, mas os recursos pagos permanecem bloqueados até carregar um ficheiro de licença. As contas individuais Premium e todos os níveis pagos das organizações (Families, Teams, Enterprise) precisam de uma licença. Pode descarregá-la do cofre Web na nuvem, em Settings e depois Subscription para uma conta individual, ou na Admin Console, em Billing e depois Subscription, para uma organização, e carregá-la na sua própria instância. As licenças de organizações são emitidas para o ID de instalação armazenado em ./bwdata/env/global.override.env. Por isso, uma organização autoalojada continua a ter uma subscrição paga e continua a contactar a nuvem do Bitwarden para efeitos de faturação.

O Vaultwarden ativa os mesmos recursos sem licença e sem subscrição. A wiki do projeto lista-os:

• 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 é o mais recente destes recursos e é configurado com SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID e SSO_CLIENT_SECRET. Apenas autentica o início de sessão. A wiki deixa claro 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 autoalojado. Os utilizadores iniciam sessão nesse fornecedor e depois desbloqueiam 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 fim.

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 recompensas por bugs na HackerOne. Estas medidas abrangem o código e o serviço do Bitwarden, não o servidor que instalou. Ainda assim, se um auditor exigir um fornecedor identificado por trás do seu gestor de palavras-passe, uma reimplementação mantida por voluntários será difícil de justificar.

Os aplicativos oficiais do Bitwarden funcionam com o Vaultwarden?

Sim. O Vaultwarden implementa a API do 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 auto-hospedado no ecrã de ambiente antes de iniciar sessão, e não depois.

Uma funcionalidade requer configuração adicional: 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. Assim, uma palavra-passe alterada no portátil não aparece no telemóvel até que o aplicativo seja consultado. O Vaultwarden pode utilizar o relay de push do Bitwarden e precisa de um ID de instalação e de uma chave obtidos na mesma página https://bitwarden.com/host usada pelo instalador oficial.

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 depurar este problema. Um aplicativo instalado a partir do F-Droid ou do Neo Store não tem suporte para Firebase e nunca receberá notificações push, independentemente do que o servidor faça. Um aplicativo que se ligou antes do Vaultwarden 1.30.2 precisa de ter os dados apagados para poder registar um token de 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 e 2023. A IOActive e a Mandiant analisaram os clientes em 2024, a Fracture Labs realizou avaliações da Web e da rede ao longo de 2024 e 2025, a Unit 42 avaliou as aplicações móveis em 2025 e 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 pediu à mgm security partners que o testasse entre fevereiro e maio de 2024, no âmbito do projeto de análise de código Caos 3.0, e essa análise classificou duas conclusões como de severidade alta. Separadamente, a ERNW comunicou uma falha de bypass da 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, incluiu correções para SSRF (server side request forgery) através do endpoint de ícones, acesso a cifras entre organizações e um bypass da política da organização durante importações de diretórios.

Este histórico mostra um projeto com um processo funcional de comunicação de vulnerabilidades. Também aponta para a superfície que aparece repetidamente nessas análises: 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 definida, e deve armazenar um hash em vez do token em texto simples.

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

Isto imprime uma cadeia PHC do Argon2 (password hashing competition format) para colar em ADMIN_TOKEN. Ative o HTTPS antes de ativar a página de administração, porque o token é enviado no pedido e um token em texto simples numa ligação HTTP sem encriptação pode ser lido por qualquer entidade no caminho da rede. Mantenha /admin fora da Internet pública sempre que possível e combine-o com medidas comuns de proteção do host, como restringir o acesso SSH ao servidor.

O que pode falhar quando a API oficial muda

Este é um risco que costuma ser subestimado. A Bitwarden lança os clientes, e esses clientes atualizam-se automaticamente através das lojas de aplicações. O Vaultwarden tem de acompanhar essas mudanças. Quando uma versão do cliente altera o contrato da API, um Vaultwarden não atualizado recebe um cliente que já avançou, e os inícios de sessão ou a sincronização começam a falhar em dispositivos que não foram alterados.

As notas da versão apresentam um exemplo concreto. O Vaultwarden 1.37.0 indica: "Esta atualização é necessária para suportar clientes com a versão 2026.7.0 ou superior; atualize antes de comunicar quaisquer problemas com eles." Em agosto de 2026, a versão atual é a 1.37.1, publicada em 29 de julho de 2026.

Duas práticas mantêm este processo previsível. Fixe uma tag de imagem específica em vez de latest, para que uma obtenção automática não possa atualizar o servidor às 3h. Depois, monitorize o feed de versões e atualize de forma deliberada, lendo primeiro as notas, porque as alterações incompatíveis aparecem aí e em nenhum outro local. Por exemplo, a versão 1.35.5 invalidou, durante a atualização, todos os tokens existentes de memorização da autenticação de dois fatores. Isto termina a sessão dos utilizadores numa etapa que julgavam ter guardado.

A implementação padrão da Bitwarden tem o problema inverso. As atualizações são executadas através de ./bitwarden.sh updateself e ./bitwarden.sh update, e a atualização aplica migrações à base de dados. Uma cópia de segurança criada antes da migração não permite reverter o esquema depois dela. Por isso, crie a cópia de segurança e registe a versão em que a criou.

Backups, onde as pessoas realmente perdem os vaults

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 container estiver em execução. O SQLite pode estar a escrever nesse momento, e a cópia pode ser uma base de dados corrompida que parece válida 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 qualquer dos casos, o snapshot permanece no mesmo disco que o original até ser transferido. Por isso, envie-o para fora do servidor com snapshots do restic para armazenamento externo, segundo uma agenda. Os ficheiros rsa_key são tão importantes como a base de dados: o servidor assina os seus tokens de sessão com essa chave. Assim, restaurar uma base de dados junto de uma chave gerada novamente termina a sessão de todos e interrompe os convites de organizações que estavam em curso.

O Bitwarden standard faz backup de mais componentes. O container mssql grava backups noturnos da base de dados em ./bwdata/mssql/backups e mantém 30 dias de backups, desde que o container 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 da 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 manter uma agenda de dumps, tal como faria com o Vaultwarden.

Migrar em qualquer direção

A migração é feita pelos clientes, não pelos servidores, porque exportar e importar são funções do cliente. Por isso, os dois sentidos seguem o mesmo procedimento.

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 disponíveis são .json em texto simples, .csv em texto simples, .json encriptado e um .zip que contém o JSON e os anexos de ficheiros dos cofres individuais. Cartões, identidades, passkeys armazenadas e chaves SSH só são preservados nos formatos JSON, pelo que uma migração CSV elimina-os silenciosamente. Nenhum formato de exportação inclui itens da reciclagem ou Sends, e os dados pertencentes à organização não fazem parte de uma exportação individual.

Trate uma exportação em texto simples como um segredo ativo, porque é exatamente isso: o seu cofre completo em texto não encriptado 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 muitos utilizadores durante a migração. Uma exportação encriptada associada à sua conta não pode ser importada para uma conta diferente, e mudar de servidor implica, por definição, usar uma conta diferente. Escolha antes a opção de exportação protegida por palavra-passe, que é portátil.

A migração de Vaultwarden para o Bitwarden standard é 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 faça com que cada utilizador importe 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 home lab num VPS com 1 GB ou 2 GB. Organizations, Emergency Access e Send são gratuitos, o consumo de memória em idle é aproximadamente o de um separador do browser e o backup consiste num ficheiro SQLite mais um diretório pequeno. Essa combinação é a razão pela qual domina a gestão de passwords 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 pelas quais já paga. Atribua 4 GB à instalação padrão e trate o ficheiro de licença e o installation ID como parte da instalação, não como simples burocracia.

O Bitwarden lite fica numa posição intermédia difícil. É código do fornecedor com uma fração do peso, o que é realmente atrativo, mas o Bitwarden documenta-o para uso pessoal e home lab e ele não tem backups automáticos. Fica responsável pela carga operacional do Vaultwarden sem o conjunto gratuito de funcionalidades 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 que outros serviços 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, com algumas condições. Os clientes encriptam o cofre antes de este chegar ao servidor, pelo que o Vaultwarden nunca vê a palavra-passe principal nem dados em texto simples. O software foi analisado externamente: a BSI contratou parceiros de segurança da mgm para o testar entre fevereiro e maio de 2024, e a ERNW comunicou uma falha de bypass de autenticação corrigida na versão 1.32.5. Mantenha a versão atualizada, mantenha a página de administração desativada ou protegida por 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, principalmente devido à base de dados MSSQL. O Bitwarden documenta 2 GB como requisito mínimo e 4 GB como valor recomendado para a stack padrão, além de 200 MB para o Bitwarden lite. O Vaultwarden funciona num VPS com 1 GB e ainda deixa margem disponível.

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 qualquer plano pago de organização, que inclui Families, Teams e Enterprise. Pode descarregá-lo do cofre web na cloud e carregá-lo para a sua instância. As licenças de organização são emitidas para o 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 voltar atrás?

Sim, nos dois sentidos, através dos clientes. Cada utilizador exporta o seu cofre a partir do cofre web ou da aplicação de ambiente de trabalho e importa-o para o novo servidor depois de criar uma conta nesse servidor. 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 organizações 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.