ద్వారా Matt Connor 2026-10-11

VPSలో Vaultwarden ద్వారా సొంత పాస్‌వర్డ్ మేనేజర్ ఏర్పాటు

Q: Vaultwarden మరియు Bitwarden ఒకటేనా?

ఇది అధికారిక server కాదు; Bitwardenకు అనుకూలమైన స్వతంత్ర server. Vaultwarden, Bitwarden server APIని Rustలో మళ్లీ అమలు చేస్తుంది. అందువల్ల అధికారిక desktop, mobile, browser మరియు CLI clients అన్నీ దీనితో పనిచేస్తాయి. అధికారిక stackతో పోలిస్తే దీనికి చాలా తక్కువ resources అవసరం. Vault format ఒకటే. కాబట్టి export చేసి import చేయడం ద్వారా రెండు దిశల్లోనూ migrate చేయవచ్చు.

Q: నా serverలో అపరిచితులు register కాకుండా ఎలా ఆపాలి?

మీ accountను సృష్టించిన వెంటనే Compose fileలో SIGNUPS_ALLOWED: "false" ను set చేసి, docker compose up -d ను run చేయండి. ఆ తర్వాత /admin లోని Invite User button ద్వారా కొత్త వ్యక్తులను చేర్చండి. వారికి invitation link అందాలంటే SMTP configured అయి ఉండాలి. ఊహించని accounts ఏవీ చేరలేదని నిర్ధారించడానికి admin user listను అప్పుడప్పుడు పరిశీలించండి.

Q: నా Vaultwarden vaultను ఎలా back up చేయాలి?

containerను కొద్దిసేపు stop చేసి, మొత్తం vw-data volumeను, db.sqlite3, attachments/, sends/, config.json మరియు rsa_key.* filesను archive చేయండి. ఆ archiveను server వెలుపలికి copy చేయండి. వీలైతే nightly cron ద్వారా దీన్ని నిర్వహించండి. server నడుస్తున్నప్పుడు live SQLite fileను copy చేస్తే corrupt snapshot ఏర్పడే ప్రమాదం ఉంది. అందువల్ల serverను ఆపి backup తీసుకోండి. ముఖ్యంగా, ఆ backupను ఒకసారి throwaway containerలో restore చేసి login చేయండి. మీరు దానిపై ఆధారపడే ముందు backup నిజంగా పనిచేస్తుందని నిర్ధారించుకోవాలి.

Docker ఉపయోగించి VPSలో Vaultwarden ఎలా ఇన్‌స్టాల్ చేయాలో తెలుసుకోండి. HTTPS సెటప్, అడ్మిన్ టోకెన్, Fail2ban మరియు సురక్షితమైన డేటా బ్యాకప్ పద్ధతుల గురించి పూర్తి వివరాలు ఇక్కడ ఉన్నాయి.

మీరు నిర్మించేది

మీ పూర్తి నియంత్రణలో ఉండే password manager: ఒక చిన్న container లో నడిచే Vaultwarden, HTTPS ను terminate చేసే reverse proxy వెనుక ఉంటుంది. మీ phone, laptop, browser లోని అధికారిక Bitwarden apps అన్నీ దానికి point చేయబడతాయి. Vaultwarden Rust లో Bitwarden server API ను మళ్లీ అమలు చేస్తుంది. ఇది bitwarden.com ఉపయోగించే అదే protocol తో పనిచేస్తుంది. అందువల్ల server ను current గా ఉంచినంతకాలం అధికారిక clients ఎలాంటి మార్పులు లేకుండా పనిచేస్తాయి. అయితే కొత్త client releases కు కొన్నిసార్లు సరిపోలే Vaultwarden release అవసరం కావచ్చు: clients 2026.8.0 మరియు ఆ తరువాతి versions కోసం 1.37.2 అవసరం. అయినప్పటికీ, అనేక containers కలిగిన అధికారిక stack కు బదులుగా ఇది సుమారు 100 MB RAM లో సరిపోతుంది.

ఈ install కోసం Compose లో ఒక డజను lines చాలు. నిజంగా ముఖ్యమైనవి, సమస్యలకు కారణమయ్యేవి ఈ మూడు: web vault ను ఎప్పుడైనా load చేయడానికి ముందే TLS అందుబాటులో ఉండాలి; మీ స్వంత account సృష్టించిన వెంటనే public signups ను మూసివేయాలి; data volume ను backup చేసి test-restore చేయాలి. ఎందుకంటే మీకు చెందిన ప్రతి password ఆ ఒక్క directory లోనే ఉంటుంది.

ముందస్తు అవసరాలు మరియు వాస్తవిక సవాళ్లు

Docker Engine మరియు Compose plugin కలిగిన ఒక VPS, ఇది కొత్తగా ఇన్‌స్టాల్ చేసిన Ubuntu 24.04 KVM బాక్స్‌పై root లేదా sudo అనుమతులతో ఉండాలి. 512 MB RAM దీనికి సరిపోతుంది; 1 GB RAM ఉంటే మరింత సౌకర్యవంతంగా ఉంటుంది. ఇది మీరు రన్ చేయగల అత్యంత తేలికపాటి సేవలలో ఒకటి, ఇది self-hosting కు తగిన సేవల జాబితా లో అగ్రస్థానంలో ఉంటుంది. అయితే, అదే సర్వర్‌లో ఇతర సేవలను కూడా నడుపుతుంటే దానికి తగినట్లుగా బాక్స్ పరిమాణాన్ని ఎంచుకోండి: PhotoPrism లేదా Immich వంటి self-hosted ఫోటో లైబ్రరీలను అదే VPSలో ఉంచితే RAM అవసరం GBలలోకి పెరుగుతుంది, కానీ Vaultwarden కు అంత అవసరం ఉండదు. మీరు తర్వాత జోడించే మీడియా ఫ్రంట్-ఎండ్‌లకు కూడా ఇదే లెక్క వర్తిస్తుంది, ఎందుకంటే Jellyfin లైబ్రరీని 90ల నాటి రెంటల్ స్టోర్ లాగా మార్చడం అంటే అదనంగా ఒక container ఎప్పుడూ రన్ అవ్వడమే కాకుండా, transcoding కోసం అదనపు RAM అవసరమవుతుంది.
VPS యొక్క IPని సూచించే A record (మీకు IPv6 ఉంటే AAAA record కూడా) కలిగిన ఒక డొమైన్ ఉండాలి, ఇది vault.example.com ద్వారా VPSకి పాయింట్ చేయాలి. TLS certificate ఈ నిర్దిష్ట పేరుకే జారీ చేయబడుతుంది, కాబట్టి మీరు ప్రారంభించే ముందే DNS రిజల్యూషన్ పూర్తవ్వాలి.
80 మరియు 443 పోర్టులు ఇంటర్నెట్‌కు అందుబాటులో ఉండాలి, వీటిని మీ reverse proxy ద్వారా మాత్రమే నిర్వహించాలి, ఎట్టి పరిస్థితుల్లోనూ Vaultwarden ద్వారా నేరుగా కాదు. 80వ పోర్ట్ కేవలం ACME certificate challenge మరియు HTTP-to-HTTPS redirect కోసం మాత్రమే ఉపయోగించబడుతుంది.
ముందుగా గుర్తించాల్సిన అతిపెద్ద సవాలు: Bitwarden క్లయింట్లు HTTPS లేని సర్వర్‌తో కనెక్ట్ అవ్వవు. "ముందుగా http ద్వారా పరీక్షించి చూద్దాం" అనే అవకాశం లేదు, ఆ మార్గం పనిచేయదు, దీనికి గల ఖచ్చితమైన కారణం తర్వాత వివరించబడింది.

Vaultwarden ను అధికారిక Bitwarden stack కంటే ఎందుకు ఎంచుకోవాలి

అదే clients, కానీ వనరుల వినియోగం చాలా తక్కువ. సాధారణ అధికారిక self-hosted Bitwarden deployment అనేక containers బండిల్‌గా వస్తుంది. ఇందులో MSSQL Express, Identity, Api, Admin మరియు మరిన్ని ఉంటాయి. దీనికి కనీసం 2 GB RAM అవసరం. Bitwarden, Bitwarden lite ను కూడా అందిస్తుంది. ఇది కనీసం 200 MB RAM అవసరమయ్యే ఒకే Docker image. అయితే ఇది వ్యక్తిగత వినియోగం మరియు home labs కోసం ఉద్దేశించబడింది. business వినియోగం కోసం కాదు. Database మరియు దాని backups బాధ్యతను పూర్తిగా మీకే వదిలేస్తుంది. Vaultwarden ఒకే binary. ఇది default‌గా మొత్తం డేటాను SQLite database‌లో నిల్వ చేస్తుంది. idle స్థితిలో కొన్ని పదుల megabytes మాత్రమే ఉపయోగిస్తుంది. ఒక వ్యక్తి, కుటుంబం లేదా చిన్న బృందం కోసం ఇది స్పష్టమైన ఎంపిక. ఇది Bitwarden APIను నమ్మకంగా అమలు చేస్తుంది కాబట్టి, మీ డేటాను Vaultwarden మరియు bitwarden.com మధ్య సులభంగా మార్చుకోవచ్చు.

మీరు వదులుకునేది enterprise సౌకర్యాల్లో ఎక్కువ భాగం. SCIM provisioning అందుబాటులో లేదు. అయితే OpenID Connect SSO support 1.35.0లో వచ్చింది. మీరు operator కాబట్టి patching, HTTPS మరియు backups బాధ్యతలు మీవే. ఈ guide ఆ మూడు బాధ్యతల గురించే.

HTTPS ఎందుకు తప్పనిసరి

Bitwarden web vault మరియు browser extensions, Web Crypto API (window.crypto.subtle) ఉపయోగించి browser లోనే మీ encryption keys ను ఉత్పత్తి చేస్తాయి. Browsers, crypto.subtle ను secure context లో మాత్రమే అందిస్తాయి. HTTPS లేదా http://localhost, http://127.0.0.1 వంటి loopback addresses ఇందుకు ప్రత్యేక మినహాయింపులు. సాధారణ http://vault.example.com పై ఇది undefined అవుతుంది. అందువల్ల app key ను ఉత్పత్తి చేయగానే error వస్తుంది, console లో ఇది కనిపిస్తుంది:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'importKey')

Page నిలిచిపోవచ్చు లేదా సాధారణ crypto error చూపించవచ్చు. ఏదీ log in కాదు. Desktop, mobile మరియు browser clients self-hosted URL కు తమ స్వంత check ను నిర్వహిస్తాయి. http లేదా అందుబాటులో లేని endpoint ను ఉపయోగిస్తే అవి ఈ error తో తిరస్కరిస్తాయి:

This is not a recognized Bitwarden server. You may need to check with your provider or update your server.

రెండింటికీ కారణం ఒకటే: చెల్లుబాటు అయ్యే HTTPS లేదు. కాబట్టి ముందుగా TLS ను ఏర్పాటు చేయాలి. Vault ను http ద్వారా ఎప్పుడూ తెరవకూడదు, త్వరగా పరిశీలించడానికి కూడా కాదు.

దశ 1, DNS మరియు రివర్స్ ప్రాక్సీ (ముందుగా TLS)

మీ VPS వైపు రికార్డును పాయింట్ చేయండి మరియు అది సరైన అడ్రస్‌కు రిజాల్వ్ అవుతుందో లేదో నిర్ధారించుకోండి:

dig +short vault.example.com

అది ప్రింట్ చేసే లైన్ మీ VPS IP అయి ఉండాలి. అది ఖాళీగా ఉన్నా లేదా తప్పుగా ఉన్నా, DNS ను సరిచేసి TTL పూర్తయ్యే వరకు వేచి ఉండండి, ఎందుకంటే రిజాల్వ్ కాని పేరుతో సర్టిఫికేట్ జారీ చేయడం విఫలమవుతుంది.

HTTPS ఫ్రంట్ ఎండ్ కోసం ఈ గైడ్ Traefik ను ఉపయోగిస్తుంది, ఇది Let's Encrypt సర్టిఫికేట్‌లను ఆటోమేటిక్‌గా జారీ చేస్తుంది మరియు పునరుద్ధరిస్తుంది, అలాగే నేరుగా Compose లోకి అమరుస్తుంది. మీరు ఇప్పటికే దీన్ని రన్ చేయకపోతే, ముందుగా Traefik రివర్స్ ప్రాక్సీ మరియు ఆటోమేటిక్ TLS సెటప్ అనుసరించండి; ఇది ఒక ఎక్స్‌టర్నల్ Docker నెట్‌వర్క్ (క్రింద ఉన్న proxy) మరియు ఒక ACME రిజాల్వర్‌ను (letsencrypt) సృష్టిస్తుంది, దీనికి Vaultwarden సర్వీస్ అనుసంధానించబడుతుంది. మాన్యువల్‌గా జారీ చేసిన సర్టిఫికేట్‌తో సాధారణ nginx కూడా Vaultwarden వైపు నుండి అదే విధంగా పనిచేస్తుంది.

Traefik కు బదులుగా nginx మరియు Certbot కావాలా? Vaultwarden ను 127.0.0.1:8080 పై ఉంచండి (సర్వీస్‌కు ports: ["127.0.0.1:8080:80"] జోడించి, Traefik లేబుల్స్‌ను తొలగించండి), ఆపై సర్టిఫికేట్‌ను జారీ చేసి దానికి ప్రాక్సీ చేయండి. సర్టిఫికేట్ భాగం Certbot మరియు nginx తో Let's Encrypt సర్టిఫికేట్‌లను జారీ చేయడం లో వివరించబడింది. నోటిఫికేషన్ పాత్‌లో WebSocket అప్‌గ్రేడ్ అనేది చాలా ముఖ్యమైన అదనపు అంశం:

server {
    listen 443 ssl;
    server_name vault.example.com;

    client_max_body_size 525M;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

X-Real-IP లైన్‌ను గమనించండి, ఇది Fail2ban కు 127.0.0.1 కు బదులుగా అసలైన దాడి చేసే వ్యక్తిని గుర్తించడానికి అనుమతిస్తుంది. Traefik లేదా nginx లలో ఏది ముందున్నా, ఈ గైడ్‌లోని మిగిలినవన్నీ ఒకే విధంగా ఉంటాయి.

దశ 2, Compose ఫైల్

ముందుగా ప్రాజెక్ట్ డైరెక్టరీని సృష్టించండి. ఈ గైడ్ /opt/vaultwarden ను ఉపయోగిస్తుంది, ఇది Compose ప్రాజెక్ట్ పేరును, తద్వారా డేటా వాల్యూమ్‌ను vaultwarden_vw-data గా స్థిరంగా ఉంచుతుంది; కింద పేర్కొన్న Fail2ban మరియు బ్యాకప్ దశలు ఆ ఖచ్చితమైన పేరుపైనే ఆధారపడి ఉంటాయి.

sudo mkdir -p /opt/vaultwarden
cd /opt/vaultwarden

ఆ డైరెక్టరీలో అడ్మిన్ సీక్రెట్ మరియు Compose ఫైల్ కోసం ఒక .env ని సృష్టించండి.

# .env
ADMIN_TOKEN=paste-a-strong-token-here

openssl rand -base64 48 తో ఆ టోకెన్‌ను జనరేట్ చేసి, అందులో పేస్ట్ చేయండి. (మరింత బలమైన హ్యాష్డ్ ఫార్మాట్ గురించి తర్వాత చూద్దాం; ప్రారంభానికి పొడవైన రాండమ్ స్ట్రింగ్ సరిపోతుంది.)

# docker-compose.yml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"          # closed in Step 4, keep true just to register
      ADMIN_TOKEN: "${ADMIN_TOKEN}"
      IP_HEADER: "X-Forwarded-For"     # X-Real-IP if your proxy sends that instead
      LOG_FILE: "/data/vaultwarden.log"
      LOG_LEVEL: "warn"
    volumes:
      - vw-data:/data
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.vw.rule=Host(`vault.example.com`)"
      - "traefik.http.routers.vw.entrypoints=websecure"
      - "traefik.http.routers.vw.tls.certresolver=letsencrypt"
      - "traefik.http.services.vw.loadbalancer.server.port=80"

volumes:
  vw-data:

networks:
  proxy:
    external: true

ఈ ఫైల్‌కు సంబంధించి రెండు అంశాలు మొత్తం డిజైన్‌ను నిర్ణయిస్తాయి. ఇందులో ఎటువంటి ports: మ్యాపింగ్ లేదు, కాబట్టి Vaultwarden కేవలం Traefik మరియు దాని TLS ద్వారా మాత్రమే అందుబాటులో ఉంటుంది. హోస్ట్ మెషీన్‌పై పోర్ట్‌ను పబ్లిష్ చేయడం వల్లనే పొరపాటున ప్రజలు vault ను http ద్వారా సర్వ్ చేస్తుంటారు. అలాగే DOMAIN అనేది ఖచ్చితమైన పూర్తి పబ్లిక్ HTTPS URL అయి ఉండాలి: ఇది అటాచ్‌మెంట్ లింకులు, WebAuthn 2FA మరియు నోటిఫికేషన్ ఎండ్‌పాయింట్‌లలో అంతర్భాగంగా ఉంటుంది, కాబట్టి తప్పుగా లేదా http విలువను ఇస్తే సైట్ లోడ్ అయినప్పటికీ అవి పనిచేయవు. latest ట్యాగ్ అనేది సాధారణంగా వాడే never-latest నియమానికి ఒక ఉద్దేశపూర్వక మినహాయింపు. Vaultwarden తన stable releases ను ఒకే rolling image గా విడుదల చేస్తుంది, :testing అనేది ప్రత్యేకమైన pre-release ఛానల్. కాబట్టి, మీరు అప్‌డేట్ చేసే ముందు రిలీజ్ నోట్స్‌ను పరిశీలించి, ఉద్దేశపూర్వకంగానే pull చేయండి. అయితే ఈ మినహాయింపు చాలా పరిమితమైనది: ఎక్కువ కాలం నడిచే చాలా కంటైనర్‌లను ఒక ఖచ్చితమైన ట్యాగ్‌కు పిన్ చేయడం మంచిది. ఇదే పద్ధతి అదే VPSలో నడిచే always-on agent ను రీబూట్‌లు మరియు పుల్స్ తర్వాత కూడా స్థిరంగా ఉంచుతుంది.

దీనిని ప్రారంభించి లాగ్‌ను గమనించండి:

docker compose up -d
docker compose logs -f vaultwarden

సరైన ప్రారంభం Rocket has launched from http://0.0.0.0:80 వంటి లైన్‌తో ముగుస్తుంది. సర్టిఫికేట్‌ను పొందడానికి Traefik కు కొన్ని సెకన్ల సమయం ఇవ్వండి, ఆపై https://vault.example.com ను లోడ్ చేయండి. మీకు ఎటువంటి సర్టిఫికేట్ హెచ్చరికలు లేకుండా, సరైన ప్యాడ్‌లాక్ గుర్తుతో Bitwarden వెబ్ వాల్ట్ కనిపిస్తుంది.

దశ 3: బలమైన ADMIN_TOKEN మరియు $$ trap

ADMIN_TOKEN మీ instance లోని ప్రతి user మరియు setting ను చదవగలిగే panel అయిన /admin ను రక్షిస్తుంది. అందువల్ల దీన్ని root password లాగా పరిగణించండి. రెండు రూపాలు పనిచేస్తాయి.

మీరు ఇప్పటికే openssl rand -base64 48 తో రూపొందించిన random string సరళమైన రూపం. base64 లో ఎప్పుడూ $ ఉండదు కాబట్టి, escaping అవసరం లేకుండా అది నేరుగా .env లో ఉంచవచ్చు.

బలమైన రూపం Argon2 PHC hash. అందువల్ల plaintext token disk లో ఎప్పుడూ నిల్వ ఉండదు. అదే image కు ఒకదాన్ని రూపొందించండి:

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

ఇది రెండుసార్లు prompt చూపించి, $argon2id$v=19$... తో ప్రారంభమయ్యే string ను ముద్రిస్తుంది. ఒక గంట సమయం వృథా చేసే trap ఇదే: Docker Compose $ ను variable interpolation గా పరిగణిస్తుంది. కాబట్టి Compose file లోని environment: కింద hash ను నేరుగా paste చేస్తే, ప్రతి $ ను $$ గా రెండుసార్లు రాయాలి. అక్కడ value ను quotes లో ఉంచడం సమస్య కాదు; escaping చేయడం ముఖ్యం:

    environment:
      ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$c29tZXNhbHQ$$RdescudvJCsgt3ub+b+dWRWJTmaaJObG

hash ను .env లో ఉంచాలనుకుంటే నియమం మారుతుంది: ఒకే $ signs ను అలాగే ఉంచి, మొత్తం value ను single quotes (ADMIN_TOKEN='$argon2id$v=19$...') లో చుట్టండి. అప్పుడు Compose file లోని ప్రస్తుత ${ADMIN_TOKEN} line దాన్ని ఉపయోగిస్తుంది. .env లోని $ ను ఎప్పుడూ రెండుసార్లు రాయకండి. Compose file లోనే ఒకే $ signs ఉంచితే, Compose The "argon2id" variable is not set గురించి warning ఇస్తుంది మరియు token ను ఖాళీ చేస్తుంది. అప్పుడు /admin మీ సరైన password ను తిరస్కరిస్తుంది. docker compose up -d అమలు చేసి, prompt వద్ద మీరు టైప్ చేసిన plaintext ను మీ స్వంత password store లో భద్రంగా ఉంచండి.

దశ 4, మీ ఖాతాను నమోదు చేయండి, ఆపై తలుపును లాక్ చేయండి

SIGNUPS_ALLOWED: "true" తో, https://vault.example.com ని తెరవండి, Create account పై క్లిక్ చేయండి, మరియు మీ ఇమెయిల్ మరియు బలమైన master password తో నమోదు చేసుకోండి. ఈ master password తిరిగి పొందడం సాధ్యం కాదు, దీనికి reset ఆప్షన్ ఉండదు, కాబట్టి ముందుగా దీన్ని సురక్షితమైన చోట భద్రపరుచుకోండి.

ఇప్పుడు తలుపును మూసివేయండి. signups ఆపివేయడానికి Compose ఫైల్‌ను సవరించండి:

      SIGNUPS_ALLOWED: "false"

docker compose up -d తో మళ్ళీ అమలు చేయండి. ఇది మీరు వాయిదా వేయదగ్గ hardening కాదు. దీన్ని తెరిచి ఉంచితే, URL తెలిసిన ఎవరైనా, మరియు crawlers కూడా, మీ సర్వర్‌లో ఖాతాను సృష్టించగలరు. వారు మీ vault ను చదవలేరు, కానీ వారు వనరులను వినియోగిస్తారు మరియు మీ ప్రైవేట్ instance ను బహిరంగ సేవగా మారుస్తారు. మీరు దీన్ని ఆన్ లో ఉంచారని చెప్పడానికి సంకేతం: /admin మీరు సృష్టించని ఖాతాలను జాబితా చేస్తుంది.

తరువాత కుటుంబ సభ్యులను లేదా సహోద్యోగులను చేర్చడానికి, బహిరంగ signups ను మళ్ళీ తెరవాల్సిన అవసరం లేదు, /admin లోని Invite User బటన్‌ను ఉపయోగించండి; ఆ పద్ధతి పని చేయాలంటే SMTP కాన్ఫిగర్ చేయబడి ఉండాలి, అప్పుడే ఆహ్వానించబడిన వారికి వారి లింక్ అందుతుంది.

దశ 5, /admin ను తెరవడం

https://vault.example.com/admin కు వెళ్లి plaintext admin token నమోదు చేయండి. ఇది random string లేదా మీరు hash చేసిన password కావాలి; hash స్వయంగా కాదు. లోపల users జాబితాను చూడవచ్చు, settings సర్దుబాటు చేయవచ్చు, test email పంపవచ్చు మరియు database snapshot తీసుకోవచ్చు.

దానికి బదులుగా పేజీ The admin panel is disabled, please configure the 'ADMIN_TOKEN' variable to enable it అని చూపిస్తే, ADMIN_TOKEN ఖాళీగా ఉంది లేదా unset అయింది. అందువల్ల panel పూర్తిగా నిలిపివేయబడుతుంది. మీకు అది ఎప్పుడూ అవసరం లేకపోతే ఇది కూడా సరైన ఎంపిక. Panel లోడ్ అయినా token ను తిరస్కరిస్తే, దిగువ failure list లోని $$ escaping సమస్యను చూడండి. Token మర్చిపోయారా? Recovery prompt లేదు. .env లేదా Compose file ను సవరించి, కొత్త token సెట్ చేసి, docker compose up -d.

దశ 6, Bitwarden క్లయింట్‌లను కనెక్ట్ చేయడం

ప్రతి అధికారిక క్లయింట్ ఒక self-hosted సర్వర్‌కు కనెక్ట్ అవ్వగలదు, కాబట్టి సాధారణ స్టోర్ల నుండి Bitwarden డెస్క్‌టాప్, మొబైల్ లేదా బ్రౌజర్ క్లయింట్‌ను ఇన్‌స్టాల్ చేయండి. మీకు ప్రత్యేకమైన Vaultwarden బిల్డ్ అవసరం లేదు.

లాగిన్ అయ్యే ముందు, లాగిన్ స్క్రీన్‌పై ఉన్న సెట్టింగ్స్ గేర్ ఐకాన్‌ను (దీనిని Self-hosted లేదా Region → Self-hosted అని లేబుల్ చేస్తారు) ఓపెన్ చేయండి. Server URL ను https://vault.example.com కి సెట్ చేసి, సేవ్ చేయండి. ఆ తర్వాత మీరు రిజిస్టర్ చేసుకున్న ఈమెయిల్ మరియు మాస్టర్ పాస్‌వర్డ్‌తో లాగిన్ అవ్వండి; క్లయింట్ వెంటనే కనెక్ట్ అయ్యి, క్రెడెన్షియల్స్‌ను ఫిల్ చేయడానికి మరియు సేవ్ చేయడానికి అనుమతి అడుగుతుంది.

ఒకవేళ క్లయింట్ This is not a recognized Bitwarden server. You may need to check with your provider or update your server. అని చూపిస్తే, URL తప్పుగా ఉండటం, http వాడటం లేదా సర్టిఫికేట్ నమ్మదగినది కాకపోవడం కారణం కావచ్చు. ముందుగా https://vault.example.com బ్రౌజర్‌లో సరిగ్గా లోడ్ అవుతుందో లేదో తనిఖీ చేయండి. ఇతర పరికరాల్లో అప్‌డేట్‌లు నెమ్మదిగా ఉంటే, అది WebSocket పుష్ సమస్య కావచ్చు, దీని గురించి కింద వివరించబడింది.

లాగిన్ endpoint కోసం Fail2ban jail

Vaultwarden ప్రతి విఫలమైన login ను LOG_FILE ద్వారా నిర్దేశించిన file లో log చేస్తుంది. Brute-force రక్షణకు అవసరమైన సమాచారం ఇదే. మీరు ఇప్పటికే Fail2ban నడుపుతున్నట్లయితే, install మరియు ప్రాథమిక విధానాలు Fail2ban SSH hardening guide లో ఉన్నాయి. ఇక్కడ vault కోసం ఒక jail జోడిస్తాము.

ముందుగా host పై named volume ఎక్కడ ఉందో కనుగొనండి. అప్పుడు Fail2ban ఆ log ను చదవగలదు:

docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}'

ఇది సాధారణంగా /var/lib/docker/volumes/vaultwarden_vw-data/_data వంటి output ను చూపిస్తుంది. దాని లోపల log vaultwarden.log లో ఉంటుంది. Filter ను సృష్టించండి:

# /etc/fail2ban/filter.d/vaultwarden.conf
[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

తరువాత jail ను సృష్టించండి:

# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled   = true
filter    = vaultwarden
logpath   = /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log
banaction = iptables-allports
chain     = DOCKER-USER
maxretry  = 5
findtime  = 600
bantime   = 3600

sudo systemctl restart fail2ban తో reload చేసి, sudo fail2ban-client status vaultwarden తో నిర్ధారించండి.

ఈ రక్షణ పనిచేస్తుందో లేదో మూడు Docker వివరాలు నిర్ణయిస్తాయి. మొదట, ప్రతి విఫల ప్రయత్నంలో log IP: 127.0.0.1 లేదా మీ proxy address ను చూపిస్తే, Vaultwarden proxy ని ban చేస్తోంది. మీ proxy వాస్తవంగా పంపే header కు IP_HEADER ను సెట్ చేయండి. Traefik కోసం X-Forwarded-For, పైన ఉన్న nginx block కోసం X-Real-IP, Cloudflare వెనుక ఉంటే CF-Connecting-IP ఉపయోగించండి. 1.37.4 నుంచి X-Forwarded-For తో, IP_HEADER_TRUSTED_PROXIES లో లేని కుడివైపు address ను Vaultwarden తీసుకుంటుంది. దీని default local. అదే host లేదా Docker network లో ఉన్న proxy కి ఇది సరిపోతుంది. మీ proxy ముందు CDN ఉంటే, దాని addresses ను కూడా అక్కడ జాబితా చేయండి.

రెండవది, సరైన iptables chain మీ proxy పై ఆధారపడి ఉంటుంది. Published ports తో Traefik ను container గా నడిపితే, traffic Docker యొక్క FORWARD path గుండా వెళుతుంది. అందువల్ల ban DOCKER-USER లో ఉండాలి. అయితే Step 1 లోని host-nginx ఎంపికను ఉపయోగిస్తే, connections host పై ఉన్న nginx వద్ద terminate అవుతాయి మరియు INPUT chain ను ఉపయోగిస్తాయి. DOCKER-USER ban వాటిని చూడదు. ఈ సందర్భంలో chain = DOCKER-USER line ను తొలగించండి. అప్పుడు Fail2ban default INPUT chain ను ఉపయోగిస్తుంది.

మూడవది, port-based default కు బదులుగా banaction = iptables-allports ఉపయోగించండి. ఈ jail ఏ port ను నిర్వచించదు. DOCKER-USER లో all-ports ban ఉంచితే, ఆ host పై published చేసిన ప్రతి service నుంచి దాడి చేసే address ను సులభంగా block చేయవచ్చు.

దశ 8, vault ను బ్యాకప్ చేసి, దాన్ని వాస్తవంగా పునరుద్ధరించండి

vw-data volume అంటే మీ password manager. ఇందులో db.sqlite3 (ప్రతి entry), attachments/ మరియు sends/ directories, login sessions కు సంతకం చేసే rsa_key.* files, అలాగే admin panel నుంచి తీసుకునే config.json ఉంటాయి. వీటిలో ఏదైనా మినహాయించే backup అవసరమైనప్పుడు విఫలమవుతుంది.

Vaultwarden file రాస్తున్న సమయంలో db.sqlite3 ను copy చేస్తే సగం రాసిన, దెబ్బతిన్న file capture కావచ్చు. అందువల్ల cold snapshot తీసుకోండి. downtime కొన్ని seconds మాత్రమే ఉంటుంది:

#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date +%F)
DEST=/root/vw-backups
VOL=$(docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}')
mkdir -p "$DEST"
docker compose -f /opt/vaultwarden/docker-compose.yml stop vaultwarden
tar czf "$DEST/vw-$STAMP.tgz" -C "$VOL" .
docker compose -f /opt/vaultwarden/docker-compose.yml start vaultwarden

దీన్ని ప్రతి రాత్రి cron నుంచి run చేసి, .tgz ను server వెలుపలికి copy చేయండి. మీరు రక్షిస్తున్న server లో మాత్రమే ఉన్న backup, backup కాదు. దీన్ని భద్రంగా పంపే సరైన మార్గం మరో server లేదా object storage కు nightly restic backup ఉపయోగించడం. ఇది archive ను encrypt చేసి, పునరావృత snapshots ను మీకు బదులుగా deduplicate చేస్తుంది. Admin panel లోని Backup Database button SQLite file కు మాత్రమే ఉపయోగపడే hot snapshot. అయితే ఇది attachments మరియు keys ను మినహాయిస్తుంది.

ఇప్పుడు నిజమైన backup ను కేవలం ఆశాజనకమైన backup నుంచి వేరు చేసే విధానం: దాన్ని ఒక్కసారి restore చేసి, పని చేస్తుందని నిర్ధారించండి:

mkdir -p /tmp/vw-restore
tar xzf /root/vw-backups/vw-2026-07-15.tgz -C /tmp/vw-restore
docker run --rm -p 127.0.0.1:8888:80 -v /tmp/vw-restore:/data vaultwarden/server

మీ laptop నుంచి ssh -L 8888:127.0.0.1:8888 you@your-vps తో tunnel చేసి, http://localhost:8888 (లేదా http://127.0.0.1:8888) ను open చేయండి. Loopback addresses secure context గా పరిగణించబడతాయి కాబట్టి ఇక్కడ crypto.subtle అందుబాటులో ఉంటుంది. ఈ సందర్భంలో vault plain http ద్వారా decrypt అవుతుంది. అనుమతించబడే address రకం ఇదొక్కటే. మీ master password తో log in చేసి, మీ entries ఉన్నాయో నిర్ధారించండి. అవి ఉంటే మీ database, RSA keys మరియు master password అన్నీ సరిగ్గా పునరుద్ధరించబడ్డాయని అర్థం. కొత్త VPS పై minutes లో rebuild చేయవచ్చు. Ctrl-C తో container ను stop చేసి, /tmp/vw-restore ను delete చేయండి. Server పై internet కు ఎప్పుడూ అందుబాటులో ఉండకూడని ఇతర admin UI ల కోసం కూడా ఈ tunnel పద్ధతిని ఉపయోగించండి. ఇదే విధంగా port 5173 పై self-hosted open-kritt security scanner ను కూడా access చేయవచ్చు.

వైఫల్య పరిస్థితులు, మీరు చూడబోయే సందేశాలతో

Cannot read properties of undefined (reading 'importKey') బ్రౌజర్ కన్సోల్‌లో కనిపిస్తుంది. Vault ను http ద్వారా లోడ్ చేశారు. అందువల్ల crypto.subtle నిర్వచించబడలేదు. దాన్ని https:// ద్వారా మాత్రమే యాక్సెస్ చేయండి. Proxy వద్ద HTTP-to-HTTPS redirect ను కూడా జోడించండి.

క్లయింట్‌లో This is not a recognized Bitwarden server... కనిపిస్తుంది. Server URL http కావచ్చు, తప్పుగా టైప్ చేసి ఉండవచ్చు లేదా certificate ను నమ్మదగినదిగా గుర్తించకపోవచ్చు. https://vault.example.com వద్ద చెల్లుబాటు అయ్యే padlock కనిపిస్తుందో నిర్ధారించండి. తరువాత client యొక్క self-hosted settings లో దాన్ని మళ్లీ నమోదు చేయండి.

సరైన password ను /admin తిరస్కరిస్తుంది. Argon2 hash లోని escaping పోయి ఉండవచ్చు. Compose file లో ప్రతి $ తప్పనిసరిగా $$ అయి ఉండాలి. అయితే .env లో single quotes మధ్య ఉన్న single $ మాత్రం అలాగే ఉండాలి. లేదా hash సూచించే plaintext కు బదులుగా మీరు hash నే నమోదు చేసి ఉండవచ్చు.

పరికరాల మధ్య sync నెమ్మదిగా ఉంటుంది; కన్సోల్‌లో WebSocket connection to 'wss://vault.example.com/notifications/hub' failed కనిపిస్తుంది. Proxy Upgrade/Connection headers ను forward చేయడం లేదు. Traefik దీన్ని స్వయంచాలకంగా చేస్తుంది. nginx కోసం Step 1 లోని రెండు upgrade lines అవసరం. Vault పనిచేస్తూనే ఉంటుంది, కానీ తెరిచినప్పుడు మాత్రమే sync అవుతుంది. v1.31.0 నుంచి పాత dedicated port 3012 తొలగించబడింది. అందువల్ల ప్రత్యేక WebSocket route అవసరం లేదు.

Fail2ban ban చేసినట్లు చూపించినా attacker కనెక్ట్ అవుతూనే ఉంటాడు. IP_HEADER తప్పుగా ఉన్నందువల్ల అది 127.0.0.1 ను ban చేస్తుండవచ్చు. లేదా ban తప్పు iptables chain లో ఉండవచ్చు. chain = DOCKER-USER మరియు banaction = iptables-allports సెట్ చేయండి.

అప్‌గ్రేడ్‌లు

కొత్త image ను pull చేసి, కంటైనర్‌ను తిరిగి సృష్టించండి; named volume మరియు మీ డేటా మొత్తం అలాగే ఉంటాయి:

docker compose pull
docker compose up -d

Vaultwarden తరచుగా కొత్త వెర్షన్‌లను విడుదల చేస్తుంది. ప్యాచ్ వెర్షన్‌ను ఫిక్స్ చేసే బదులు ప్రాజెక్ట్ విడుదల నోట్స్ గమనిస్తూ ఉండండి, ఎందుకంటే కొన్ని విడుదలలలో మైగ్రేషన్ సూచనలు ఉంటాయి. ఏదైనా ప్రధాన అప్‌గ్రేడ్‌కు ముందు కొత్త బ్యాకప్‌ను తీసుకోండి; ఒకవేళ సమస్య వస్తే, tarball ను కొత్త volume లోకి restore చేయడం ద్వారా మీరు పాత స్థితికి వెళ్లవచ్చు.

FAQ

Vaultwarden మరియు Bitwarden ఒకటేనా?

ఇది అధికారిక server కాదు; Bitwarden‌కు అనుకూలమైన స్వతంత్ర server. Vaultwarden, Bitwarden server APIని Rustలో మళ్లీ అమలు చేస్తుంది. అందువల్ల అధికారిక desktop, mobile, browser మరియు CLI clients అన్నీ దీనితో పనిచేస్తాయి. అధికారిక stackతో పోలిస్తే దీనికి చాలా తక్కువ resources అవసరం. Vault format ఒకటే. కాబట్టి export చేసి import చేయడం ద్వారా రెండు దిశల్లోనూ migrate చేయవచ్చు.

నాకు నిజంగా HTTPS అవసరమా, లేక నా LANలో httpపై అమలు చేయవచ్చా?

loopback test మినహా మిగతా సందర్భాల్లో HTTPS అవసరం. Bitwarden web vault మరియు extensions browser యొక్క Web Crypto APIని ఉపయోగిస్తాయి. ఇది secure contextలో మాత్రమే అందుబాటులో ఉంటుంది. అందువల్ల plain httpపై client Cannot read properties of undefined ను చూపించి login చేయదు. పనిచేసే ఏకైక http addresses loopback addresses మాత్రమే. ఉదాహరణకు http://localhost లేదా http://127.0.0.1. అందుకే Step 8లోని restore test SSH tunnelను ఉపయోగిస్తుంది.

నా serverలో అపరిచితులు register కాకుండా ఎలా ఆపాలి?

మీ accountను సృష్టించిన వెంటనే Compose fileలో SIGNUPS_ALLOWED: "false" ను set చేసి, docker compose up -d ను run చేయండి. ఆ తర్వాత /admin లోని Invite User button ద్వారా కొత్త వ్యక్తులను చేర్చండి. వారికి invitation link అందాలంటే SMTP configured అయి ఉండాలి. ఊహించని accounts ఏవీ చేరలేదని నిర్ధారించడానికి admin user listను అప్పుడప్పుడు పరిశీలించండి.

నా Vaultwarden vaultను ఎలా back up చేయాలి?

containerను కొద్దిసేపు stop చేసి, మొత్తం vw-data volumeను, db.sqlite3, attachments/, sends/, config.json మరియు rsa_key.* filesను archive చేయండి. ఆ archiveను server వెలుపలికి copy చేయండి. వీలైతే nightly cron ద్వారా దీన్ని నిర్వహించండి. server నడుస్తున్నప్పుడు live SQLite fileను copy చేస్తే corrupt snapshot ఏర్పడే ప్రమాదం ఉంది. అందువల్ల serverను ఆపి backup తీసుకోండి. ముఖ్యంగా, ఆ backupను ఒకసారి throwaway containerలో restore చేసి login చేయండి. మీరు దానిపై ఆధారపడే ముందు backup నిజంగా పనిచేస్తుందని నిర్ధారించుకోవాలి.

నా passwordsను self-host చేయడం నిజంగా సురక్షితమేనా?

అవును. ఈ guideలో చెప్పిన మూడు విషయాలను అమలు చేసినప్పుడు ఇది సురక్షితం: నిజమైన HTTPS, మూసివేసిన signupsతో పాటు బలమైన admin token, మరియు పరీక్షించిన backups. మీ vault మీ master passwordతో client-sideలోనే encrypt అవుతుంది. అందువల్ల serverకు కూడా మీ passwords plain textలో కనిపించవు. db.sqlite3 దొంగిలించబడినా, master password లేకుండా మీ entries బయటపడవు. అయితే serverలో account emails మరియు ప్రతి master password నుంచి ఉత్పన్నమైన salted hash ఉంటాయి. Attacker వీటిని offlineగా crack చేయడానికి ప్రయత్నించవచ్చు. కాబట్టి database fileను మరియు దాని ప్రతి copyని రక్షించండి. Patching మరియు backups ఇప్పుడు మీ బాధ్యత కావడం ఈ విధానంలోని trade-off. అందుకే ఇక్కడ Fail2ban మరియు restore విధానం ఐచ్చికాలు కావు. ఇవి అమల్లోకి వచ్చిన తర్వాత, self-hosted vaultపై వాస్తవంగా ఎక్కడ దాడి చేయవచ్చో మరింత పరిశీలించడం ఉపయోగకరమైన తదుపరి దశ. Entries clientలోనే encryptedగా ఉండటంతో, రక్షించాల్సింది admin token మరియు backup archive మాత్రమే.

#vaultwarden #passwords #security #docker #self-hosting