2026'da Vaultwarden'ı Self-Host Etme: Domain'ler, SMTP ve Güvenli Yedekler

“Vaultwarden çalıştırmanın” iki farklı anlamı vardır: bir container'ın mevcut olması veya servisin gerçek işlevini tamamlaması. Önemli olan yalnızca ikincisidir. Buradaki kanıt; bir browser extension üzerinden oturum açmak, bir öğe oluşturmak, ikinci bir client'ı sync etmek, bir attachment yüklemek ve restart sonrasında bir Send'i geri alabilmektir.

Vaultwarden şu amaçla kullanılır: Bitwarden uyumlu, kompakt bir password server. Deployment, bu davranışın arkasındaki bileşenleri korumalıdır; bir port, bir volume ve bir certificate girdidir, sonuç değildir.

Volume'ler yalnızca ilk recovery katmanıdır

Kalıcı recovery set'i; database'i, attachment'ları, Send'leri, key'leri ve /data içindeki configuration'ı kapsar. Bootstrap işleminden önce /data'yı mount edin, zararsız örnek veriler yazın ve bu path'in gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Bir volume verileri container değişiminden korur; ancak host kaybına, yanlışlıkla silinmeye veya application-level corruption'a karşı koruma sağlamaz.

Data source'u anlayan backup'lar alın: gerektiğinde çalışan database'ler için logical dump kullanın ve dosyaları yalnızca tutarlı bir durumdan kopyalayın. Şifrelenmiş bir kopyayı Vaultwarden host'undan ayrı bir yerde tutun. Restore için kabul kriteri nettir — restore sonrasında vault öğeleri, attachment'lar, Send'ler ve organization üyeliği temiz bir client ile doğru şekilde sync edilmelidir. Restore'u test edilmiş backup rehberi, yalnızca job başarısının neden yeterli olmadığını açıklar.

Vaultwarden'ı hareketli parçaları gizlemeden başlatın

Vaultwarden'ı, bootstrap tamamlanana kadar route'u private bırakacak şekilde başlatın.

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

Process loop'a girerse image'ın beklediği user ile mount edilen her path'in owner'ını karşılaştırın. Çalışmaya devam ederse port 80'i local olarak test edin ve doğrudan workflow'a geçin: bir browser extension üzerinden oturum açın, bir öğe oluşturun, ikinci bir client'ı sync edin, bir attachment yükleyin ve restart sonrasında bir Send'i geri alın. Image'ı version-pin işlemini ancak bu uçtan uca kontrol başarılı olduktan sonra yapın ve exact configuration'ı service'in yanında kaydedin.

Vaultwarden runtime sınırını belirleyin

Vaultwarden'ın etrafında üç sınır belirleyin: port 80'e gelen ingress, kalıcı state ve supporting requirements. Container değiştirilebilir; ancak diğer iki bileşenin açıkça belirlenmiş owner'ları olmalıdır. Vaultwarden için external requirement, invitation ve emergency access e-postaları gerekiyorsa çalışan SMTP'dir. Başka bir inbound service yayınlamadan outbound DNS'i, TLS'i ve provider davranışını test edin.

Temiz bir client bir browser extension üzerinden oturum açabildiğinde, bir öğe oluşturabildiğinde, ikinci bir client'ı sync edebildiğinde, bir attachment yükleyebildiğinde ve restart sonrasında bir Send'i geri alabildiğinde diagram tamamlanmış olur. Attachment volume'u, SQLite write contention veya database pool limit'leri ve invitation'lar sırasındaki SMTP latency için timing ve resource verilerini kaydedin. Transaction başarısız olursa, dokümante edildiği gibi davranmayan ilk sınır; routing'i, local capacity'yi veya supporting service'i araştırmanız gerekip gerekmediğini gösterir.

Internal ve external URL'leri doğru yönetin

Vaultwarden için geçici ve kalıcı public origin'leri birlikte kullanmaktan kaçının. Bunun yerine DOMAIN'i exact external HTTPS origin olarak ayarlayın, seçilen DNS adını platform route'una yönlendirin ve yalnızca port 80'e proxy yapın.

Bu işlemi host'un dışından gerçekleştirin: bir browser extension üzerinden oturum açın, bir öğe oluşturun, ikinci bir client'ı sync edin, bir attachment yükleyin ve restart sonrasında bir Send'i geri alın. Ingress başarısız olursa 502 troubleshooting rehberi, port ve listener hatalarını ele alır. Vaultwarden isteği alıyor ancak DOMAIN HTTP iken browser vault özellikleri için secure origin gerektiriyorsa, kanıt artık proxy'nin ötesindeki bir noktaya işaret eder.

Vaultwarden için production acceptance çalıştırması

Vaultwarden için production gate, deployment'ı oluşturmamış biri tarafından çalıştırılabilmelidir. Bu kişiye pinned version'ı, hassas olmayan bir test hesabını ve şu görevi verin: bir browser extension üzerinden oturum açmak, bir öğe oluşturmak, ikinci bir client'ı sync etmek, bir attachment yüklemek ve restart sonrasında bir Send'i geri almak. Talimatlar undocumented shell access gerektiriyorsa service henüz operational olarak hazır değildir.

Yalnızca container'ı değiştirerek gate'i tekrarlayın. Ardından database'i, attachment'ları, Send'leri, key'leri ve /data içindeki configuration'ı boş infrastructure'a restore edin ve vault öğelerinin, attachment'ların, Send'lerin ve organization üyeliğinin restore sonrasında temiz bir client ile doğru şekilde sync edildiğini kanıtlayın. Her iki başarılı çalıştırma sırasında attachment volume'unu, SQLite write contention veya database pool limit'lerini ve invitation'lar sırasındaki SMTP latency'yi ölçün; beklenmeyen farklar çoğu zaman eksik bir cache'i, index'i, worker'ı veya data mount'ını ortaya çıkarır.

Bir failure drill ekleyin: invitation ve emergency access e-postaları gerekiyorsa, çalışan SMTP'nin kullandığı test path'ine erişimi geçici olarak engelleyin. Vaultwarden kullanışlı bir error üretmeli, mevcut state'i korumalı ve geçerli koşul geri geldiğinde düzelmelidir. Secret'ları redakte ederek timestamp'leri ve ilgili log satırlarını kaydedin. Bu kanıt, sonraki image veya configuration değişikliği için referans olur.

Yalnızca container'ı değil workload'u izleyin

Yeşil bir container gereklidir ancak yeterli değildir. Service-level indicator, “bir browser extension üzerinden oturum açmak, bir öğe oluşturmak, ikinci bir client'ı sync etmek, bir attachment yüklemek ve restart sonrasında bir Send'i geri almak” işleminin başarıyla tamamlanmasıdır; olası pressure signal'ları ise attachment volume'u, SQLite write contention veya database pool limit'leri ve invitation'lar sırasındaki SMTP latency'dir.

Change control önemlidir; çünkü Vaultwarden database migration'ları ile Bitwarden client uyumluluğu birlikte kontrol edilmelidir; ADMIN_TOKEN rotation, vault-data migration değil administrator-access değişikliğidir. Eski image'ı koruyun, migration'ları kopyalanmış state üzerinde test edin ve schema taşındıktan sonra rollback'in desteklenip desteklenmediğini dokümante edin. DOMAIN HTTP iken browser vault özellikleri için secure origin gerektiriyorsa, çalışan ortamdan farklı davranan ilk sınırı teşhis edin.

Geçici setup erişimini kapatın

Güvenli bir Vaultwarden deployment'ı authority'yi kaldırarak başlar. Zayıf bir admin token kullanmaktan veya sign-up'ları açık bırakmaktan kaçının; bunun yerine enrollment sona erdiğinde açık sign-up'ı devre dışı bırakın, admin page'i güçlü bir token ile koruyun ve her vault client için HTTPS zorunlu tutun.

Örnek ADMIN_TOKEN'ı hemen değiştirin, image'ın dışında saklayın ve açığa çıkması durumunda administrator credential gibi rotate edin. Administrative route'ları kısıtlayın, dependency'ler için private DNS kullanın ve her bind mount'ı gözden geçirin. Log'lar merkezi olarak gönderiliyorsa, server'dan ayrılmadan önce secret'ları ve private content'i filtreleyin.

Platform katmanı için Dockup kullanın

Dockup, Vaultwarden çevresindeki manuel reverse-proxy ve lifecycle işlerini ortadan kaldırır. Service, replacement işlemleri sırasında 80'e yönlendiren sabit bir HTTPS route, injected configuration ve persistent storage alır. Bağlı bir customer server, Dockup-hosted compute ile aynı modeli izler.

Launch sonrasında application contract'ı karşılayın: DOMAIN'i exact external HTTPS origin olarak ayarlayın, invitation ve emergency access e-postaları gerekiyorsa çalışan SMTP'ye izin verildiğini doğrulayın ve şu kanıtı çalıştırın: bir browser extension üzerinden oturum açın, bir öğe oluşturun, ikinci bir client'ı sync edin, bir attachment yükleyin ve restart sonrasında bir Send'i geri alın. Böylece tek tıklama deneyimi, Vaultwarden'ı recoverable ve secure kılan ayrıntılar göz ardı edilmeden faydalı kalır.

Sık sorulan sorular

Production deployment için Vaultwarden'ın neye ihtiyacı vardır?

Vaultwarden container'ını tek bir HTTPS origin üzerinden port 80'e route edin. External delivery requirement, invitation ve emergency access e-postaları gerekiyorsa çalışan SMTP'dir. Bir browser extension üzerinden oturum açamadığınız, bir öğe oluşturamadığınız, ikinci bir client'ı sync edemediğiniz, bir attachment yükleyemediğiniz ve restart sonrasında bir Send'i geri alamadığınız sürece Vaultwarden'ı hazır kabul etmeyin.

Hangi Vaultwarden verileri backup'a dahil edilmelidir?

/data'yı persist edin ve database'i, attachment'ları, Send'leri, key'leri ve /data içindeki configuration'ı aynı recovery manifest'e dahil edin. Temiz bir Vaultwarden restore'u ancak vault öğeleri, attachment'lar, Send'ler ve organization üyeliği restore sonrasında temiz bir client ile doğru şekilde sync edildiğinde başarılı sayılır.

Reverse proxy arkasında Vaultwarden için HTTPS gerekir mi?

Public Vaultwarden origin için HTTPS kullanın ve port 80'i internal route üzerinde tutun. Vaultwarden ayarını doğru uygulayın: DOMAIN'i exact external HTTPS origin olarak ayarlayın. Vaultwarden için HTTPS, credentials veya user content'in transit sırasında korunmasını sağlar ve origin-sensitive client davranışını tutarlı tutar.

Bir Vaultwarden upgrade'i nasıl test edilmelidir?

Mevcut Vaultwarden state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Vaultwarden database migration'ları ile Bitwarden client uyumluluğunun birlikte kontrol edilmesi gerektiğinden özellikle dikkatli olun; ADMIN_TOKEN rotation, vault-data migration değil administrator-access değişikliğidir. Data migration ve rollback sınırı anlaşılana kadar önceki Vaultwarden image'ını saklayın.