Como fazer self-hosting do Vaultwarden em 2026: domínios, SMTP e backups seguros

Há duas versões de “executar o Vaultwarden”: existe um container ou o serviço cumpre sua função de verdade. Apenas a segunda importa. Aqui, a comprovação consiste em entrar a partir de uma extensão do navegador, criar um item, sincronizar um segundo cliente, fazer upload de um anexo e recuperar um Send após reiniciar.

O Vaultwarden atende a este propósito: um servidor de senhas compacto e compatível com Bitwarden. A implantação precisa preservar os elementos por trás desse comportamento; uma porta, um volume e um certificado são entradas, não o resultado.

Volumes são apenas a primeira camada de recuperação

O conjunto persistente de recuperação inclui o banco de dados, anexos, Sends, chaves e configurações em /data. Monte /data antes do bootstrap, grave dados de exemplo inofensivos e substitua o container para comprovar que esse caminho é realmente persistente. Um volume protege os dados contra a substituição do container, mas não contra a perda do host, exclusões acidentais ou corrupção no nível da aplicação.

Faça backups que entendam a origem dos dados: use dumps lógicos para bancos de dados ativos quando necessário e copie arquivos apenas a partir de um estado consistente. Mantenha uma cópia criptografada fora do host do Vaultwarden. O critério de aceitação de uma restauração é específico: itens do cofre, anexos, Sends e associação à organização devem ser sincronizados corretamente com um cliente limpo após a restauração. O guia de backups testados por restauração explica por que o sucesso de um job, por si só, não é suficiente.

Inicie o Vaultwarden sem ocultar os componentes

Inicie o Vaultwarden de forma que a rota permaneça privada até a conclusão do bootstrap.

docker run -d \
  --name vaultwarden \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v vaultwarden-data:/data \
  -e ADMIN_TOKEN=replace-with-a-long-random-value \
  vaultwarden/server:latest

Se o processo entrar em loop, compare o usuário esperado pela imagem com o proprietário de cada caminho montado. Se permanecer em execução, teste a porta 80 localmente e passe diretamente ao fluxo: entre a partir de uma extensão do navegador, crie um item, sincronize um segundo cliente, faça upload de um anexo e recupere um Send após reiniciar. Fixe a versão da imagem somente depois que essa verificação de ponta a ponta for aprovada e registre a configuração exata junto ao serviço.

Defina os limites de execução do Vaultwarden

Defina três limites ao redor do Vaultwarden: a entrada até a porta 80, o estado persistente e os requisitos de suporte. O container pode ser substituído, mas os outros dois precisam de responsáveis explícitos. O requisito externo do Vaultwarden é um SMTP funcional quando convites e e-mails de acesso de emergência forem necessários. Teste o DNS de saída, o TLS e o comportamento do provedor sem publicar outro serviço de entrada.

O diagrama estará completo quando um cliente limpo puder entrar a partir de uma extensão do navegador, criar um item, sincronizar um segundo cliente, fazer upload de um anexo e recuperar um Send após reiniciar. Colete dados de tempo e recursos para o volume de anexos, a contenção de escrita do SQLite ou os limites do pool de conexões do banco de dados, além da latência do SMTP durante os convites. Se a transação falhar, o primeiro limite que não se comportar conforme documentado indicará se a investigação deve se concentrar no roteamento, na capacidade local ou em um serviço de suporte.

Mantenha corretas as URLs internas e externas

Evite origens públicas temporárias e permanentes para o Vaultwarden. Em vez disso, defina DOMAIN como a origem HTTPS externa exata, aponte o nome DNS escolhido para a rota da plataforma e faça proxy apenas para a porta 80.

Execute esta ação de fora do host: entre a partir de uma extensão do navegador, crie um item, sincronize um segundo cliente, faça upload de um anexo e recupere um Send após reiniciar. Se a entrada falhar, o guia de troubleshooting de 502 aborda erros de porta e listener. Se o Vaultwarden receber a solicitação, mas DOMAIN estiver definido como HTTP enquanto o navegador exigir uma origem segura para os recursos do cofre, as evidências agora apontam para além do proxy.

Uma execução de aceitação do Vaultwarden em produção

Um gate de produção para o Vaultwarden deve poder ser executado por alguém que não tenha criado a implantação. Forneça a essa pessoa a versão fixada, uma conta de teste sem dados sensíveis e esta tarefa: entrar a partir de uma extensão do navegador, criar um item, sincronizar um segundo cliente, fazer upload de um anexo e recuperar um Send após reiniciar. Se as instruções exigirem acesso shell não documentado, o serviço ainda não está pronto do ponto de vista operacional.

Repita o gate substituindo apenas o container. Em seguida, restaure o banco de dados, os anexos, os Sends, as chaves e as configurações em /data em uma infraestrutura vazia e comprove que os itens do cofre, os anexos, os Sends e a associação à organização são sincronizados corretamente com um cliente limpo após a restauração. Meça o volume de anexos, a contenção de escrita do SQLite ou os limites do pool de conexões do banco de dados, além da latência do SMTP durante os convites, nas duas execuções bem-sucedidas; diferenças inesperadas frequentemente revelam um cache, índice, worker ou montagem de dados ausente.

Adicione um teste de falha: negue temporariamente o caminho de teste usado pelo SMTP funcional quando convites e e-mails de acesso de emergência forem necessários. O Vaultwarden deve emitir um erro útil, preservar o estado existente e se recuperar quando a condição válida retornar. Salve os timestamps e as linhas de log relevantes, ocultando os secrets. Essas evidências se tornam a referência para a próxima alteração de imagem ou configuração.

Monitore a carga de trabalho, não apenas o container

Um container em estado saudável é necessário, mas não suficiente. O indicador de nível de serviço é a conclusão bem-sucedida de “entrar a partir de uma extensão do navegador, criar um item, sincronizar um segundo cliente, fazer upload de um anexo e recuperar um Send após reiniciar”, enquanto os sinais prováveis de pressão são o volume de anexos, a contenção de escrita do SQLite ou os limites do pool de conexões do banco de dados e a latência do SMTP durante os convites.

O controle de mudanças é importante porque as migrações do banco de dados do Vaultwarden e a compatibilidade com os clientes Bitwarden precisam ser verificadas em conjunto; a rotação de ADMIN_TOKEN é uma alteração de acesso administrativo, não uma migração de dados do cofre. Preserve a imagem antiga, teste as migrações em um estado copiado e documente se o rollback é compatível depois que o schema for alterado. Se DOMAIN estiver definido como HTTP enquanto o navegador exigir uma origem segura para os recursos do cofre, diagnostique o primeiro limite que divergir do ambiente funcional.

Remova o acesso temporário de configuração

Uma implantação segura do Vaultwarden começa removendo autoridade. Evite usar um token de administrador fraco ou deixar os cadastros abertos; em vez disso, desative o cadastro aberto quando o período de adesão terminar, proteja a página de administração com um token forte e exija HTTPS para todos os clientes do cofre.

Substitua imediatamente o ADMIN_TOKEN de exemplo, armazene-o fora da imagem e faça sua rotação como uma credencial de administrador caso ele seja exposto. Restrinja as rotas administrativas, use DNS privado para as dependências e revise cada bind mount. Quando os logs forem enviados para um sistema central, filtre secrets e conteúdo privado antes que deixem o servidor.

Use o Dockup para a camada de plataforma

O Dockup elimina o trabalho manual de reverse proxy e gerenciamento do ciclo de vida ao redor do Vaultwarden. O serviço recebe uma rota HTTPS estável para a porta 80, configuração injetada e armazenamento persistente durante as substituições. Um servidor de cliente conectado segue o mesmo modelo da infraestrutura de computação hospedada pelo Dockup.

Após o lançamento, cumpra o contrato da aplicação: defina DOMAIN como a origem HTTPS externa exata, permita e verifique um SMTP funcional quando convites e e-mails de acesso de emergência forem necessários e execute esta comprovação: entre a partir de uma extensão do navegador, crie um item, sincronize um segundo cliente, faça upload de um anexo e recupere um Send após reiniciar. Isso mantém a experiência de um clique útil sem ocultar os detalhes que tornam o Vaultwarden recuperável e seguro.

Perguntas frequentes

O que o Vaultwarden precisa para uma implantação em produção?

Encaminhe o container do Vaultwarden na porta 80 por meio de uma única origem HTTPS. O requisito externo de entrega é um SMTP funcional quando convites e e-mails de acesso de emergência forem necessários. Não considere o Vaultwarden pronto até que seja possível entrar a partir de uma extensão do navegador, criar um item, sincronizar um segundo cliente, fazer upload de um anexo e recuperar um Send após reiniciar.

Quais dados do Vaultwarden devem fazer parte de um backup?

Persista /data e inclua o banco de dados, os anexos, os Sends, as chaves e as configurações em /data no mesmo manifesto de recuperação. Uma restauração limpa do Vaultwarden só será aprovada quando os itens do cofre, os anexos, os Sends e a associação à organização forem sincronizados corretamente com um cliente limpo após a restauração.

O Vaultwarden exige HTTPS atrás de um reverse proxy?

Use HTTPS para a origem pública do Vaultwarden e mantenha a porta 80 na rota interna. Aplique corretamente a configuração do Vaultwarden: defina DOMAIN como a origem HTTPS externa exata. No Vaultwarden, o HTTPS protege credenciais ou conteúdo do usuário durante o trânsito e mantém consistente o comportamento do cliente sensível à origem.

Como uma atualização do Vaultwarden deve ser testada?

Restaure o estado atual do Vaultwarden em uma implantação isolada, aplique a versão candidata e repita sua transação de aceitação. Dê atenção especial a esse processo porque as migrações do banco de dados do Vaultwarden e a compatibilidade com os clientes Bitwarden precisam ser verificadas em conjunto; a rotação de ADMIN_TOKEN é uma alteração de acesso administrativo, não uma migração de dados do cofre. Mantenha a imagem anterior do Vaultwarden até compreender os limites de migração de dados e rollback.