Vaultwardenin Koventaminen: 12 Vaihetta, 90 Min [2026]

Heinäkuun lopussa 2026 tuhannet itseisännöityä Vaultwardenia käyttävät ihmiset avasivat salasanaholvinsa ja näkivät tyhjän listan. Ei virheilmoitusta, ei varoitusta, vain tyhjä kassakaappi. Syynä ei ollut tietomurto vaan Bitwardenin selainlaajennuksen versio 2026.7.0, joka otti käyttöön uuden protokollan ja lakkasi keskustelemasta vanhempien Vaultwarden-palvelinten kanssa. Ratkaisu löytyi nopeasti: päivitys versioon 1.37.0 ja pian sen jälkeen korjausversioon 1.37.1, mutta tapaus muistutti karulla tavalla, että oma salasanapalvelin vaatii jatkuvaa ylläpitoa, ei kertaasennusta.

Tämä opas käy läpi, miten pystytät ja koventat Vaultwarden-palvelimen vuoden 2026 uusimpien tietoturvakorjausten mukaisesti. Käymme läpi 12 vaihetta VPS-palvelimen valmistelusta PostgreSQL-tietokantaan, kaksivaiheiseen tunnistautumiseen, fail2ban-suojaukseen ja varmuuskopiointiin. Lopussa löydät myös kahdeksan yleisintä vikatilannetta ratkaisuineen sekä listan sudenkuopista, joihin moni itseisännöijä kompastuu ensimmäisellä kerralla.

Opas sopii sinulle, jos hallinnoit jo pientä kotipalvelinta tai VPS:ää ja haluat siirtää salasanat pois kolmannen osapuolen pilvestä. Se sopii myös pienelle IT-tiimille, joka miettii, kannattaisiko yrityksen salasanaholvi tuoda oman infran sisään GDPR-riskien pienentämiseksi. Et tarvitse aiempaa Rust- tai Vaultwarden-kokemusta, mutta perustason Linux- ja Docker-tuntemus nopeuttaa etenemistä huomattavasti. Jokainen vaihe sisältää valmiin koodilohkon, jonka voi kopioida suoraan omaan terminaaliin, sekä selityksen siitä, miksi asetus on juuri tällainen eikä jokin muu.

Mikä Vaultwarden on ja miksi se kiinnostaa juuri nyt

Vaultwarden on Rust-kielellä kirjoitettu, avoimen lähdekoodin uudelleentoteutus Bitwardenin palvelinrajapinnasta. Se puhuu samaa protokollaa kuin viralliset Bitwarden-asiakassovellukset (selainlaajennus, työpöytäsovellus, mobiilisovellus, CLI), mutta pyörii murto-osalla virallisen palvelimen resursseista. Yksi vCPU ja 512 megatavua muistia riittää tyypillisesti perheen tai pienen tiimin käyttöön, kun virallinen Bitwarden-palvelinpaketti vaatii huomattavasti enemmän.

Pohjoismaisille käyttäjille itseisännöinti tarkoittaa myös sitä, että salasanaholvin salattu data ei koskaan poistu omalta palvelimelta tai valitulta EU-alueen konesalilta. Vaultwarden-projektin lähdekoodi on julkisesti auditoitavissa GitHub-repositoriossa, ja projekti on yksi suosituimmista itseisännöitävistä salasanahallinnoista koko maailmassa. Salaus ja purku tapahtuvat aina asiakassovelluksessa, joten palvelin näkee vain salattua tekstiä. Tämä ero on tärkeä muistaa: koventaminen ei suojaa itse salattua dataa vaan estää hyökkääjää pääsemästä käsiksi palvelimeen, kirjautumislokeihin tai admin-paneeliin.

Käytännössä Vaultwardenin suosio on kasvanut kolmesta syystä. Ensimmäinen on kustannus: kun pilvipalvelun kuukausimaksu kertautuu jokaisesta käyttäjästä, oma VPS maksaa saman verran riippumatta siitä, onko käyttäjiä viisi vai viisikymmentä. Toinen syy on hallinta: organisaatio päättää itse, kuinka kauan lokeja säilytetään, mistä maasta liikenne reititetään ja kuka pääsee käsiksi varmuuskopioihin. Kolmas syy on läpinäkyvyys: koska lähdekoodi on kokonaan avoin, kuka tahansa voi lukea, miten salasanat käsitellään palvelimella, eikä tarvitse luottaa pelkkään toimittajan lupaukseen.

Heinä-elokuun 2026 tapahtumasarja näytti myös, miten herkkä tämä yhteensopivuus on. Vaultwarden 1.37.0 julkaistiin 24.7.2026 ja korjasi kahdeksan keskitason haavoittuvuutta, muun muassa palvelinpuolen pyyntöväärennöksen (SSRF) kuvakkeidenhakupalvelussa, organisaatioiden välisen kassakaappien näkyvyysbugin ja tunnistautumattoman WebSocket-tulvituksen. Samassa julkaisussa lisättiin tuki niin sanotulle “trusted proxy” -asetukselle, joka vaikuttaa suoraan siihen, miten palvelin lukee IP-osoitteita käänteisproxyn takaa. Korjausversio 1.37.1 ilmestyi 29.7.2026 ja siivosi jäljellä olevat kutsuongelmat sekä Alpine-pohjaisten Docker-kuvien OpenSSL-käännösvirheen.

Vaultwardenin tietoturvahistoria lyhyesti

Yksi syy siihen, miksi Vaultwarden on noussut suosituksi valinnaksi kotilabreissa ja pienissä yrityksissä, on projektin avoimuus omista virheistään. Kun haavoittuvuus löytyy, se dokumentoidaan julkisesti julkaisumuistiossa eikä piiloteta markkinointipuheen taakse. Heinäkuun 2026 kahdeksan keskitason löydöksen lisäksi projektissa on aiempina vuosina korjattu muun muassa organisaatiokutsujen väärinkäyttöön liittyviä bugeja ja liian sallivia CORS-asetuksia. Trendi on ollut selvä: löydökset ovat olleet pääosin keskitason vakavuutta, ei kriittisiä etäkoodinsuoritushaavoittuvuuksia, ja korjaukset ovat tyypillisesti ilmestyneet päivien sisällä raportoinnista.

Tämä ei tarkoita, että itseisännöinti olisi riskitöntä. Se tarkoittaa, että riski on hallittavissa, kunhan seuraat julkaisuja aktiivisesti etkä jätä palvelinta pyörimään vuosikausiksi ilman päivityksiä. Loput tästä oppaasta keskittyvät juuri siihen: miten rakennat asennuksen, joka on helppo pitää ajan tasalla.

Yksi rekisteröinnin ja kutsujen toiminnallisuuteen liittynyt korjaus 1.37.1-versiossa koski juuri tilannetta, jossa kutsulinkki näytti vanhentuneelta, vaikka se ei ollut sitä. Tämäntyyppiset pienet käytettävyysbugit eivät ole tietoturvakriittisiä, mutta ne kertovat, miksi kannattaa aina lukea koko julkaisumuistio eikä vain otsikkoa “sisältää tietoturvakorjauksia”. Osa korjauksista vaikuttaa suoraan siihen, miten sujuvasti pystyt kutsumaan uusia käyttäjiä koventamisen jälkeen.

Kannattaa myös verrata omaa riskiprofiilia siihen, mitä holviin oikeasti tallennetaan. Henkilökohtaisten striimauspalvelujen tunnukset eivät vaadi samaa valvontatasoa kuin tuotantopalvelimien pääkäyttäjätunnukset tai asiakasrekisterin API-avaimet. Mitä arkaluontoisempaa dataa holvi sisältää, sitä perustellumpaa on käyttää tässä oppaassa esiteltyjä lisäsuojia täysimääräisinä sen sijaan, että tyytyisi vain oletusasetuksiin.

GDPR ja pohjoismainen näkökulma datan sijaintiin

Suomalaisille ja pohjoismaisille organisaatioille datan sijainti ei ole pelkkä periaatekysymys vaan usein myös sopimusvaatimus. Julkishallinnon, terveydenhuollon ja finanssialan toimijoilta edellytetään yhä useammin, että arkaluontoinen data, salasanat mukaan lukien, pysyy tietyn maantieteellisen alueen sisällä. Kun Vaultwarden pyörii omalla VPS:llä esimerkiksi suomalaisessa tai muussa EU-alueen konesalissa, koko käsittelyketju on auditoitavissa alusta loppuun, eikä tarvitse selvittää alihankkijaketjua, joka saattaa ulottua kolmansiin maihin.

Tämä ei poista organisaation vastuuta. GDPR:n näkökulmasta itseisännöity palvelin tarkoittaa, että organisaatio itse toimii rekisterinpitäjänä ja on suoraan vastuussa siitä, että tekniset ja organisatoriset suojatoimet ovat asianmukaisia. Käytännössä tämä tarkoittaa juuri niitä asioita, jotka tässä oppaassa käydään läpi: pääsynhallintaa, salausta liikenteessä, lokien rajattua säilytysaikaa ja dokumentoitua varmuuskopiointia. Jos näistä jokin puuttuu, valvova viranomainen voi katsoa suojatoimet riittämättömiksi siinä missä minkä tahansa muunkin järjestelmän kohdalla.

Käytännön vinkkinä kannattaa kirjata tietosuojaselosteeseen tai sisäiseen käsittelyluetteloon lyhyt kuvaus siitä, mistä VPS on vuokrattu, missä maassa konesali sijaitsee ja kuka palvelinta ylläpitää. Kun tämä on dokumentoitu etukäteen, mahdolliseen tietosuojakyselyyn tai auditointiin vastaaminen on huomattavasti nopeampaa kuin tilanteessa, jossa tiedot pitäisi kaivaa esiin jälkikäteen useasta eri paikasta.

Esivaatimukset ennen aloitusta

Varmista ennen aloitusta, että käytössäsi on seuraavat komponentit. Vanhemmillakin versioilla asennus todennäköisesti onnistuu, mutta tässä oppaassa käytetyt asetukset ja korjaukset on testattu näillä versioilla.

Käyttöjärjestelmäksi kannattaa valita jokin pitkän tuen (LTS) Linux-jakelu, esimerkiksi Ubuntu Server 24.04 tai Debian 12, koska niille löytyy valmiit paketointiohjeet ja pisin tuki-ikkuna ilman suurempaa käyttöjärjestelmäpäivitystä. Vältä ajamasta Vaultwardenia samalla palvelimella kuin muita julkisesti avoimia web-sovelluksia, joiden tietoturvasta et ole yhtä tarkka, sillä palomuurisäännöt ja Docker-verkot suojaavat konttien välillä, mutta eivät poista riskiä täysin, jos isäntäkone itsessään kompromisoituu jonkin toisen palvelun kautta.

Komponentti	Versio	Huomio
Vaultwarden	1.37.1 tai uudempi	Pakollinen Bitwarden-asiakkaiden 2026.7.0+ kanssa
Docker Engine	27.x	Ajaa konttia isolaatiossa
Docker Compose	v2.29 tai uudempi	Compose-tiedoston plugin-versio, ei erillinen binääri
PostgreSQL	16	Korvaa oletus-SQLiten tuotantokäytössä
Caddy	2.8.x	Käänteisproxy ja automaattinen TLS
fail2ban	1.1.x	Kirjautumisyritysten rajoitus
UFW	Ubuntu 24.04 -mukana	Palomuuri, joka avaa vain tarvittavat portit
VPS-minimit	1 vCPU / 1 GB RAM	Riittää 1-20 käyttäjän tiimille

Tarvitset lisäksi oman verkkotunnuksen (esim. holvi.omadomain.fi), jonka A-tietue osoittaa VPS:n IP-osoitteeseen, sekä SSH-pääsyn palvelimelle root- tai sudo-oikeuksin. Koko asennus vie noin 90 minuuttia, kun lasketaan mukaan DNS-propagoinnin odotusaika.

Vaihe 1: Palvelimen valmistelu ja palomuuri

Aloita päivittämällä palvelin ja asentamalla UFW-palomuuri. Oletusperiaate on tiukka: sulje kaikki portit oletuksena ja avaa vain SSH, HTTP ja HTTPS. Vaultwarden itse kuuntelee sisäisesti porttia 8080, eikä sitä koskaan tule julkaista suoraan internetiin.

sudo apt update && sudo apt upgrade -y
sudo apt install ufw -y

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Vaihda SSH oletusportista toiseen ja poista salasanapohjainen kirjautuminen käytöstä ennen jatkamista, jos et ole vielä tehnyt niin. Tämä yksi askel poistaa suurimman osan automatisoiduista skannaus- ja murtoyrityksistä.

Kannattaa myös harkita fail2banin asentamista jo tässä vaiheessa suoraan SSH-palvelulle, ennen kuin Vaultwarden on edes pystyssä. Moni VPS-tarjoaja näkee ensimmäiset porttiskannaukset jo minuuttien sisällä palvelimen käyttöönotosta, joten palomuurin pitäisi olla päällä ennen kuin mitään muuta asennetaan. Jos käytät pilvipalveluntarjoajan omaa suojausryhmää (security group) UFW:n lisäksi, pidä molemmat linjassa keskenään: kahden erillisen palomuurisäännöstön ristiriita on yleinen syy siihen, että yhteys katkeaa yllättäen asennuksen puolivälissä.

Vaihe 2: Docker Enginen ja Docker Composen asennus

Vaultwarden pyörii käytännössä aina Docker-kontissa, koska projektin ylläpitäjä julkaisee valmiit kuvat jokaisesta versiosta. Asenna Docker Engine virallisesta arkistosta, älä jakelun omasta pakettivarastosta, sillä jakeluversiot jäävät usein monta kuukautta jälkeen.

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
newgrp docker

docker --version
docker compose version

Varmista, että docker compose version palauttaa vähintään 2.29. Vanhemmat compose-versiot eivät aina tue kaikkia terveystarkistus- ja profiiliavainsanoja, joita käytämme myöhemmin.

Vältä asentamasta Dockeria jakelun omasta apt-arkistosta (esimerkiksi pelkällä apt install docker.io), sillä Ubuntun ja Debianin ylläpitämät versiot ovat usein useita minorversioita jäljessä virallisesta julkaisusta eivätkä sisällä uusimpia tietoturvakorjauksia compose-pluginiin. Virallinen asennusskripti lisää Docker-yhtiön oman apt-arkiston, jolloin saat päivitykset samalla tahdilla kuin projekti ne julkaisee. Lisää käyttäjäsi docker-ryhmään vain, jos hyväksyt, että kyseinen käyttäjä saa käytännössä root-oikeudet isäntäkoneeseen. Tuotantopalvelimella harkitse mieluummin sudo docker -komentojen käyttöä ilman ryhmäjäsenyyttä.

Vaihe 3: PostgreSQL-tietokanta SQLiten sijaan

Vaultwarden toimii oletuksena SQLite-tiedostokannalla, mikä riittää testaukseen mutta ei tuotantoon. SQLite lukitsee koko tietokannan kirjoitusten ajaksi, mikä aiheuttaa viiveitä useamman käyttäjän tiimeissä ja hankaloittaa varmuuskopiointia lennosta. PostgreSQL 16 poistaa molemmat ongelmat.

Luo ensin erillinen Docker-verkko ja tietokantakontti, jota vain Vaultwarden pääsee käyttämään sisäisen verkon kautta, ei koskaan julkisesta internetistä.

Pienelle tiimille oletusasetukset riittävät hyvin, mutta jos käyttäjiä on kymmeniä, kannattaa nostaa PostgreSQL:n max_connections-arvoa ja varata kontille hieman enemmän muistia yhteyspoolia varten. Vaultwarden itse avaa suhteellisen vähän rinnakkaisia tietokantayhteyksiä, joten oletusarvo 100 riittää käytännössä lähes kaikille itseisännöidyille asennuksille, eikä sitä kannata kasvattaa ilman todellista tarvetta, koska jokainen avoin yhteys varaa muistia myös silloin, kun sitä ei käytetä.

version: "3.9"
services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: vaultwarden
      POSTGRES_USER: vw_admin
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    networks:
      - vw_internal
    secrets:
      - db_password

networks:
  vw_internal:
    internal: true

secrets:
  db_password:
    file: ./secrets/db_password.txt

Käytä secrets-lohkoa suorien ympäristömuuttujien sijaan aina, kun se on mahdollista. Ympäristömuuttujat näkyvät docker inspect -komennon tulosteessa kenelle tahansa, jolla on pääsy Docker-daemoniin, kun taas secrets-tiedosto luetaan vain kontin sisäisestä tiedostojärjestelmästä.

Generoi tietokannan salasana etukäteen komennolla openssl rand -base64 32 > secrets/db_password.txt ja rajaa tiedoston oikeudet komennolla chmod 600. Merkitse vw_internal-verkko internal: true -asetuksella, jolloin Docker ei reititä siitä liikennettä ulos isäntäkoneen verkkorajapinnan kautta lainkaan. Tämä tarkoittaa käytännössä, että vaikka joku onnistuisi murtautumaan toiseen samalla palvelimella ajettavaan konttiin, se ei pääse suoraan keskustelemaan tietokantakontin kanssa ilman erillistä reititystä samaan sisäverkkoon.

Vaihe 4: Vaultwarden 1.37.1:n docker-compose-määrittely

Seuraavaksi lisäät itse Vaultwarden-palvelun samaan compose-tiedostoon. Kiinnitä kuva täsmälliseen versioon 1.37.1, älä käytä latest-tagia. Kiinnitetty versio takaa, että päivität tietoisesti etkä vahingossa keskellä yötä ajastetun cronin kautta.

  vaultwarden:
    image: vaultwarden/server:1.37.1
    restart: unless-stopped
    depends_on:
      - db
    environment:
      DATABASE_URL: postgresql://vw_admin:PASSWORD@db/vaultwarden
      DOMAIN: "https://holvi.omadomain.fi"
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "true"
      WEBSOCKET_ENABLED: "true"
      ROCKET_PORT: "8080"
      IP_HEADER: "X-Real-IP"
    volumes:
      - ./vw-data:/data
    networks:
      - vw_internal
      - vw_public
    expose:
      - "8080"

networks:
  vw_public:
    driver: bridge

Huomaa SIGNUPS_ALLOWED: "false". Luo ensin oma tilisi arvolla true, kirjaudu sisään, ja käännä arvo sen jälkeen heti false:ksi. Uusia käyttäjiä kutsutaan tästä eteenpäin INVITATIONS_ALLOWED-asetuksen kautta, ei avoimen rekisteröinnin kautta.

WEBSOCKET_ENABLED: "true" kannattaa jättää päälle, vaikka se lisää yhden liikkuvan osan konfiguraatioon. Ilman sitä asiakassovellukset joutuvat kyselemään muutoksia pollaamalla säännöllisin väliajoin, mikä kuluttaa enemmän akkua mobiililaitteissa ja tuntuu käyttäjästä hitaalta, kun kollega jakaa uuden salasanan organisaation kokoelmaan. WebSocket-yhteys vaatii kuitenkin, että käänteisproxy osaa välittää Upgrade-otsikon oikein, mikä käsitellään seuraavassa vaiheessa.

Vaihe 5: Käänteisproxy ja TLS-sertifikaatti

Vaultwardenia ei koskaan tule julkaista suoraan ilman TLS:ää. Selainten WebAuthn-toteutus, joka on passkeyjen ja laitteistoavainten perusta, vaatii turvallisen kontekstin eli HTTPS-yhteyden toimiakseen. Caddy hoitaa Let’s Encrypt -sertifikaatin hakemisen ja uusimisen automaattisesti, eikä vaadi erillistä cron-tehtävää.

holvi.omadomain.fi {
    reverse_proxy vaultwarden:8080 {
        header_up X-Real-IP {remote_host}
    }

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "same-origin"
    }

    encode gzip
}

Tallenna tiedosto nimellä Caddyfile ja käynnistä koko pino: docker compose up -d. Ensimmäinen käynnistys kestää hetken, koska Caddy hakee sertifikaatin lennosta ennen kuin palvelu vastaa pyyntöihin.

Jos käytät Nginxiä Caddyn sijaan, muista lisätä vastaavat proxy_set_header Upgrade $http_upgrade; ja proxy_set_header Connection "upgrade"; -rivit, muuten WebSocket-yhteys katkeaa heti muodostumisen jälkeen ja asiakassovellus näyttää jatkuvaa “yhdistetään uudelleen” -ilmoitusta. Caddyn etu Nginxiin verrattuna tässä käyttötapauksessa on juuri se, ettei sertifikaattien uusimista, HTTP-uudelleenohjausta HTTPS:ään tai WebSocket-otsikoita tarvitse määritellä käsin, koska Caddy hoitaa ne oletuksena.

Vaihe 6: Ensimmäinen admin-tili ja rekisteröinnin sulkeminen

Avaa selaimessa https://holvi.omadomain.fi ja luo ensimmäinen tilisi. Tästä tulee automaattisesti holvin omistaja. Seuraavaksi generoi admin-token, joka suojaa erillistä /admin-hallintapaneelia.

openssl rand -base64 48

Liitä tuloste ADMIN_TOKEN-ympäristömuuttujaan compose-tiedostossa ja käynnistä pino uudelleen. Muista, ettei tätä tokenia koskaan kierrätetä muualla, sillä se avaa pääsyn koko käyttäjärekisteriin, kutsujen hallintaan ja diagnostiikkalokeihin.

Uusimmat Vaultwarden-versiot tukevat myös Argon2-hajautettua admin-tokenia pelkän raakatekstin sijaan. Aja token vaultwarden hash -aliaskomennon läpi ennen tallennusta, jolloin compose-tiedostossa säilytettävä arvo on hajautettu eikä suoraan käyttökelpoinen, vaikka joku pääsisi lukemaan tiedoston. Tämä on pieni lisävaiva, joka kannattaa tehdä heti, ei vasta myöhemmin “kun ehtii”.

Vaihe 7: Kaksivaiheinen tunnistautuminen pakolliseksi

Vaultwarden tukee useaa toisen tekijän muotoa: TOTP-sovelluksia, sähköpostikoodeja, WebAuthn/FIDO2-laitteistoavaimia, YubiKey OTP:tä ja Duota. NIST:n digitaalisen identiteetin ohjeiston mukaan laitteistoavaimet ja autentikaattorisovellukset ovat merkittävästi vahvempia kuin tekstiviestikoodit, koska niitä ei voi kaapata SIM-vaihtohuijauksella.

Pakota 2FA koko organisaatiolle admin-paneelin kautta: siirry kohtaan Organisaatiot, valitse tiimisi ja aktivoi “Vaadi kaksivaiheinen tunnistautuminen jäseniltä”. Jäsenet, jotka eivät ole ottaneet 2FA:ta käyttöön määräajassa, poistetaan automaattisesti organisaatiosta, joten ilmoita muutoksesta tiimille etukäteen.

Käytännössä kannattaa suositella WebAuthn/FIDO2-laitteistoavainta ensisijaiseksi menetelmäksi ja TOTP-sovellusta varamenetelmäksi. Sähköpostikoodi on teknisesti tuettu, mutta se nojaa sähköpostitilin omaan turvallisuuteen, joten jos sama henkilö käyttää heikkoa salasanaa sähköpostissaan, koko kaksivaiheinen suoja jää käytännössä hyödyttömäksi. Muista myös tallentaa jokaiselle käyttäjälle palautuskoodit turvalliseen, salasanaholvin ulkopuoliseen paikkaan ennen kuin pakotus astuu voimaan, muuten laitteen kadotessa tili voi jäädä pysyvästi lukkoon.

Organisaatioiden kokoelmat ja käyttöoikeuksien hienosäätö

2FA:n pakottamisen jälkeen kannattaa käyttää hetki aikaa kokoelmarakenteen suunnitteluun, ennen kuin tiimi alkaa täyttää holvia. Vaultwardenin organisaatiomalli perustuu kokoelmiin (collections), joihin jäsenille annetaan erikseen luku-, muokkaus- tai hallintaoikeus. Yleinen virhe on luoda yksi iso “Yritys”-kokoelma, johon kaikki laitetaan, jolloin jokainen työntekijä näkee kaikkien muidenkin tunnukset. Jaa sen sijaan kokoelmat tiimeittäin tai järjestelmittäin, esimerkiksi “Tuotanto-palvelimet”, “Markkinointi-SaaS” ja “Talous”, ja anna kullekin ryhmälle pääsy vain siihen, mitä he oikeasti tarvitsevat.

Vaultwarden tukee myös “read-only” ja “hide passwords” -oikeustasoja kokoelmakohtaisesti. Jälkimmäinen on hyödyllinen tilanteessa, jossa työntekijän pitää pystyä käynnistämään kirjautuminen suoraan selainlaajennuksesta, muttei koskaan nähdä salasanaa selväkielisenä, esimerkiksi ulkoistetulle tukihenkilölle annettavissa tunnuksissa. Käy oikeudet läpi uudelleen aina, kun joku vaihtaa tiimiä tai poistuu organisaatiosta, sillä unohdetut oikeudet ovat yksi yleisimmistä syistä siihen, että vanha työntekijä pääsee yhä käsiksi tunnuksiin irtisanomisen jälkeen.

Kirjaa kokoelmarakenne ylös erilliseen dokumenttiin holvin ulkopuolelle, esimerkiksi organisaation omaan wikiin. Kun uusi työntekijä liittyy tiimiin, tästä dokumentista näkee heti, mihin kokoelmiin hänet pitää lisätä, sen sijaan että joutuisi arvailemaan tai kysymään kollegoilta. Sama dokumentti toimii myös auditointijälkenä, jos joudut myöhemmin selvittämään, kenellä oli pääsy mihinkin tiettynä ajankohtana.

Kokoelmien lisäksi kannattaa hyödyntää ryhmiä (groups), jos organisaatiokoko kasvaa yli kymmenen hengen. Ryhmät antavat lisätä ja poistaa käyttäjiä kerralla useasta kokoelmasta yhdellä toimenpiteellä sen sijaan, että jokainen oikeus pitäisi myöntää yksitellen. Tämä vähentää inhimillisten virheiden määrää tilanteissa, joissa uusi työntekijä pitäisi saada tuottavaksi nopeasti mutta oikeuksien tarkkuudesta ei silti haluta tinkiä.

Vaihe 8: Fail2ban murtosuojaksi

Vaultwarden ei rajoita kirjautumisyrityksiä itsessään yhtä tiukasti kuin moni odottaa, joten fail2ban jää käytännössä ensimmäiseksi puolustuslinjaksi raa’an voiman hyökkäyksiä vastaan. Ohjaa Vaultwardenin lokit tiedostoon ja luo suodatin, joka tunnistaa epäonnistuneet kirjautumiset 401-vastauskoodeista.

[vaultwarden]
enabled = true
port = http,https
filter = vaultwarden
logpath = /var/log/vaultwarden/vaultwarden.log
maxretry = 5
findtime = 600
bantime = 600
action = iptables-multiport[name=vaultwarden, port="http,https"]

Viisi epäonnistunutta kirjautumista kymmenessä minuutissa laukaisee kymmenen minuutin eston kyseiselle IP-osoitteelle. Kiristä arvoja tarvittaessa, mutta muista, että liian tiukka maxretry voi lukita myös oikeat käyttäjät ulos, jos he näppäilevät salasanansa väärin muutaman kerran.

Toistuvasti estetyt IP-osoitteet kannattaa nostaa myös UFW:hen pysyvästi, jos näet saman lähteen palaavan uudelleen ja uudelleen fail2banin väliaikaisen eston jälkeen. Komento fail2ban-client status vaultwarden näyttää tämänhetkiset estot ja tilastot, joita kannattaa tarkistaa säännöllisesti ensimmäisten viikkojen aikana, jotta näet, kuinka paljon taustakohinaa palvelimeesi kohdistuu suoraan internetistä.

Vaihe 9: Tietoturvaotsikot ja trusted proxy -asetukset

Version 1.37.0 mukana tullut “trusted proxy” -tuki ratkaisee vanhan ongelman: ilman sitä Vaultwarden saattoi kirjata kaikki pyynnöt saapuvaksi käänteisproxyn sisäisestä IP-osoitteesta, mikä teki fail2ban-suodatuksesta ja lokianalyysistä hyödytöntä. Varmista, että IP_HEADER on asetettu ja että Caddy välittää oikean asiakkaan osoitteen X-Real-IP-otsikossa, kuten Vaihe 5:ssä määriteltiin.

Tarkista lopuksi vielä OWASP Top 10 -listan mukaiset perusasiat: onko admin-paneeli erotettu omaan aliverkkoon tai VPN:n taakse, palautuuko virheilmoituksissa liikaa teknistä tietoa, ja onko HSTS-otsikko todella pakottamassa selaimet HTTPS:ään myös ensimmäisellä käynnillä.

Docker-kontin resurssirajat ja ajaminen ei-root-käyttäjänä

Vaultwarden-kuva ajaa prosessin oletuksena ei-root-käyttäjänä kontin sisällä, mikä on hyvä lähtökohta, mutta koko kontin voi silti kaataa palvelunestohyökkäyksellä, jos resursseja ei rajata. Lisää compose-tiedostoon muistin ja prosessorin ylärajat, jotta yksittäinen hyökkäys tai bugi ei voi viedä koko VPS:n resursseja ja kaataa samalla myös muita samalla koneella pyöriviä palveluita.

  vaultwarden:
    image: vaultwarden/server:1.37.1
    deploy:
      resources:
        limits:
          cpus: "1.0"
          memory: 512M
        reservations:
          memory: 128M
    read_only: false
    security_opt:
      - no-new-privileges:true

no-new-privileges:true estää kontin sisällä ajettavia prosesseja hankkimasta lisää oikeuksia esimerkiksi setuid-binäärien kautta, vaikka konttiin onnistuttaisiin murtautumaan sovellustason haavoittuvuuden kautta. Yhdistettynä aiempien vaiheiden verkkoeristykseen tämä tarkoittaa, että yksittäinen kompromisoitu kontti ei automaattisesti tarjoa hyökkääjälle pääsyä isäntäkoneen muihin osiin.

Rajaa myös lokitiedostojen kokoa suoraan Dockerin tasolla, muuten kontin oma json-file-lokiajuri voi täyttää koko levyn ajan mittaan, jos jokin sovellus alkaa kirjoittaa lokia poikkeuksellisen tiheästi virhetilanteessa. Lisää compose-tiedostoon logging: driver: "json-file", options: {max-size: "10m", max-file: "3"}, jolloin yhden kontin lokit eivät koskaan kasva yli 30 megatavun kokonaisuudessaan. Tämä on pieni yksityiskohta, joka jää helposti huomiotta, mutta täysi levy kaataa koko VPS:n riippumatta siitä, kuinka hyvin muu koventaminen on tehty.

Vaihe 10: Lokien koventaminen ja yksityisyys

Elokuun alussa 2026 projektin GitHub-repositorioon lisättiin muutos, joka kirjaa käyttäjän sähköpostiosoitteen onnistuneiden kirjautumisten lokiin. Muutos helpottaa vianmääritystä, mutta se tarkoittaa myös, että lokitiedostoihin kertyy henkilötietoa, joka pitää huomioida GDPR-näkökulmasta. Aseta lokien säilytysaika lyhyeksi ja rajaa lukuoikeudet vain sille, joka todella tarvitsee niitä.

sudo tee /etc/logrotate.d/vaultwarden <<EOF
/var/log/vaultwarden/vaultwarden.log {
  daily
  rotate 14
  compress
  missingok
  notifempty
  create 0640 root adm
}
EOF

14 vuorokauden säilytys riittää useimmille fail2ban- ja diagnostiikkatarpeille ilman, että lokit paisuvat vuosien mittaiseksi henkilötietoarkistoksi.

Jos ylläpidät Vaultwardenia yrityskäytössä, kannattaa dokumentoida tämä lokikäytäntö osaksi omaa tietosuojaselostetta. GDPR ei kiellä kirjautumislokien pitämistä, mutta se edellyttää, että käsittelyllä on peruste ja että säilytysaika on rajattu tarpeeseen nähden. Sähköpostiosoitteiden ilmestyminen lokeihin elokuun 2026 päivityksen jälkeen on hyvä esimerkki siitä, miten pieni tekninen muutos avoimen lähdekoodin projektissa voi vaikuttaa suoraan organisaation tietosuojavelvoitteisiin ilman, että kukaan erikseen ilmoittaa siitä.

Vaihe 11: Varmuuskopiointi ja palautustestaus

PostgreSQL-siirron jälkeen varmuuskopiointi muuttuu huomattavasti luotettavammaksi kuin SQLite-tiedoston kopioiminen lennossa. Ajasta yöllinen pg_dump ja kopioi samalla /data-kansio, joka sisältää liitetiedostot ja RSA-avaimet.

#!/bin/bash
set -euo pipefail
STAMP=$(date +%Y%m%d)
BACKUP_DIR=/opt/vw-backups

docker compose exec -T db pg_dump -U vw_admin vaultwarden \
  | gzip > "$BACKUP_DIR/db_$STAMP.sql.gz"

tar -czf "$BACKUP_DIR/data_$STAMP.tar.gz" ./vw-data

find "$BACKUP_DIR" -name "*.gz" -mtime +30 -delete

Testaa palautus vähintään kerran kvartaalissa erilliseen testiympäristöön. Varmuuskopio, jota ei ole koskaan palautettu, on käytännössä toive, ei suunnitelma. Kirjaa palautustestin tulos ylös, mukaan lukien kulunut aika, jotta tiedät etukäteen, kuinka pitkä käyttökatko todellisessa hätätilanteessa olisi odotettavissa.

Harkitse varmuuskopioiden salaamista vielä erikseen ennen siirtoa etäsijaintiin, vaikka Vaultwardenin oma data on jo salattu asiakaspäässä. PostgreSQL-vedos sisältää käyttäjien sähköpostiosoitteet, organisaatiorakenteen ja metatietoja, jotka eivät ole samalla tavalla suojattuja kuin itse salasanamerkinnät. Työkalu kuten restic tai borgbackup hoitaa sekä salauksen että etäsiirron samalla komennolla, ja kumpikin tukee suoraan S3-yhteensopivia pohjoismaisia pilvivarastoja.

Vaihe 12: Bitwarden-asiakkaiden yhteensopivuus (2026.7.0+)

Heinä-elokuun tapaus opetti yhden asian ylitse muiden: Bitwardenin viralliset asiakassovellukset päivittyvät automaattisesti taustalla, mutta oma palvelin ei. Kun selainlaajennus, työpöytäsovellus ja mobiilisovellus päivittyivät versioon 2026.7.0 heinäkuun lopussa, ne alkoivat odottaa uutta protokollaversiota, jota vain Vaultwarden 1.37.0 ja uudemmat puhuvat. Vanhemmalla palvelimella käyttäjä näki vaihtelevasti tyhjän holvin tai jatkuvan latausanimaation.

Ennen kuin raportoit “kadonneita” salasanoja tai avaat tukipyynnön, tarkista aina ensin palvelimen versio komennolla docker compose exec vaultwarden vaultwarden --version ja vertaa sitä tuoreimpaan julkaisuun GitHubissa. Data ei tyypillisesti katoa tällaisissa tilanteissa, vaan asiakassovellus ei yksinkertaisesti pysty enää neuvottelemaan yhteyttä vanhentuneen palvelimen kanssa.

Pidä varasuunnitelma valmiina ennen jokaista päivitystä: ota tietokannasta ja /data-kansiosta tuore varmuuskopio juuri ennen komentoa docker compose pull && docker compose up -d, jotta pystyt palauttamaan edellisen version nopeasti, jos jokin menee pieleen. Käytännössä palautus tarkoittaa vain kuvatunnisteen vaihtamista compose-tiedostossa takaisin vanhaan versioon ja kontin uudelleenkäynnistystä, sillä tietokantaskeema pysyy yleensä yhteensopivana muutaman version ajan taaksepäin.

Migraatio muista salasananhallinnoista

Moni päätyy Vaultwardeniin vasta sen jälkeen, kun on käyttänyt vuosia jotain muuta ratkaisua. Siirtymä onnistuu useimmista suosituista työkaluista, koska Vaultwarden tukee samaa CSV- ja JSON-tuontimuotoa kuin virallinen Bitwarden-asiakassovellus. Vie ensin data vanhasta palvelusta sen omalla vientitoiminnolla (esimerkiksi KeePass-tietokannasta .csv-muodossa tai 1Passwordista .1pux-muodossa), kirjaudu sisään uuteen Vaultwarden-tiliisi ja valitse Työkalut → Tuo data.

Kolme asiaa kannattaa tarkistaa heti tuonnin jälkeen. Ensimmäinen on kaksoiskappaleiden määrä: jos olet aiemmin synkronoinut useita työkaluja keskenään, tuonti voi luoda saman tunnuksen moneen kertaan. Toinen on kansiorakenne, joka ei aina siirry sellaisenaan, vaan saattaa litistyä yhdeksi tasoksi. Kolmas ja tärkein on vanhan datan tuhoaminen turvallisesti: älä jätä alkuperäistä CSV-tiedostoa lojumaan Lataukset-kansioon salaamattomana, vaan poista se heti tuonnin onnistuttua tai säilytä se vain toisessa jo salatussa säiliössä.

Isommissa organisaatioissa siirtymä kannattaa ajaa vaiheittain tiimi kerrallaan sen sijaan, että koko henkilöstö vaihtaa työkalua samana päivänä. Ensimmäinen aalto paljastaa tyypilliset kysymykset ja kitkakohdat, joihin voi valmistautua ennen seuraavaa aaltoa. Varaa myös rinnakkaiskäytölle pari viikkoa: pidä vanha palvelu vielä lukutilassa saatavilla siltä varalta, että joku löytää unohtuneen tunnuksen vasta myöhemmin.

Esimerkkituloste: näin onnistunut käyttöönotto näyttää

Kun kaikki 12 vaihetta on ajettu läpi, docker compose ps näyttää molemmat palvelut tilassa “healthy”:

NAME          IMAGE                        STATUS
db            postgres:16-alpine          Up 2 hours (healthy)
vaultwarden   vaultwarden/server:1.37.1   Up 2 hours (healthy)
caddy         caddy:2.8-alpine            Up 2 hours

$ docker compose exec vaultwarden vaultwarden --version
vaultwarden 1.37.1

Selaimessa admin-paneeli (/admin) näyttää käyttäjämäärän, diagnostiikkasivun vihreät merkit tietokantayhteydelle, sähköpostilähetykselle (jos määritetty) ja WebSocket-yhteydelle. Jos jokin näistä on punainen, palaa vastaavaan vaiheeseen ennen kuin kutsut muita käyttäjiä.

fail2ban-status näyttää samaan aikaan nollaa estettyä osoitetta tuoreella asennuksella, mikä on odotettu ja hyvä merkki. Ensimmäiset estot ilmestyvät yleensä tuntien tai päivien sisällä, kun automatisoidut skannerit löytävät uuden julkisen IP-osoitteen ja alkavat kokeilla oletustunnuksia. Tämä on normaalia taustakohinaa koko julkisessa internetissä, ei merkki siitä, että juuri sinun palvelimesi olisi erityisesti kohteena.

Täysi esimerkkiprojekti: tiimin salasanaholvi 90 minuutissa

Kokoa lopuksi kaikki palaset yhteen. Kansiorakenne näyttää tältä valmiissa asennuksessa:

vaultwarden-stack/
├── docker-compose.yml
├── Caddyfile
├── secrets/db_password.txt
├── pgdata/
├── vw-data/
└── backup.sh

Tästä eteenpäin viikoittainen ylläpito rajoittuu kolmeen asiaan: tarkista GitHubin julkaisusivu uusien versioiden varalta, seuraa fail2ban-lokia epäilyttävän liikenteen varalta ja varmista, että yöllinen varmuuskopiointi on todella ajastettu cronilla. Kymmenen käyttäjän tiimille tämä koko pino pyörii mukavasti yhdellä 1 vCPU / 1 GB RAM -VPS:llä, ja kuukausikustannus jää tyypillisesti alle kymmenen euron pilvipalveluntarjoajasta riippuen.

Koko projektin voi pakata versionhallintaan yhtä kansiota lukuun ottamatta: secrets/-kansio ja vw-data/-kansio eivät koskaan kuulu Gitiin, koska ne sisältävät oikeaa dataa. Sen sijaan docker-compose.yml, Caddyfile ja backup.sh voi tallentaa yksityiseen repositorioon, jolloin koko asennus on toistettavissa uudelle palvelimelle muutamassa minuutissa, jos alkuperäinen VPS jostain syystä hajoaa. Tämä toistettavuus on itsessään osa koventamista: mitä nopeammin saat palvelun pystyyn uudelleen, sitä vähemmän aikaa jää haavoittuvalle väliaikaisratkaisulle.

Yleisimmät sudenkuopat

• Latest-tagin käyttö tuotannossa. Kun kuva päivittyy automaattisesti taustalla, et tiedä milloin protokolla muuttuu ja klientit alkavat oireilla. Kiinnitä aina täsmällinen versio.
• SIGNUPS_ALLOWED jää päälle. Moni unohtaa kääntää arvon takaisin falseksi ensimmäisen tilin luonnin jälkeen, jolloin holvi on avoin kenelle tahansa domainin löytäneelle.
• Admin-paneeli ilman erillistä suojausta. Pelkkä pitkä token ei riitä, jos paneeli on avoinna koko internetiin. Rajoita pääsy IP-osoitteen tai VPN:n perusteella.
• SQLite tuotannossa usean käyttäjän kanssa. Tietokantalukot aiheuttavat satunnaisia aikakatkaisuja, jotka näyttävät selaimessa hitaudelta tai kaatumiselta.
• Varmuuskopiot samalla levyllä kuin tuotantodata. Jos VPS:n levy hajoaa tai tili suljetaan, katoavat sekä data että varmuuskopio samalla kertaa. Kopioi varmuuskopiot aina toiseen sijaintiin.
• WebSocket-otsikot unohdetaan käänteisproxysta. Ilman Upgrade-otsikon välitystä sovellus toimii näennäisesti mutta ilman reaaliaikaisia päivityksiä, mikä näkyy käyttäjälle satunnaisina viiveinä jaetuissa kokoelmissa.
• Ympäristömuuttujat versionhallinnassa selväkielisenä. Jos docker-compose.yml päätyy julkiseen Git-repositorioon salasanoineen, koko holvi on vaarassa. Käytä .env-tiedostoa ja lisää se .gitignore-listaan heti ensimmäisenä.
• Kaikki jäsenet samassa yhdessä kokoelmassa. Tämä tekee kaikista tunnuksista näkyviä kaikille organisaation jäsenille riippumatta heidän todellisesta tarpeestaan, mikä kasvattaa vahingon laajuutta yhden tilin kompromissin sattuessa.

Yhteinen nimittäjä näissä sudenkuopissa on kiire: asennus saadaan toimimaan nopeasti oletusasetuksilla, ja koventaminen jää “myöhemmin tehtäväksi”, joka ei koskaan tule. Varaa koventamiselle oma aikaikkuna heti asennuksen jälkeen äläkä avaa palvelua tiimin käyttöön ennen kuin tämän oppaan 12 vaihetta on käyty läpi.

Vianmääritys: 8 yleisintä ongelmaa

Suurin osa Vaultwarden-asennuksen ongelmista jakautuu kolmeen ryhmään: versioyhteensopivuus, verkkokonfiguraatio ja tietokantalukot. Ennen kuin avaat tukipyynnön projektin GitHub-sivulle, käy läpi seuraava taulukko, sillä valtaosa oireista selittyy jollain näistä kahdeksasta syystä.

Oire	Todennäköinen syy	Korjaus
Holvi näyttää tyhjältä kirjautumisen jälkeen	Palvelin vanhempi kuin 1.37.0, klientti 2026.7.0+	Päivitä palvelin versioon 1.37.1
“Bad Gateway” selaimessa	Caddy ei löydä vaultwarden-konttia	Tarkista, että molemmat ovat samassa Docker-verkossa
WebSocket-yhteys ei muodostu	Käänteisproxy ei välitä Upgrade-otsikkoa	Lisää websocket-tuki Caddyfileen
Sähköposti-ilmoitukset eivät lähde	SMTP-muuttujia ei asetettu	Lisää SMTP_HOST, SMTP_PORT ja tunnukset
fail2ban ei estä mitään	logpath osoittaa väärään tiedostoon	Tarkista Docker-lokien ohjaus levylle
“database is locked” -virheitä	SQLite käytössä usean käyttäjän kanssa	Siirry PostgreSQL 16 -kantaan
Admin-paneeliin ei pääse	ADMIN_TOKEN puuttuu tai väärä	Generoi uusi token ja käynnistä pino uudelleen
TLS-sertifikaatti ei uusiudu	Portti 80 ei ole auki HTTP-01-haasteelle	Avaa UFW:stä portti 80 pysyvästi

Jos oma ongelmasi ei löydy taulukosta, tarkista ensin docker compose logs vaultwarden --tail 100. Vaultwarden kirjoittaa selkeät virheviestit suoraan konsoliin, ja suurin osa jää huomaamatta vain siksi, ettei kukaan katso lokia ennen kuin käyttäjät alkavat valittaa. Toiseksi kannattaa aina varmistaa kellon synkronointi (timedatectl status) sekä isäntäkoneella että käyttäjän omalla laitteella, sillä TOTP-koodit ja TLS-sertifikaattien voimassaolo nojaavat molemmat tarkkaan kellonaikaan.

Edistyneet vinkit tehokäyttäjille

Kun perusasennus on vakaa, seuraava askel on seuranta. Vaultwardenin admin-diagnostiikkasivu tarjoaa perustiedot, mutta et halua kirjautua sinne käsin joka päivä. Ohjaa docker compose logs -tuloste keskitettyyn lokijärjestelmään tai yksinkertaiseen Prometheus-exportteriin, joka hälyttää epätavallisesta kirjautumismäärästä.

Yksinkertaisin tapa aloittaa on ajastettu terveystarkistus, joka lähettää hälytyksen, jos palvelu vastaa väärällä statuskoodilla tai ei vastaa lainkaan. Alla oleva skripti ajaa tarkistuksen minuutin välein cronista ja kirjoittaa poikkeamat omaan lokitiedostoonsa, josta ne on helppo yhdistää esimerkiksi sähköposti- tai Slack-hälytykseen.

#!/bin/bash
URL="https://holvi.omadomain.fi/alive"
CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 5 "$URL")

if [ "$CODE" != "200" ]; then
  echo "$(date -Iseconds) Vaultwarden vastasi koodilla $CODE" \
    >> /var/log/vaultwarden/healthcheck.log
fi

Lisää skripti crontabiin komennolla crontab -e ja rivillä * * * * * /opt/vw-backups/healthcheck.sh. Kun tähän yhdistää vielä levytilan ja muistinkäytön seurannan, esimerkiksi node_exporter-työkalulla, saat kattavan kuvan palvelimen kunnosta ilman raskasta valvontapinoa.

Isommassa ympäristössä kannattaa lisäksi seurata levytilan kulumista PostgreSQL-datakansiossa erikseen, sillä tietokanta kasvaa hitaasti mutta tasaisesti käyttöhistorian, kirjautumislokien ja tiedostoliitteiden myötä. Aseta hälytysraja esimerkiksi 80 prosenttiin levytilasta, jotta ehdit reagoida ennen kuin PostgreSQL lakkaa hyväksymästä uusia kirjoituksia kokonaan täyden levyn vuoksi.

Harkitse myös hätäkäyttöoikeuden (emergency access) käyttöönottoa perheenjäsenelle tai kollegalle organisaatioissa. Se antaa luotetulle henkilölle mahdollisuuden pyytää pääsyä holviin ennalta määritellyn odotusajan jälkeen, mikä on huomattavasti turvallisempi ratkaisu kuin pääsalasanan kirjoittaminen paperille kassakaappiin. Organisaation admin-lokit kannattaa lisäksi tarkistaa kuukausittain: ne kertovat, kuka on kutsunut jäseniä, muuttanut kokoelmien oikeuksia tai ladannut vientitiedostoja.

Kun tiimi kasvaa yli parinkymmenen käyttäjän, kannattaa harkita erillistä lukuoikeuksilla toimivaa PostgreSQL-replikaa raportointia varten, jotta itse tuotantokanta ei kuormitu kuukausittaisista käyttöoikeusauditoinneista. Voit myös automatisoida haavoittuvuusseurannan lisäämällä GitHubin “Watch → Custom → Releases” -asetuksen projektin repositorioon, jolloin uusi julkaisu tipahtaa sähköpostiin heti eikä vasta viikkoja myöhemmin jonkin uutiskirjeen kautta.

Vaultwarden vs pilvi-Bitwarden vs 1Password

Itseisännöinti ei sovi kaikille. Seuraava taulukko auttaa arvioimaan, onko Vaultwarden oikea valinta juuri sinun tarpeisiisi vai kannattaako pysyä pilvipalvelussa.

Ominaisuus	Vaultwarden (itseisännöity)	Bitwarden Cloud	1Password
Datan sijainti	Oma valinta	Bitwardenin konesalit	1Passwordin konesalit
Ylläpitovastuu	Käyttäjällä itsellään	Bitwardenilla	1Passwordilla
Kuukausikustannus tiimille	VPS-hinta, usein alle 10€	Maksullinen taso alkaen muutamasta eurosta/käyttäjä	Maksullinen, kalliimpi taso
Lähdekoodi	Avoin	Osittain avoin	Suljettu
Vaatii teknistä osaamista	Kyllä, Docker ja Linux	Ei	Ei
Automaattiset päivitykset	Ei, manuaalinen seuranta	Kyllä	Kyllä

Jos et halua vastata puhelimeen kello kolme yöllä palvelinongelman takia, pilvipalvelu on todennäköisesti parempi valinta. Jos taas datan sijainti ja täysi hallinta ovat sinulle tärkeämpiä kuin muutaman minuutin ylläpitorupeama viikossa, Vaultwarden kannattaa. Voit lukea lisää vaihtoehdoista artikkelistamme Bitwarden vs LastPass vs KeePass.

Moni tiimi päätyy myös hybridimalliin: henkilökohtaiset salasanat pysyvät työntekijän omassa pilvitilissä, mutta jaetut yritystunnukset, palvelinsalasanat ja API-avaimet siirretään itseisännöityyn Vaultwardeniin, jota IT-tiimi valvoo tarkasti. Tämä rajaa itseisännöinnin vastuun sinne, missä siitä saa eniten hyötyä, eikä vaadi jokaiselta työntekijältä Docker-osaamista.

Yhteenveto: mitä koventaminen käytännössä tarkoittaa

Kaksitoista vaihetta kuulostaa paljolta, mutta ne jakautuvat neljään loogiseen kokonaisuuteen. Ensin rakennetaan perusta: palomuuri, Docker ja PostgreSQL. Sen jälkeen palvelu avataan turvallisesti internetiin TLS:n ja käänteisproxyn kautta. Kolmanneksi lukitaan pääsy: rekisteröinnin sulkeminen, pakollinen 2FA ja fail2ban. Lopuksi varmistetaan, että palvelu pysyy toimintakuntoisena myös kuukausien päästä: lokien hallinta, varmuuskopiointi ja version seuranta.

Heinä-elokuun 2026 Bitwarden-yhteensopivuustapaus on hyvä muistutus siitä, että viimeinen kokonaisuus on yhtä tärkeä kuin ensimmäinen. Palvelin, joka on koventunut asennushetkellä mutta unohdettu sen jälkeen, ajautuu ennemmin tai myöhemmin tilanteeseen, jossa asiakassovellus ja palvelin eivät enää puhu samaa kieltä. Merkitse kalenteriin muistutus tarkistaa Vaultwardenin versio kerran kuukaudessa, niin vältät sekä tietoturvariskit että yllättävät “tyhjä holvi” -puhelut kollegoilta.

Lopputulos on palvelin, joka tekee samaa työtä kuin kaupallinen pilvipalvelu mutta pysyy täysin oman organisaation hallinnassa. Se ei ole täysin huoltovapaa ratkaisu, mutta viikoittainen ylläpitorupeama on lyhyempi kuin useimmat kuvittelevat etukäteen, kunhan perusta on rakennettu tämän oppaan mukaisesti kunnolla kertaalleen.

Usein kysytyt kysymykset

Voinko siirtää holvini pilvi-Bitwardenista suoraan Vaultwardeniin?

Kyllä. Vie holvi Bitwarden Cloudista JSON-muodossa ja tuo se uuteen Vaultwarden-tiliin asiakassovelluksen tuontitoiminnolla. Salasanat pysyvät salattuna koko siirron ajan, jos käytät salattua vientimuotoa.

Onko SQLite todella niin huono valinta?

Yhden käyttäjän testiympäristössä SQLite toimii hyvin. Ongelmat alkavat, kun useampi käyttäjä kirjautuu samanaikaisesti tai kun haluat ottaa varmuuskopion tietokannasta ilman palvelun pysäyttämistä.

Mitä teen, jos unohdan admin-tokenin?

Generoi uusi token komennolla openssl rand -base64 48, päivitä se compose-tiedostoon ja käynnistä pino uudelleen komennolla docker compose up -d. Vanha token lakkaa toimimasta välittömästi.

Tarvitsenko PostgreSQL:n heti alusta asti?

Et välttämättä, jos käyttäjiä on vain yksi tai kaksi. Suosittelemme silti aloittamaan PostgreSQL:llä suoraan, koska myöhempi tietokannan vaihto vaatii erillisen migraatioajon eikä ole yhtä yksinkertaista kuin oikean kannan valinta alusta lähtien.

Miten tiedän, milloin Vaultwarden pitää päivittää?

Tilaa ilmoitukset projektin GitHub-repositorion julkaisuista tai lisää yksinkertainen viikoittainen cron-tehtävä, joka vertaa asennettua versiota uusimpaan tagiin GitHubin rajapinnasta.

Riittääkö fail2ban yksinään suojaamaan palvelinta?

Ei yksinään. Fail2ban hidastaa raa’an voiman hyökkäyksiä, mutta se ei korvaa vahvoja pääsalasanoja, pakollista 2FA:ta tai säännöllisiä ohjelmistopäivityksiä. Kohtele sitä yhtenä kerroksena useamman joukossa.

Voiko Vaultwardenia ajaa ilman Dockeria?

Kyllä, projekti voidaan kääntää suoraan Rust-lähdekoodista, mutta ylläpitäjät suosittelevat Docker-kuvia, koska ne sisältävät valmiiksi oikeat riippuvuudet ja OpenSSL-versiot testattuina.

Mitä eroa on SIGNUPS_ALLOWED- ja INVITATIONS_ALLOWED-asetuksilla?

SIGNUPS_ALLOWED päättää, voiko kuka tahansa domainin löytävä luoda itselleen tilin suoraan kirjautumissivulta. INVITATIONS_ALLOWED puolestaan sallii vain sen, että olemassa oleva käyttäjä tai admin voi kutsua uuden jäsenen sähköpostilla. Tuotantoasennuksessa ensimmäinen kannattaa pitää aina pois päältä ja nojata jälkimmäiseen.

Vaikuttaako koventaminen Vaultwardenin suorituskykyyn?

Vaikutus on käytännössä huomaamaton. TLS-purku, tietoturvaotsikot ja fail2ban-suodatus kuluttavat murto-osan yhden ytimen VPS:n tehosta, ja PostgreSQL on SQLiteä nopeampi rinnakkaisessa käytössä. Ainoa mitattava lisäviive tulee TLS-kättelystä, joka on tyypillisesti muutamia millisekunteja eikä näy käytännössä lainkaan.

Kuinka usein Vaultwarden-palvelin pitää päivittää käytännössä?

Tarkkaa aikataulua ei ole, koska julkaisutahti riippuu löytyneistä ongelmista. Vuoden 2026 aikana isompia julkaisuja on tullut karkeasti kuukausittain, ja tietoturvakorjauksia sisältäviä versioita kannattaa asentaa mahdollisimman pian, tyypillisesti viikon sisällä. Pienemmät ylläpitojulkaisut, jotka eivät koske tietoturvaa, voi ajaa seuraavan säännöllisen huoltoikkunan yhteydessä.

Related Coverage

• Bitwarden: 94% Salasanoista Kierrätetty, 13 Vaihetta
• Bitwarden vs LastPass vs KeePass: €18 vs €33 vs 0€
• WireGuard VPN Linuxille: oma palvelin 12 vaiheessa
• Firefoxin yksityisyysasetukset: 14 vaihetta, 30 min
• Signal-sovellus käyttöön: 12 Vaihetta, 40 Min
• Lisää yksityisyysaiheisia artikkeleita