Passbolt-asennus Dockerilla: 12 Vaihetta, 90 Min [2026]

Passbolt ilmoitti 22. heinäkuuta 2026 saaneensa päätökseen riippumattoman GDPR-vaatimustenmukaisuusauditoinnin ja nimittäneensä ranskalaisen Examin SAS -yhtiön riippumattomaksi tietosuojavastaavakseen (DPO). Avoimen lähdekoodin salasanhallinta on käytössä kymmenissä tuhansissa organisaatioissa, mutta harva suomalainen tiimi on vielä ottanut sen käyttöön Bitwardenin, LastPassin tai KeePassin rinnalle. Syynä on usein se, ettei kukaan ole kirjoittanut selkeää, suomenkielistä asennuspolkua Dockerilla. Tämä opas paikkaa aukon: käymme läpi koko asennuksen nollasta toimivaan tiimiympäristöön, 12 vaiheessa noin 90 minuutissa.

Kohderyhmänä ovat pienet ja keskisuuret IT-tiimit, jotka tarvitsevat jaettua salasanhallintaa mutta eivät halua luovuttaa salausavaimia kolmannelle osapuolelle. Passbolt-asennus sopii erityisen hyvin organisaatioille, joissa on jo Docker-osaamista ja oma palvelinkapasiteetti, mutta ei halua maksaa kuukausittaista pilvilisenssiä jokaisesta käyttäjätunnuksesta. Käymme läpi palvelimen esivalmistelun, Docker Compose -kokoonpanon, TLS-sertifikaatin, ylläpitäjätilin luonnin, GPG-avainten toiminnan sekä käyttäjien ja ryhmien hallinnan. Lisäksi käsittelemme GDPR-näkökulman käytännössä, sillä juuri se nosti Passboltin otsikoihin syksyllä 2026. Lopussa on 5 yleisintä asennusvirhettä, 8 vianmääritystapausta taulukkomuodossa ja muutama edistyneempi vinkki tuotantokäyttöön, kuten LDAP-synkronointi ja API-automaatio.

Koko opas nojaa Passboltin viralliseen Docker-dokumentaatioon ja yhtiön julkaisemiin tietoturvatiedotteisiin. Jokainen komento on testattu tuoreella Ubuntu-palvelimella, ja jokaisen vaiheen kohdalla kerrotaan myös, mitä tehdä, jos jokin menee pieleen. Jos olet aiemmin asentanut Vaultwardenin tai Matrix Synapsen Dockerilla, moni vaihe tuntuu tutulta, mutta Passboltin GPG-pohjainen salausmalli tuo mukanaan omat erityispiirteensä, joita ei kannata ohittaa. Laajempi katsaus muihin yksityisyyttä ja tietosuojaa käsitteleviin oppaisiimme löytyy Yksityisyys-kategoriasta.

Miksi Passbolt nousi otsikoihin syksyllä 2026

Passboltin heinäkuisessa blogikirjoituksessa kerrotaan, että Examin SAS kävi läpi yhtiön tietosuojakäytännöt, tietojen säilytyssäännöt, henkilötietojen käsittelysopimukset, hallintoprosessit ja tekniset suojatoimet. Läpikäynnin lopputulemana Passbolt sai suosituksia muun muassa tietojen säilytyskäytännön laajentamisesta useampiin liiketoimintatietojen luokkiin sekä henkilöstön tietosuojaohjeistuksen päivittämisestä. Yhtiö kuvaa auditointia osana laajempaa tietosuojan hallinnan ja vastuullisuuden vahvistamista, ei kertaluonteisena PR-tempauksena.

Ajoitus ei ole sattumaa. Suomessa tietosuojavaltuutetun toimisto käsitteli ennätysmäärän tapauksia viime vuonna, ja valvonta on kiristynyt myös Pohjoismaissa laajemmin. Samaan aikaan julkishallinnon toimijat ovat joutuneet GDPR-sakkojen piiriin aiempaa herkemmin. Kun salasanhallinta on osa organisaation tietoturva-arkkitehtuuria, sen toimittajan oma vaatimustenmukaisuus alkaa kiinnostaa tietosuojavastaavia yhtä paljon kuin käyttäjäkokemus. Passboltin ratkaisu perustuu OpenPGP-salaukseen, jossa salauksen purku tapahtuu aina paikallisesti käyttäjän laitteella, joten palvelinta ylläpitävä taho ei näe salasanoja selväkielisenä missään vaiheessa. Koodi on avointa, joten kuka tahansa voi tarkastaa sen itse.

Passbolt julkaisi myös 26. elokuuta 2026 tietoturvatiedotteen, jossa suositellaan päivittämään versioon 5.15 tai uudempaan. Tiedotteessa mainitaan kaksi haavoittuvuutta, joille oli hakemuksen jättöhetkellä pyydetty CVE-tunnisteet elokuun alussa ja lopussa 2026. Tämä on hyvä muistutus siitä, että itse isännöity ohjelmisto vaatii jatkuvaa päivitystä, ei vain kertaluonteista asennusta. Aiemmin, vuonna 2025, Passboltin omassa vikailmoituksessa dokumentoitiin myös CVE-2025-27913, host header -injektiohaavoittuvuus, joka koski Passbolt API:n versioita 4.11.1 asti ja korjattiin ominaisuuslipun kautta versiossa 4.11.1 sekä pysyvästi versiossa 5. Tämä tarkoittaa käytännössä, että jos asennat tuoreen version tämän oppaan ohjeilla, olet jo suojattu kyseiseltä haavoittuvuudelta, mutta vanhoja asennuksia päivittämättä jättäneet eivät ole.

Miksi tämä kiinnostaa juuri nyt suomalaisia ja pohjoismaisia IT-päättäjiä? Salasanhallinta on yksi harvoista työkaluista, joka näkee käytännössä jokaisen muun järjestelmän tunnukset. Jos toimittaja itse ei pysty osoittamaan omaa tietosuojansa tasoa, koko ketju on heikko lenkki. Passboltin tapauksessa auditoinnin ja avoimen lähdekoodin yhdistelmä antaa organisaatiolle mahdollisuuden sekä lukea auditointiraportin tiivistelmän että tarkastaa itse koodin, mikä ei onnistu suljetun lähdekoodin kilpailijoiden kanssa.

Pohjoismaissa tilanne on erityisen ajankohtainen, koska tietosuojaviranomaisten yhteistyö ja valvontakäytäntöjen yhdenmukaistuminen on kiihtynyt. Kun valvonta tiukkenee sekä Suomessa että laajemmin alueella, IT-päättäjät joutuvat perustelemaan yhä useamman työkalun valinnan myös tietosuojanäkökulmasta, ei vain hinnan tai käytettävyyden perusteella. Itse isännöity, auditoitu ja avoimen lähdekoodin salasanhallinta on tässä yhtälössä helpompi perustella hallitukselle tai tietosuojavastaavalle kuin suljetun lähdekoodin pilvipalvelu, jonka sisäisiä käytäntöjä ei voi itse tarkastaa.

Mikä Passbolt on ja kenelle se sopii

Passbolt on avoimen lähdekoodin salasanhallinta, joka on suunniteltu erityisesti tiimeille ja organisaatioille, ei yksittäiselle käyttäjälle. Community Edition (CE) on ilmainen ja itse isännöitävä, kun taas Pro- ja Enterprise-versiot lisäävät ominaisuuksia kuten hakemistosynkronoinnin ja laajemman käyttöoikeuksien hallinnan. Ydinarkkitehtuuri nojaa OpenPGP-standardiin: jokaisella käyttäjällä on oma avainpari, ja jaetut salasanat salataan vastaanottajan julkisella avaimella. Palvelin tallentaa vain salattua dataa eikä koskaan pura sitä.

Tämä eroaa monesta kuluttajasuuntautuneesta työkalusta. KeePassXC on erinomainen henkilökohtaiseen käyttöön, mutta jaettu tiimikäyttö vaatii manuaalista tiedostonjakoa. Vaultwarden tarjoaa samankaltaisen itse isännöidyn mallin Bitwarden-yhteensopivalla rajapinnalla, mutta salausmalli ja jakamislogiikka poikkeavat Passboltista. Passbolt sopii parhaiten tiimille, joka tarvitsee roolipohjaista pääsynhallintaa, jaettuja kansioita ja tarkastettavaa lokia siitä, kuka pääsi käsiksi mihinkin salaisuuteen, milloin.

Passboltin perusajatus on yksinkertainen: salasanhallinnan pitäisi olla yhtä helppoa jakaa turvallisesti tiimin kesken kuin se on nykyään jakaa turvattomasti sähköpostitse tai pikaviestimissä. Avoin lähdekoodi ja OpenPGP-standardi mahdollistavat sen, että kuka tahansa voi tarkastaa, pitääkö tämä lupaus paikkansa myös koodin tasolla, eikä vain markkinointimateriaalissa.

Community Edition vs. Pro: mistä erot tulevat

Community Edition kattaa perustoiminnot: salasanojen ja muistiinpanojen tallennuksen, jakamisen käyttäjille ja ryhmille, kansiorakenteen sekä käyttöoikeustasot. Pro- ja Enterprise-lisenssit lisäävät ominaisuuksia, jotka kiinnostavat erityisesti suurempia organisaatioita: hakemistosynkronoinnin LDAP:iin tai Azure AD:hen, kertakirjautumisen (SSO), laajemman raportoinnin ja virallisen tuen. Tämä opas keskittyy kokonaan CE-versioon, koska se riittää valtaosalle pienistä ja keskisuurista tiimeistä eikä vaadi lisenssimaksuja.

Käytännön esimerkki havainnollistaa eroa: 15 hengen kehitystiimi, joka jakaa palvelintunnuksia ja API-avaimia sisäisesti, pärjää CE-versiolla mainiosti. Sen sijaan 400 hengen konserni, jossa käyttäjätilit halutaan poistaa automaattisesti Azure AD:sta heti työsuhteen päättyessä, tarvitsee todennäköisesti Pro-version hakemistosynkronoinnin.

Kannattaako Passboltin itse isännöinti taloudellisesti?

Itse isännöinnin taloudellinen houkutus on ilmeinen: Community Edition ei vaadi kuukausittaista per-käyttäjä-maksua, joten kasvava tiimi ei näy suoraan laskulla samalla tavalla kuin pilvipohjaisissa vaihtoehdoissa. Tämä ei kuitenkaan tarkoita, että kustannus olisi nolla. Palvelinkapasiteetti, ylläpitäjän työaika, varmuuskopioinnin valvonta ja päivitysten seuraaminen ovat kaikki todellisia kuluja, jotka eivät näy laskulla mutta näkyvät työajassa.

Käytännön nyrkkisääntönä: jos organisaatiossasi on jo Docker-osaamista ja palvelinkapasiteettia muita palveluita varten, kuten oman Matrix-palvelimen ylläpitoon, Passboltin lisääminen samaan infrastruktuuriin on rajakustannukseltaan pieni. Jos taas joudut rakentamaan koko Docker-osaamisen ja palvelinympäristön tätä yhtä työkalua varten, kannattaa laskea mukaan myös opetteluun ja ylläpitoon kuluva aika, ei vain palvelinlaskua. Monelle pienelle tiimille pilvipohjainen vaihtoehto on käytännössä halvempi, kun ylläpitäjän aika hinnoitellaan mukaan, mutta organisaatioille, joilla on jo tarvittava osaaminen talossa, itse isännöinti maksaa itsensä takaisin nopeasti sekä suorina kustannussäästöinä että siinä, että salausavaimet eivät koskaan poistu organisaation omasta hallinnasta.

Palvelimen sijainnilla on myös merkitystä tietosuojan kannalta, vaikka Passboltin OpenPGP-malli jo itsessään vähentää sijainnin merkitystä salaamalla sisällön aina päätelaitteella. Moni suomalainen organisaatio valitsee silti tarkoituksella kotimaisen tai EU-alueella toimivan palveluntarjoajan, kuten UpCloudin tai Hetznerin, jotta myös metadata, kuten kirjautumislokit ja IP-osoitteet, pysyy selkeästi EU:n lainkäyttöalueella. Tämä ei ole Passboltin tekninen vaatimus vaan organisaation oma päätös, joka kannattaa kirjata osaksi tietosuojaselostetta.

Esivaatimukset ennen asennusta

Passboltin virallinen Docker-dokumentaatio ei julkaise tarkkoja RAM- tai CPU-minimejä, mutta pino sisältää PHP-sovelluksen, MariaDB/MySQL-tietokannan sekä GPG-avainten generoinnin, joten pieni tuotantopalvelin riittää muutaman kymmenen käyttäjän tiimille. Käytännössä kannattaa varata palvelimelle riittävästi levytilaa varmuuskopioille ja lokitiedostoille, sillä jokainen jaettu resurssi ja käyttöoikeusmuutos kirjautuu tietokantaan. Alla oleva taulukko kokoaa viralliset ja käytännössä toimivaksi todetut vaatimukset ennen kuin avaat ensimmäisenkään terminaali-ikkunan.

Komponentti	Vaatimus	Huomio
Docker Engine	Uusin vakaa versio	Käyttäjän tulee pystyä ajamaan docker-komentoja ilman sudoa
Docker Compose	Compose v2 -liitännäinen	Sisältyy nykyisiin Docker-asennuksiin
Tietokanta	MariaDB tai MySQL ≥ 5.0	Passbolt suosittelee ajamaan tietokannan omassa kontissaan
SMTP-palvelin	Toimiva ulosmenevä sähköposti	Ilman tätä käyttäjäkutsut ja salasanan palautus eivät toimi
NTP-aikapalvelu	Synkronoitu kellonaika	Vääristynyt kello aiheuttaa GPG-todennusvirheitä
Entropia	rng-tools tai haveged isäntäkoneella	Nopeuttaa GPG-avainparin generointia kontin sisällä
Verkkotunnus + TLS	DNS osoittaa palvelimelle, HTTPS pakollinen	Selainlaajennus ei toimi luotettavasti ilman kelvollista sertifikaattia

Varaa lisäksi noin 90 minuuttia aikaa, jos teet asennuksen ensimmäistä kertaa ja haluat myös testata varmuuskopioinnin. Kokenut ylläpitäjä selviää nopeamminkin, mutta GPG-avainten entropian odottelu ja sertifikaatin varmistus vievät oman aikansa. Jos asennat testiympäristöön ilman julkista verkkotunnusta, laske aikaa hieman lisää, koska itse allekirjoitetun varmenteen tuonti jokaiselle työasemalle manuaalisesti on hitaampaa kuin Let’s Encryptin automaattinen uusinta.

Yhtä tärkeää kuin tekninen ympäristö on se, että joku organisaatiossasi omistaa vastuun ylläpidosta jatkossa. Passbolt ei ole kertaluonteinen asennus vaan palvelu, joka vaatii säännöllisiä päivityksiä, varmuuskopioiden testaamista ja käyttäjähallinnan siivoamista, kun työntekijöitä tulee ja lähtee. Nimeä siis vastuuhenkilö jo ennen kuin aloitat ensimmäistä vaihetta.

Käyttöjärjestelmän valinnalla ei ole suurta merkitystä, koska koko sovellus pyörii Docker-konteissa, mutta isäntäkoneen tulisi olla ajan tasalla oleva, tuettu Linux-jakelu. Tässä oppaassa komennot on kirjoitettu Ubuntu- ja Debian-pohjaisille järjestelmille apt-pakettienhallinnalla, mutta samat Docker-kontit toimivat identtisesti myös RHEL-pohjaisilla jakeluilla, kunhan Docker Engine asennetaan jakelun omilla ohjeilla.

Vaihe 1–2: Palvelimen ja Dockerin valmistelu

Asennuksen tekninen osuus alkaa tästä. Käymme läpi palvelimen valmistelun, Dockerin asennuksen, kokoonpanotiedostot, TLS-sertifikaatin, käynnistyksen ja ylläpitäjätilin luonnin siinä järjestyksessä, jossa ne oikeasti kannattaa tehdä. Jokaisen komentorivin jälkeen on selitys siitä, mitä komento tekee ja mihin virheeseen se voi törmätä.

Vaihe 1. Päivitä palvelin ja luo erillinen käyttäjätunnus, joka kuuluu docker-ryhmään. Älä aja Passboltia root-käyttäjänä, sillä root-oikeuksin ajettu kontti laajentaa mahdollisen tietoturvapoikkeaman vaikutusalaa tarpeettomasti koko isäntäkoneelle.

sudo apt update && sudo apt upgrade -y
sudo adduser passbolt-admin
sudo usermod -aG sudo passbolt-admin
sudo apt install -y ca-certificates curl gnupg rng-tools ntp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Viimeiset kolme riviä avaavat palomuurista portit 80 ja 443, joita Let’s Encrypt ja HTTPS-liikenne tarvitsevat. Jos palvelimesi on jo suojattu jonkin muun palomuuriratkaisun tai pilvipalveluntarjoajan tietoturvaryhmän takana, tee vastaavat säännöt siellä eikä pelkästään käyttöjärjestelmän omalla palomuurilla.

Vaihe 2. Asenna Docker Engine ja Compose-liitännäinen virallisesta pakettivarastosta.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
echo "deb [signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo usermod -aG docker $USER
newgrp docker
docker compose version

Odotettu tuloste viimeiseltä riviltä on suunnilleen Docker Compose version v2.x.x. Jos komento epäonnistuu käyttöoikeusvirheeseen (permission denied while trying to connect to the Docker daemon socket), kirjaudu ulos ja takaisin sisään, jotta docker-ryhmän jäsenyys astuu voimaan. Docker Enginen viralliset asennusohjeet eri Linux-jakeluille löytyvät Dockerin omasta dokumentaatiosta, jos komennot poikkeavat käyttämästäsi jakelusta.

Vaihe 3–4: docker-compose.yml ja ympäristömuuttujat

Vaihe 3. Luo projektikansio ja kirjoita docker-compose.yml, joka käynnistää virallisen passbolt/passbolt-kuvan sekä MariaDB-tietokannan. Tämä on koko tutoriaalin ydintiedosto: samalla pohjalla saat toimivan, valmiin projektin tuotantokäyttöön. Rakenne noudattaa Passboltin virallista passbolt_docker-repositoriota GitHubissa, josta löytyy myös vaihtoehtoisia kokoonpanoja, jos haluat esimerkiksi erottaa tietokannan omalle palvelimelleen.

mkdir -p ~/passbolt && cd ~/passbolt
nano docker-compose.yml

services:
  db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MYSQL_RANDOM_ROOT_PASSWORD: "true"
      MYSQL_DATABASE: passbolt
      MYSQL_USER: passbolt
      MYSQL_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    volumes:
      - db_data:/var/lib/mysql

  passbolt:
    image: passbolt/passbolt:latest-ce
    restart: unless-stopped
    depends_on:
      - db
    environment:
      APP_FULL_BASE_URL: https://passbolt.esimerkkiyritys.fi
      DATASOURCES_DEFAULT_HOST: db
      DATASOURCES_DEFAULT_USERNAME: passbolt
      DATASOURCES_DEFAULT_PASSWORD_FILE: /run/secrets/db_password
      DATASOURCES_DEFAULT_DATABASE: passbolt
    secrets:
      - db_password
    ports:
      - "443:443"
    volumes:
      - gpg_data:/etc/passbolt/gpg
      - jwt_data:/etc/passbolt/jwt

secrets:
  db_password:
    file: ./db_password.txt

volumes:
  db_data:
  gpg_data:
  jwt_data:

Vaihe 4. Luo salasanatiedosto Docker Secretsille äläkä koskaan kirjoita salasanaa suoraan docker-compose.yml-tiedostoon. Vaihda APP_FULL_BASE_URL omaan verkkotunnukseesi jo tässä vaiheessa, sillä väärä osoite aiheuttaa myöhemmin selainlaajennuksen yhteysvirheitä. Docker Secrets on tässä parempi valinta kuin tavallinen .env-tiedosto, koska salasana ei tällöin näy prosessilistauksessa eikä vahingossa päädy versionhallintaan.

openssl rand -base64 24 > db_password.txt
chmod 600 db_password.txt

Tiedostorakenteen yleiskatsaus

Tässä vaiheessa projektikansiossasi pitäisi olla kolme tiedostoa: docker-compose.yml, db_password.txt sekä myöhemmin luotava .gitignore, jos aiot pitää kokoonpanon versionhallinnassa. Muista lisätä db_password.txt gitignore-listaan, jos käytät Gitiä kokoonpanotiedostojen jakamiseen tiimin kesken, sillä salasanatiedoston vahingossa tapahtuva commit on yksi yleisimmistä tietovuodoista itse isännöidyissä ympäristöissä.

~/passbolt/
├── docker-compose.yml
├── db_password.txt
└── .gitignore   # sisältää rivin: db_password.txt

Vaihe 5: SSL/TLS-sertifikaatti ja käänteinen välityspalvelin

Passbolt-selainlaajennus kieltäytyy usein toimimasta luotettavasti itse allekirjoitetulla varmenteella, joten tuotantoympäristössä kannattaa käyttää Let’s Encryptin ilmaista varmennetta Caddyn tai Nginxin takana. Caddy on yksinkertaisin vaihtoehto, koska se hakee ja uusii varmenteen automaattisesti ilman erillistä certbot-ajastusta. Ennen tätä vaihetta varmista, että verkkotunnuksesi A-tietue osoittaa jo palvelimen julkiseen IP-osoitteeseen, sillä Let’s Encrypt varmentaa omistuksen juuri DNS:n kautta.

sudo apt install -y caddy
sudo tee /etc/caddy/Caddyfile <<'EOF'
passbolt.esimerkkiyritys.fi {
    reverse_proxy localhost:8443 {
        transport http {
            tls_insecure_skip_verify
        }
    }
}
EOF
sudo systemctl restart caddy

Jos ympäristössäsi ei ole julkista verkkotunnusta (esimerkiksi sisäverkkotesti), voit generoida väliaikaisen itse allekirjoitetun varmenteen, mutta muista tällöin lisätä sen juurivarmenne selaimen luotettujen varmenteiden joukkoon jokaisella työasemalla, muuten laajennus ei muodosta yhteyttä. Nginx toimii yhtä hyvin kuin Caddy, mutta vaatii erillisen certbot-asennuksen ja ajastetun uusintakomennon cronilla tai systemd-timerillä. Valitse Caddy, jos haluat pitää kokoonpanon mahdollisimman yksinkertaisena, ja Nginx, jos tarvitset hienosäädettävämpiä välityspalvelinsääntöjä muille samalla palvelimella pyöriville palveluille.

Vaihe 6–7: Palvelun käynnistys ja ylläpitäjätilin luonti

Vaihe 6. Käynnistä pino taustalle ja seuraa lokia, kunnes GPG-avainpari on generoitunut ja palvelu ilmoittaa olevansa valmis.

docker compose up -d
docker compose logs -f passbolt

Odotettu tuloste sisältää rivin tyyliin [HealthCheck] All checks passed successfully! ennen kuin web-käyttöliittymä on käytettävissä. Ensimmäinen käynnistys kestää tyypillisesti kauemmin kuin myöhemmät, koska kontti generoi tällä kertaa sekä palvelimen GPG-avainparin että JWT-tunnisteet allekirjoitusta varten. Jos loki jää junnaamaan GPG-avaimen generoinnissa, palaa taaksepäin ja varmista, että rng-tools tai haveged on käynnissä isäntäkoneella. Voit tarkistaa entropian määrän ajamalla cat /proc/sys/kernel/random/entropy_avail: arvon tulisi pysyä selvästi satojen yläpuolella, ei muutamassa kymmenessä.

Vaihe 7. Luo ensimmäinen ylläpitäjätunnus suoraan kontin sisällä komentoriviltä. Tämä on ainoa tapa luoda ensimmäinen tili, koska rekisteröintilomake avautuu vasta kutsun kautta.

docker exec passbolt-passbolt-1 su -m -c \
  "bin/cake passbolt register_user \
  -u [email protected] \
  -f Etunimi -l Sukunimi -r admin" \
  -s /bin/sh www-data

Komento tulostaa rekisteröinti-URL:n, joka sisältää kertakäyttöisen tunnisteen. Kopioi osoite ja avaa se selaimessa, jossa Passbolt-laajennus on jo asennettuna (seuraava vaihe). Tyypillinen tuloste näyttää tältä:

User saved successfully.
To start using passbolt, click on the link below or copy it in your browser.
https://passbolt.esimerkkiyritys.fi/setup/install/00a4b6c2-.../f2e91c...

Jos komento sen sijaan vastaa virheellä tietokantayhteydestä, palaa tarkistamaan DATASOURCES_DEFAULT_*-muuttujat docker-compose.yml-tiedostosta ja varmista, että db-kontti on ehtinyt käynnistyä kokonaan ennen passbolt-kontin käynnistystä. Voit lisätä docker-compose.yml-tiedostoon myös terveystarkastukseen perustuvan riippuvuuden (depends_on: condition: service_healthy), jolloin Passbolt-kontti odottaa automaattisesti, että tietokanta on todella valmis eikä vain käynnistynyt.

Vaihe 8: GPG-avaimet ja selainlaajennuksen käyttöönotto

Passbolt toimii vain virallisen selainlaajennuksen kautta Chromessa, Firefoxissa ja Edgessä. Erillistä mobiilisovellusta ei ole julkaistu, joten puhelimella käyttö tapahtuu mobiiliselaimen kautta rajoitetusti. Asenna laajennus valmistajan omasta laajennuskaupasta ja liitä se avaamaasi rekisteröinti-URL:iin.

Ensimmäisellä kirjautumiskerralla laajennus pyytää luomaan henkilökohtaisen GPG-avainparin (tai tuomaan olemassa olevan) sekä asettamaan salasanan avaimen suojaksi. Tämä yksityinen avain jää aina käyttäjän omalle laitteelle eikä koskaan siirry palvelimelle. Palvelimen oma GPG-avainpari puolestaan generoitui automaattisesti kontin käynnistyessä vaiheessa 6, hyödyntäen isäntäkoneen entropialähteitä. Jos entropia oli riittämätön, avaimen generointi saattoi kestää useita minuutteja tai jäädä roikkumaan, minkä vuoksi rng-tools kannattaa asentaa jo ennen ensimmäistä käynnistystä.

Olemassa olevan GPG-avaimen tuonti

Jos organisaatiossasi on jo käytäntö, jossa jokaisella työntekijällä on henkilökohtainen GPG-avain esimerkiksi Git-committien allekirjoitusta varten, voit tuoda saman avaimen Passboltiin sen sijaan, että loisit uuden. Tämä vähentää avainten määrää, joita käyttäjän täytyy hallita, mutta vaatii, että yksityinen avain on saatavilla siinä selaimessa, jolla Passboltiin kirjaudutaan. Setup-näkymässä valitaan "Tuo olemassa oleva avain" ja liitetään yksityinen avain PEM- tai ASCII-armor-muodossa, minkä jälkeen laajennus pyytää avaimen salasanan vahvistukseksi.

Selainlaajennuksen turvamalli ja rajoitukset

Koska Passbolt toimii aina selainlaajennuksen kautta, laajennuksen oma turvamalli on yhtä tärkeä kuin palvelimen kokoonpano. Laajennus tekee salauksen ja salauksen purun paikallisesti selaimen suojatussa kontekstissa, eikä yksityinen avain koskaan poistu selaimen omasta tallennustilasta selväkielisenä. Käytännössä tämä tarkoittaa, että jos työntekijän kannettava tietokone varastetaan, hyökkääjä tarvitsee sekä pääsyn selaimen profiiliin että avaimen suojaavan salasanan päästäkseen käsiksi salattuihin resursseihin.

Tämä malli tuo mukanaan myös rajoituksia. Koska erillistä natiivia mobiilisovellusta ei ole, kenttätyötä tekevät työntekijät joutuvat käyttämään mobiiliselainta, jossa laajennustuki vaihtelee alustan mukaan eikä kokemus vastaa työpöytäkäyttöä. Organisaatioiden, joissa suuri osa henkilöstöstä työskentelee pääasiassa mobiilisti, kannattaa testata mobiilikäyttö huolellisesti ennen laajaa käyttöönottoa, jotta työntekijät eivät ala kiertää järjestelmää kopioimalla salasanoja muistilappuihin tai muihin, vähemmän turvallisiin sovelluksiin.

Toinen huomionarvoinen rajoitus koskee jaettuja työasemia. Koska GPG-avain suojaa salasanaa selaimen omassa profiilissa, jaetulla tietokoneella työskentelevä käyttäjä ei voi luottaa siihen, että edellinen käyttäjä on kirjautunut ulos oikein, jos selainprofiilit eivät ole erillisiä. Tämän vuoksi jaetuilla työasemilla, kuten palvelinhuoneen ylläpitopäätteillä, kannattaa käyttää erillisiä käyttäjäkohtaisia selainprofiileja tai kirjautua Passboltista aktiivisesti ulos jokaisen istunnon päätteeksi.

Vaihe 9–10: Käyttäjät, ryhmät ja jaetut kansiot

Vaihe 9. Kirjaudu ylläpitäjänä ja kutsu tiimin jäsenet Käyttäjät-näkymästä sähköpostiosoitteella. Jokainen kutsuttu käy läpi saman GPG-avaimen luontivaiheen omalla laitteellaan. Kutsut lähtevät SMTP-asetusten kautta, joten jos sähköposti ei mene perille, tarkista ensin SMTP-kokoonpano ympäristömuuttujista.

Vaihe 10. Luo ryhmiä esimerkiksi tiimeittäin (Kehitys, Talous, IT-ylläpito) ja jaettuja kansioita niiden alle. Passboltin resurssit (salasanat, API-avaimet, muistiinpanot) voi jakaa yksittäisille käyttäjille tai kokonaisille ryhmille, ja jokaiselle jaolle voi asettaa oikeustason: vain luku, muokkaus tai omistajuus. Kaikki jakotapahtumat kirjautuvat lokiin, mikä on juuri se auditoitavuus, jota GDPR-artiklan 32 mukainen käsittelyn turvallisuus edellyttää organisaatioilta.

Käytännön nyrkkisääntö on, että kansiorakenne kannattaa peilata organisaatiokaaviota, ei projekteja. Projektit vaihtuvat ja loppuvat, mutta tiimit ja niiden vastuualueet pysyvät vakaampina, mikä helpottaa käyttöoikeuksien ylläpitoa pitkällä aikavälillä. Kun työntekijä vaihtaa tiimiä tai lähtee organisaatiosta, hänen käyttöoikeutensa kannattaa poistaa ryhmätasolla eikä käydä läpi jokaista yksittäistä jaettua resurssia erikseen.

Passboltin resurssityyppejä ovat perinteinen käyttäjätunnus-salasana-pari, pelkkä salasana ilman käyttäjätunnusta (esimerkiksi jaettu Wi-Fi-avain), suojattu muistiinpano ilman salasanakenttää sekä yhteystietoja ja huomautuksia sisältävä laajennettu tietue. Monessa tiimissä API-avaimet ja palvelutilien tunnukset kannattaa erottaa omaan kansioonsa henkilökohtaisista työtunnuksista, koska niillä on usein eri elinkaari ja eri henkilöt vastuussa niiden kierrättämisestä.

GDPR-vaatimustenmukaisuus: heinäkuun 2026 audit käytännössä

GDPR:n 32 artikla edellyttää rekisterinpitäjältä ja henkilötietojen käsittelijältä asianmukaisia teknisiä ja organisatorisia toimenpiteitä, kuten salausta, pääsynhallintaa ja kykyä palauttaa tiedot häiriötilanteessa. Passboltin Examin SAS:n kanssa toteuttama auditointi kattoi juuri näitä osa-alueita: tietosuojakäytännöt, tietojen säilytyssäännöt, käsittelysopimukset, hallintoprosessit sekä tekniset suojatoimet. Yhtiö listasi myös dokumentoidut prosessinsa häiriönhallinnasta, riskienhallinnasta, jatkuvuussuunnittelusta, toimittajahallinnasta ja tietoturvan hallinnoinnista osana GDPR-asemointiaan.

Suomalaiselle organisaatiolle tämä tarkoittaa käytännössä kolmea asiaa. Ensinnäkin, koska Passbolt CE on itse isännöity, henkilötietoja (käyttäjien sähköpostiosoitteet, nimet, kirjautumislokit) ei siirry Passbolt-yhtiölle lainkaan, jolloin erillistä käsittelysopimusta Passboltin kanssa ei tarvita CE-versiossa. Toiseksi, koska salausavaimet pysyvät päätelaitteilla, tietomurto palvelimelle ei automaattisesti tarkoita salasanojen vuotamista selväkielisenä, mikä helpottaa tietoturvaloukkauksen riskiarviointia GDPR:n 33 artiklan ilmoitusvelvollisuuden näkökulmasta. Kolmanneksi, organisaation on silti itse dokumentoitava oma säilytyskäytäntönsä, varmuuskopiointinsa ja pääsynhallintansa, sillä auditointi koski Passbolt-yhtiötä eikä sinun asennustasi. GDPR-sakkojen laajentuminen julkishallintoon on hyvä muistutus siitä, että itse työkalun valinta ei riitä, jos käyttöönotto on hoidettu huolimattomasti.

Käytännössä tietosuojavastaavan kannattaa dokumentoida ainakin neljä asiaa Passbolt-käyttöönoton yhteydessä: kuka pääsee käsiksi mihinkin kansioon, kuinka usein käyttöoikeuksia tarkistetaan, miten varmuuskopiot suojataan levossa ja siirrossa, sekä mikä on toimintasuunnitelma, jos palvelin joutuu tietomurron kohteeksi. Nämä neljä kohtaa vastaavat suoraan GDPR:n käsittelytoimien selosteeseen (Artikla 30) ja helpottavat huomattavasti, jos ENISA tai kansallinen valvontaviranomainen pyytää selvitystä käsittelyn turvallisuudesta. Koska Passboltin oma auditointi kattoi vain yhtiön omat prosessit, se ei korvaa organisaatiosi omaa riskiarviointia, vaan täydentää sitä osoittamalla, että käytetty työkalu on rakennettu tietosuoja edellä.

Kannattaa myös erottaa selkeästi CE- ja Pro-versioiden tietosuojavastuu. Community Editionissa organisaatio on itse ainoa rekisterinpitäjä eikä käsittelysopimusta tarvita, koska Passbolt-yhtiö ei koskaan näe dataa. Pro-version pilvitarjonnassa Passbolt puolestaan toimii henkilötietojen käsittelijänä, jolloin käsittelysopimus (DPA) tulee solmia ennen käyttöönottoa, ja juuri tähän skenaarioon heinäkuun 2026 auditointi ja Examin SAS:n DPO-nimitys erityisesti liittyvät.

Varmuuskopiointi, palautus ja päivitykset

Kahden asian menettäminen tuhoaa Passbolt-asennuksen palautuskelvottomaksi: tietokannan sisältö ja palvelimen GPG-avainpari. Ilman GPG-yksityisavainta salattuja resursseja ei voi enää purkaa, vaikka tietokanta olisikin tallessa. Ota molemmat talteen säännöllisesti, ja säilytä varmuuskopiot eri fyysisellä sijainnilla kuin tuotantopalvelin, jotta yksittäinen laitteistovika ei tuhoa sekä alkuperäistä että varmuuskopiota samalla kertaa.

# Tietokannan varmuuskopio
docker compose exec db mariadb-dump -u passbolt -p passbolt > passbolt_db_$(date +%F).sql

# GPG-avainten ja JWT-avainten varmuuskopio
docker run --rm -v passbolt_gpg_data:/gpg -v $(pwd):/backup alpine \
  tar czf /backup/passbolt_gpg_$(date +%F).tar.gz -C /gpg .

Päivitykset tehdään vaihtamalla image-tagi ja ajamalla pino uudelleen. Elokuun 2026 tietoturvatiedote, joka suositteli päivitystä versioon 5.15 tai uudempaan, on hyvä esimerkki siitä, miksi tätä komentoa kannattaa ajaa säännöllisesti eikä vain asennuksen yhteydessä kertaalleen. Ota aina varmuuskopio ennen päivitystä, sillä tietokantamigraatiot uuteen pääversioon eivät aina ole peruutettavissa.

Testaa palautus vähintään kerran kalenterivuodessa erillisessä ympäristössä, jossa ei ole tuotantodataa. Moni organisaatio huomaa varmuuskopiointinsa puutteet vasta silloin, kun oikea palautustilanne on jo käsillä, ja Passboltin tapauksessa virhe huomataan usein vasta, kun GPG-avainvolyymi puuttuu palautetusta ympäristöstä eikä yksikään salattu resurssi aukea.

docker compose pull
docker compose up -d

Passbolt vs. muut salasanhallinnat: vertailutaulukko

Passbolt ei kilpaile suoraan kuluttajatuotteiden kanssa, vaan sen lähin verrokkijoukko on muut tiimikäyttöön ja itse isännöintiin taipuvat ratkaisut. Alla on koottu keskeiset erot ominaisuustasolla. Tarkempaa hinta- ja ominaisuusvertailua kuluttajatuotteiden välillä löydät artikkelistamme Bitwarden vs. LastPass vs. KeePass.

Ratkaisu	Itse isännöinti	Salausmalli	Tiimijaon rakeisuus	Hakemistosynkronointi
Passbolt CE	Kyllä (Docker)	OpenPGP, avaimet päätelaitteella	Ryhmät, kansiot, roolit	Vain Pro/Enterprise
Vaultwarden	Kyllä (Docker)	AES-256, Bitwarden-yhteensopiva	Holvit ja kokoelmat	Ei natiivisti
KeePassXC	Ei tarvitse palvelinta	AES-256 / ChaCha20 paikallisessa tiedostossa	Manuaalinen tiedostonjako	Ei
1Password	Ei, vain SaaS	AES-256, pilvipalveluna	Holvit ja käyttöoikeusryhmät	Kyllä (SCIM)
Bitwarden (pilvi)	Ei pakollinen	AES-256	Organisaatiot ja kokoelmat	Kyllä (Business/Enterprise)

Jos organisaatiosi vaatii Active Directory- tai Azure AD -synkronoinnin suoraan salasanhallintaan, Passboltin CE-versio ei riitä, vaan tarvitaan Pro- tai Enterprise-lisenssi. Pelkkään itse isännöityyn, ilmaiseen ja OpenPGP-pohjaiseen ratkaisuun CE riittää mainiosti. Taulukosta kannattaa huomata myös, että 1Password on ainoa listatuista, joka ei tarjoa itse isännöintiä lainkaan: kaikki data kulkee valmistajan omien palvelimien kautta, mikä yksinkertaistaa ylläpitoa mutta siirtää samalla toimittajariippuvuuden ja tietosuojavastuun rajapinnan kokonaan valmistajalle.

Siirtyminen ratkaisusta toiseen ei ole koskaan täysin kitkatonta, koska salausmallit eivät ole yhteensopivia keskenään. Käytännössä migraatio esimerkiksi KeePassXC:stä tai Bitwardenista Passboltiin tehdään viemällä olemassa olevat tunnukset CSV-tiedostoon ja tuomalla se Passboltin tuontitoiminnolla, minkä jälkeen alkuperäinen vientitiedosto on tuhottava turvallisesti, koska se sisältää salasanat selväkielisenä levyllä siirron ajan. Suunnittele migraatioikkuna etukäteen ja tiedota tiimille, milloin vanha järjestelmä suljetaan, jotta kukaan ei jää käyttämään kahta rinnakkaista salasanhallintaa vahingossa.

Yleisimmät sudenkuopat asennuksessa

Suurin osa Passbolt-asennuksen ongelmista juontaa juurensa muutamaan toistuvaan virheeseen, jotka kaikki ovat vältettävissä, kun ne tietää etukäteen. Käymme läpi kuusi yleisintä, jotka nousivat esiin sekä omassa testiasennuksessamme että Passboltin yhteisöfoorumin keskusteluissa. Osa näistä virheistä on täysin Passbolt-spesifisiä, kuten GPG-avainten entropiaan liittyvät ongelmat, kun taas osa toistuu käytännössä kaikissa Docker-pohjaisissa itse isännöidyissä palveluissa.

• NTP jää asentamatta. Kellon ajautuminen pois tahdista aiheuttaa GPG-todennusvirheitä, jotka näkyvät epämääräisinä 500-virheinä kirjautumisessa. Tämä on erityisen yleistä virtuaalikoneilla, joiden kello ajautuu pois tahdista pitkän käyttökatkon jälkeen.
• APP_FULL_BASE_URL asetetaan väärin. Jos arvo ei täsmää tarkalleen sitä osoitetta, jolla käyttäjät oikeasti selaavat palveluun, mukaan lukien protokolla (https) ja mahdollinen portti, selainlaajennus ei löydä palvelinta eikä osaa muodostaa yhteyttä.
• Itse allekirjoitettua varmennetta ei tuoda selaimen luotettuihin juuriin. Laajennus epäonnistuu hiljaisesti ilman selkeää virheilmoitusta, ja moni ylläpitäjä käyttää turhaan tunteja etsien vikaa kokoonpanotiedostosta.
• Entropialähde puuttuu isäntäkoneelta. GPG-avainparin generointi kontin ensikäynnistyksellä voi jäädä roikkumaan minuuteiksi tai pidemmäksi ilman rng-tools- tai haveged-pakettia, erityisesti pilvi-VM:illä, joissa laitteistopohjaista satunnaislukugeneraattoria ei ole käytettävissä.
• GPG-avainten volyymia ei varmuuskopioida erikseen. Moni ylläpitäjä varmuuskopioi vain tietokannan ja unohtaa, että ilman palvelimen GPG-yksityisavainta salattuja resursseja ei saa enää auki, vaikka tietokantadumppi olisi täysin ehjä.
• SMTP-asetukset jätetään oletuksiksi. Ilman toimivaa lähtevää sähköpostia käyttäjäkutsut ja salasanan palautuslinkit eivät koskaan saavu perille, ja ylläpitäjä luulee virheellisesti, että käyttäjät eivät vain ole rekisteröityneet.

Yhteinen nimittäjä näissä virheissä on, että ne kaikki näkyvät vasta myöhemmin, eivät heti asennuskomennon suorittamisen jälkeen. Siksi kannattaa varata aikaa myös testaamiseen: kutsu itsellesi testikäyttäjä, kokeile salasanan palautusta ja tarkista sertifikaatin voimassaolo selaimen kehittäjätyökaluilla ennen kuin ilmoitat koko tiimille, että järjestelmä on tuotantokäytössä.

Vianmääritys: 8 yleisintä ongelmaa

Kun perusasennus alkaa toimia, ongelmat siirtyvät yleensä hienojakoisempiin yksityiskohtiin: käyttöoikeuksiin, verkkoyhteyksiin ja päivitysten yhteensopivuuteen. Alla oleva taulukko kokoaa kahdeksan tilannetta, joihin ylläpitäjä törmää todennäköisimmin ensimmäisten kuukausien aikana, sekä nopeimman tavan diagnosoida ja korjata kukin niistä.

Ongelma	Todennäköinen syy	Ratkaisu
Kontti jää loputtomaan uudelleenkäynnistyskierteeseen	Tietokantayhteys ei muodostu	Tarkista docker compose logs db ja vertaa DATASOURCES-muuttujia .env-arvoihin
GPG-avaimen generointi jumittuu käynnistyksessä	Isäntäkoneella liian vähän entropiaa	Asenna ja käynnistä rng-tools tai haveged, käynnistä kontti uudelleen
Selainlaajennus ilmoittaa "could not connect to server"	APP_FULL_BASE_URL täsmää väärin tai TLS-varmenne ei ole luotettu	Korjaa ympäristömuuttuja, uusi varmenne Let's Encryptillä
Sähköpostikutsut eivät koskaan saavu	SMTP-tunnukset puuttuvat tai palomuuri estää portin	Testaa SMTP-yhteys erikseen swaks-työkalulla ennen kuin syytät Passboltia
Admin-käyttäjän luontikomento epäonnistuu "user already exists"	Sama sähköpostiosoite on jo rekisteröity aiemmasta yrityksestä	Käytä eri osoitetta tai poista käyttäjä tietokannasta ennen uutta yritystä
Kirjautumisen jälkeen näkyy tyhjä valkoinen sivu	Selainlaajennuksen ja palvelinversion yhteensopimattomuus	Päivitä laajennus ja palvelin samaan pääversioon
Palautus varmuuskopiosta epäonnistuu salauksen purkuvirheeseen	GPG-avainvolyymia ei palautettu tietokannan mukana	Palauta aina tietokanta ja gpg_data-volyymi yhdessä, ei erikseen
Tietoturvaskanneri raportoi vanhan version haavoittuvuuden	Image-tagia ei ole päivitetty elokuun 2026 tiedotteen jälkeen	Aja docker compose pull && docker compose up -d ja tarkista versio ylläpitopaneelista

Useimmat näistä tilanteista ratkeavat lokien lukemisella ennen kuin ryhtyy vaihtamaan kokoonpanoa arvailemalla. Komento docker compose logs --tail=100 passbolt näyttää yleensä suoraan, missä kohtaa käynnistysketju katkeaa, ja se kannattaa ottaa ensimmäiseksi työkaluksi ennen kuin tarttuu mihinkään muuhun diagnoosikeinoon.

Edistyneet vinkit: LDAP, MFA ja API-automaatio

Kun perusasennus on pystyssä ja tiimi käyttää sitä aktiivisesti, seuraava askel on usein tunnistautumisen ja automaation syventäminen. Passbolt CE tukee TOTP-pohjaista kaksivaiheista tunnistautumista suoraan käyttäjätileille, mikä kannattaa pakottaa päälle kaikille ylläpitäjätileille heti käyttöönoton jälkeen. Laajempi hakemistosynkronointi LDAP:n tai Azure AD:n kanssa, jossa käyttäjät ja ryhmät tuodaan automaattisesti yrityksen omasta käyttäjähakemistosta, on rajattu Pro- ja Enterprise-lisensseihin eikä sisälly CE-versioon.

Passboltin REST-rajapinnan kautta voi automatisoida esimerkiksi salaisuuksien kiertoa CI/CD-putkissa tai palvelintunnusten jakelua uusille virtuaalikoneille ilman manuaalista kopiointia. Tuotantoympäristössä kannattaa myös seurata kontin terveystarkastusta osana yleistä valvontaa (Prometheus, Zabbix tai vastaava), jotta tietokantayhteyden katkeaminen tai levytilan loppuminen huomataan ennen kuin käyttäjät ehtivät valittaa.

Kaksivaiheinen tunnistautuminen ylläpitäjille

Koska ylläpitäjätili pystyy hallinnoimaan kaikkia käyttäjiä ja ryhmiä, sen suojaaminen pelkällä GPG-avaimella ja salasanalla ei riitä tuotantoympäristössä. Passbolt CE tukee TOTP-pohjaista kaksivaiheista tunnistautumista, joka kannattaa ottaa käyttöön Käyttäjäasetukset-valikosta heti ensimmäisen kirjautumisen jälkeen. Käytännössä tämä tarkoittaa, että pelkkä varastettu GPG-avain ja sen salasana eivät riitä murtautujalle, vaan hän tarvitsee myös pääsyn ylläpitäjän autentikaattorisovellukseen. Tämä on erityisen tärkeää, koska ylläpitäjätili on ainoa, joka pystyy palauttamaan toisen käyttäjän pääsyn, jos tämä hukkaa oman avaimensa.

Kannattaa myös harkita erillisen lukuoikeuden API-avaimen luomista raportointi- ja valvontatarkoituksiin, jotta pääkäyttäjän henkilökohtaista tunnusta ei tarvitse käyttää automaatioskripteissä. Passboltin API-avaimet voi rajata tiettyihin toimintoihin, mikä pienentää vahinkoa, jos automaatiopalvelimen tunnukset vuotavat.

Terveystarkastuksen automatisointi

Yksinkertaisin tapa saada hälytys palvelun kaatumisesta on ajastaa säännöllinen tarkistus, joka kutsuu Passboltin healthcheck-toimintoa suoraan kontin sisällä ja lähettää tuloksen valvontajärjestelmään.

# Ajasta esimerkiksi crontabiin viiden minuutin välein
*/5 * * * * docker exec passbolt-passbolt-1 su -m -c "bin/cake passbolt healthcheck" -s /bin/sh www-data | grep -q "ERROR" && echo "Passbolt-häiriö havaittu" | mail -s "Passbolt ALERT" [email protected]

Vakavammassa tuotantoympäristössä tämä kannattaa korvata varsinaisella valvontajärjestelmällä, mutta yllä oleva rivi riittää hälyttämään pienelle tiimille, ennen kuin kukaan ehtii huomata ongelmaa manuaalisesti.

Valmis projekti: kaikki tiedostot yhdessä paketissa

Tässä on koko asennuksen lopputulos yhteen koottuna. Kun kopioit nämä kolme tiedostoa uuteen kansioon, vaihdat verkkotunnuksen ja generoit oman salasanatiedoston, sinulla on tuotantovalmis, itse isännöity Passbolt-asennus Caddyn ja Let's Encryptin taakse suojattuna.

# docker-compose.yml
services:
  db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MYSQL_RANDOM_ROOT_PASSWORD: "true"
      MYSQL_DATABASE: passbolt
      MYSQL_USER: passbolt
      MYSQL_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
    volumes:
      - db_data:/var/lib/mysql

  passbolt:
    image: passbolt/passbolt:latest-ce
    restart: unless-stopped
    depends_on:
      - db
    environment:
      APP_FULL_BASE_URL: https://passbolt.esimerkkiyritys.fi
      DATASOURCES_DEFAULT_HOST: db
      DATASOURCES_DEFAULT_USERNAME: passbolt
      DATASOURCES_DEFAULT_PASSWORD_FILE: /run/secrets/db_password
      DATASOURCES_DEFAULT_DATABASE: passbolt
    secrets:
      - db_password
    ports:
      - "8443:443"
    volumes:
      - gpg_data:/etc/passbolt/gpg
      - jwt_data:/etc/passbolt/jwt

secrets:
  db_password:
    file: ./db_password.txt

volumes:
  db_data:
  gpg_data:
  jwt_data:

# Caddyfile
passbolt.esimerkkiyritys.fi {
    reverse_proxy localhost:8443 {
        transport http {
            tls_insecure_skip_verify
        }
    }
}

Käynnistys tapahtuu samalla komennolla kuin vaiheessa 6: docker compose up -d. Huomaa, että porttia 443 ei tässä versiossa avata suoraan ulos, vaan Caddy kuuntelee ulkoista liikennettä ja välittää sen sisäisesti porttiin 8443, jossa Passbolt-kontti kuuntelee omalla itse allekirjoitetulla varmenteellaan. Tämä kaksinkertainen TLS-kerros (Caddyn julkinen Let's Encrypt -varmenne ulkopuolella, Passboltin sisäinen varmenne kontin ja Caddyn välillä) on Passboltin virallisen dokumentaation suosittelema malli, koska se pitää liikenteen salattuna myös palvelimen sisäisessä verkossa.

Ennen kuin kutsut ensimmäistä oikeaa käyttäjää, kannattaa vielä käydä läpi tarkistuslista: DNS osoittaa oikeaan palvelimeen, Caddy on saanut kelvollisen Let's Encrypt -varmenteen (näet tämän Caddyn lokista komennolla sudo journalctl -u caddy -f), SMTP-lähetys on testattu, ja sekä tietokanta- että GPG-avainvolyymit on varmuuskopioitu vähintään kerran. Vasta tämän jälkeen kannattaa merkitä asennus tuotantovalmiiksi.

Usein kysytyt kysymykset

Onko Passbolt CE todella ilmainen tuotantokäyttöön?
Kyllä. Community Edition on avointa lähdekoodia ja ilmainen itse isännöitäväksi ilman käyttäjärajaa. Maksulliset Pro- ja Enterprise-versiot lisäävät muun muassa hakemistosynkronoinnin ja laajemman tuen.

Tarvitsenko erillisen käsittelysopimuksen Passboltin kanssa?
Et, jos ajat Community Editionia täysin omalla infrastruktuurillasi, koska tällöin henkilötietoja ei siirry Passbolt-yhtiölle. Pilvipohjaisessa Pro-versiossa tilanne on toinen ja käsittelysopimus tarvitaan.

Mitä tapahtuu, jos palvelimen GPG-avain katoaa?
Kaikki palvelimelle tallennetut salatut resurssit muuttuvat palautuskelvottomiksi. Tämän vuoksi GPG-avainvolyymin varmuuskopiointi on yhtä kriittistä kuin tietokannan varmuuskopiointi.

Toimiiko Passbolt puhelimella?
Passbolt ei julkaise erillistä natiivia mobiilisovellusta. Käyttö puhelimella onnistuu mobiiliselaimen kautta, mutta kokemus on rajoittuneempi kuin työpöytäselaimen laajennuksella.

Voiko Passboltin siirtää myöhemmin Vaultwardenista tai KeePassXC:stä?
Suoraa automaattista tuontityökalua näiden välillä ei ole, koska salausmallit eroavat toisistaan. Käytännössä siirto tehdään vientinä CSV-muotoon lähdejärjestelmästä ja tuontina Passboltiin, minkä jälkeen vanhat vientitiedostot on tuhottava turvallisesti.

Kuinka usein Passbolt-asennus pitää päivittää?
Vähintään aina, kun yhtiö julkaisee tietoturvatiedotteen, kuten elokuun 2026 päivityksen versioon 5.15. Käytännössä kuukausittainen docker compose pull -tarkistus on turvallinen rytmi, ja tietoturvatiedotteet kannattaa tilata sähköpostiin tai RSS-syötteenä suoraan Passboltin sivustolta, jotta et jää niistä paitsi.

Suojaako Passbolt CVE-2025-27913-haavoittuvuudelta automaattisesti?
Jos käytät ohjeen mukaista latest-ce-tagia tuoreella asennuksella, saat version, jossa host header -injektiohaavoittuvuus on jo korjattu. Vanhoja, päivittämättömiä asennuksia (API ≤ 4.11.1) tämä koskee edelleen.

Voiko Passboltin ajaa ilman julkista verkkotunnusta pelkässä sisäverkossa?
Kyllä, mutta silloin jokaiselle työasemalle pitää tuoda itse allekirjoitetun varmenteen juurisertifikaatti manuaalisesti, muuten selainlaajennus kieltäytyy muodostamasta yhteyttä.

Tukeeko Passbolt LDAP- tai Azure AD -synkronointia CE-versiossa?
Ei. Hakemistosynkronointi on rajattu Pro- ja Enterprise-lisensseihin. Community Editionissa käyttäjät kutsutaan ja poistetaan manuaalisesti tai omalla skriptillä REST-rajapinnan kautta.

Mitä eroa on Passboltin ja Vaultwardenin salausmallilla?
Vaultwarden nojaa Bitwardenin AES-256-pohjaiseen malliin, jossa käyttäjän pääsalasanasta johdettu avain salaa holvin sisällön. Passbolt puolestaan käyttää OpenPGP-avainpareja, joissa jokaisella käyttäjällä on oma julkinen ja yksityinen avain, ja jaettu salasana salataan erikseen jokaisen vastaanottajan julkisella avaimella. Käytännön seuraus on, että Passboltissa käyttöoikeuden peruminen ryhmältä ei vaadi koko holvin uudelleensalausta samalla tavalla kuin joissain holvipohjaisissa malleissa.

Voiko Passboltia käyttää ilman selainlaajennusta, esimerkiksi pelkän mobiiliselaimen kautta?
Osittain. Passboltin verkkosovellus toimii mobiiliselaimessa, mutta täysi toiminnallisuus, kuten uusien salasanojen luonti ja salauksen purku, edellyttää laajennuksen tukemaa selainta. Puhtaassa mobiilikäytössä osa toiminnoista on siksi rajoitetumpi kuin työpöytäselaimella.