Vaultwarden ou Bitwarden self-hosted: qual escolher?

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

A escolha entre o Vaultwarden e o Bitwarden self-hosted é uma escolha entre dois servidores que utilizam a mesma API de cliente, não 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 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 utiliza um único ficheiro SQLite. A extensão do navegador e o telemóvel não conseguem distingui-los, porque ambos respondem aos mesmos endpoints.

A encriptação é idêntica em ambos os casos. Os clientes Bitwarden encriptam o cofre antes de qualquer dado sair do dispositivo. Assim, 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 contratar, quem mantém o código, quais funcionalidades têm custos e aquilo de que precisa de fazer backup.

O README do Vaultwarden é claro sobre o seu estatuto: "Este projeto não está associado ao Bitwarden nem à 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, orientada por um script de 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, o nome da 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 posterior com o plugin Compose. A base de dados é 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 versão 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. Requer 200 MB de RAM e 1 GB de armazenamento. Há duas ressalvas na documentação da própria Bitwarden. A implementação é documentada para uso pessoal e laboratórios domésticos, não para uso empresarial. Também não cria cópias de segurança automáticas da base de dados. Essa tarefa fica inteiramente a seu cargo.

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. Isso é intencional. O Vaultwarden serve HTTP simples e espera que um reverse proxy termine o TLS (transport layer security) à sua frente. Neste caso, o TLS é obrigatório. O cofre Web 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 um pedido. 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 em que condições o instalador recusa executar, não quanto pesa o software. As linhas abaixo vêm de docker stats --no-stream em instalações inativas, com um utilizador, um cofre pequeno e sem anexos, num sistema Ubuntu 24.04 com 4 GB de RAM. O espaço em disco corresponde às imagens e ao 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, e o MSSQL aumenta o seu conjunto de trabalho quanto mais tempo estiver em execução.

A leitura prática para um VPS pequeno é a seguinte: o Vaultwarden com SQLite funciona bem num plano de 1 GB, e 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 pouco para o sistema operativo, pelo que o kernel out of memory killer se torna um evento real. Quando é acionado, dmesg imprime uma linha com o nome do processo que terminou e, nesta stack, esse processo é normalmente 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 tantos recursos: algo como o Halcyon, que apresenta uma biblioteca Jellyfin como um videoclube dos anos 90 é um front end no browser que depende do servidor multimédia indicado, em vez de incluir 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 desktop remoto quase não aparece em docker stats e depois consome a largura de banda incluída no seu plano.

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 de organizações (Families, Teams, Enterprise) precisam de uma licença. Pode descarregá-la a partir 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á-la 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 autoalojada continua a ter uma subscrição paga e continua a contactar a cloud 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. Este mecanismo autentica apenas o início de sessão. A wiki afirma explicitamente que continua a ser necessária uma palavra-passe principal. Essa palavra-passe não é controlada pelo seu fornecedor de identidade, porque dela 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 final.

O que não obtém com o Vaultwarden é um fornecedor comercial. 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 no HackerOne. Essas garantias 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 self-hosted na tela de ambiente antes de iniciar sessão, e não depois.

Uma funcionalidade precisa de 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. Por isso, uma senha alterada no laptop não aparece no telefone até que você abra o aplicativo. O Vaultwarden pode usar o relay de push do Bitwarden. Para isso, precisa do ID e da chave de instalação da 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 vale a pena conhecer antes de passar uma hora a depurar o 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 tenha estabelecido ligação antes do Vaultwarden 1.30.2 precisa de ter os seus dados limpos para que possa registar um token de push.

Qual é o nível de segurança de 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 web e de rede ao longo de 2024 e 2025, a Unit 42 avaliou as aplicações móveis em 2025 e o ETH Zurich Applied Cryptography Group analisou a criptografia em 2025.

O Vaultwarden também foi analisado por entidades externas, o que surpreende quem assume 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, e essa análise classificou duas descobertas como de gravidade alta. Separadamente, a ERNW comunicou um bypass de autenticação que afetava versões anteriores à 1.32.5 (CVE-2024-55225), corrigido em novembro de 2024. A versão 1.37.0, disponibilizada 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 de uma 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: a página de administração. Por isso, trate essa página como o recurso sensível que é. Ela permanece desativada, a menos que ADMIN_TOKEN esteja definido, 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 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 simples pode ser lido por qualquer entidade no caminho. O risco prático está nesse token e no seu ficheiro de backup, e não na criptografia. Uma verificação de hardening numa instância em execução trata ambos. Mantenha /admin fora da Internet pública sempre que possível e combine-o com medidas normais de hardening do host, como restringir o acesso SSH ao servidor.

O que deixa de funcionar quando a API oficial muda

Este é o risco que muitas pessoas subestimam. A Bitwarden lança os clientes, e esses clientes atualizam-se automaticamente através das lojas de aplicações durante a noite. O Vaultwarden tem de acompanhar essas alterações. Quando uma versão do cliente altera o contrato da API, um Vaultwarden que não foi 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 alterou.

As notas da versão apresentam um exemplo concreto. O Vaultwarden 1.37.0 diz: "Esta atualização é necessária para dar suporte a clientes com a versão 2026.7.0 ou posterior; atualize antes de comunicar qualquer problema 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 problema sob controlo. Fixe uma tag de imagem específica em vez de latest, para que um pull não supervisionado não atualize o servidor às 3h00. Depois, monitorize o feed de versões e atualize deliberadamente, lendo primeiro as notas, porque as alterações incompatíveis aparecem ali e em mais nenhum 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, terminando a sessão dos utilizadores numa etapa que pensavam ter guardado.

A implementação padrão do 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 são onde as pessoas efetivamente perdem os cofres

O diretório de dados do Vaultwarden é o servidor. Guarde 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, 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 movido. Por isso, envie-o para fora do servidor com snapshots do restic para armazenamento externo de forma programada. Um job de backup que deixa silenciosamente de executar parece exatamente um job que nunca existiu. Faça o temporizador comunicar as próprias falhas para algum local onde as possa detetar. É essa a finalidade de um servidor ntfy autoalojado ligado a uma unidade systemd OnFailure. Os ficheiros rsa_key são tão importantes como a base de dados. O servidor assina os tokens de sessão com essa chave. Por isso, restaurar uma base de dados junto de uma chave recém-gerada termina a sessão de todos e interrompe os convites de organizações que estavam em processamento.

O Bitwarden standard faz backup de uma parte maior dos seus dados. 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 conservar 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 o lite significa manter um agendamento de dumps exatamente como faria com o Vaultwarden.

Migração em qualquer direção

A migração é feita através dos clientes, não dos servidores, porque exportar e importar são funcionalidades dos clientes. 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. Cartões, identidades, passkeys armazenadas e chaves SSH só são preservados nos formatos JSON, por isso uma migração CSV elimina-os silenciosamente. Nenhum formato de exportação inclui itens do lixo ou Sends, e os dados pertencentes à organização não fazem parte de uma exportação individual.

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

Há uma armadilha que apanha muitas pessoas durante a migração. Uma exportação encrypted 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ável.

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

Qual deles deve executar?

Execute o Vaultwarden se for uma pessoa, uma família ou um laboratório doméstico num VPS de 1 GB ou 2 GB. Organisations, Emergency Access e Send estão incluídos sem custo, o consumo de memória em inatividade é aproximadamente o de um separador do navegador, e o backup consiste num ficheiro SQLite e num diretório pequeno. Essa combinação explica por que domina a gestão de palavras-passe auto-hospedada.

Execute o servidor próprio da 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 à implementação padrão e trate o ficheiro de licença e o ID de instalação como parte da implementação, não como mera documentação.

O Bitwarden lite fica numa posição intermédia pouco clara. É código do fornecedor com uma fração do peso, o que é realmente atrativo, mas a Bitwarden documenta-o para uso pessoal e em laboratório doméstico, e ele não tem backups automáticos. Terá 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 aceitar gerir a base de dados por conta própria.

Se ainda estiver a decidir o que mais irá alojar nesse servidor, a lista mais ampla de opções de auto-hospedagem 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 sejam cumpridas algumas condições. Os clientes cifram o cofre antes de o enviarem para o servidor, por isso o Vaultwarden nunca vê a 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 uma falha que permitia contornar a autenticação, corrigida 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 por HTTPS. Uma empresa que necessite de suporte do fornecedor ou de documentação de auditoria deve utilizar o servidor da própria Bitwarden.

Quanta RAM o Vaultwarden precisa 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 em 12 contentores. A maior parte desse consumo correspondia à base de dados MSSQL. A 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 Bitwarden para fazer self-hosting?

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 de organização pago, que inclui Families, Teams e Enterprise. Transfira-o do cofre web na cloud e carregue-o 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 precisa 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, em ambas as direções, através dos clientes. Depois de criar uma conta no novo servidor, 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. 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.