Wiki.js zelf hosten in 2026: database instellen, TLS en hersteltests
Implementeer Wiki.js met de juiste poort, duurzame opslag, TLS, authenticatie en backups. Los problemen op wanneer DB_HOST in de container localhost is of TLS-proxyheaders in productie ontbreken.
De meeste installatie-instructies voor Wiki.js eindigen zodra de eerste pagina is geladen. Dat is te vroeg: DB_HOST is localhost in de container of TLS-proxyheaders ontbreken. Een bruikbare productietest is veeleisender: voltooi de installatie, maak een pagina, pas die aan, upload media, zoek de pagina op en controleer de versiegeschiedenis na een herstart.
De rol van Wiki.js is eenvoudig: een Markdown-wiki met versiebeheer en een moderne editor. De operationele scope omvat meer dan alleen het webproces. Daarom moeten de dependency, opgeslagen status en publieke route expliciet worden vastgelegd voordat er echte data binnenkomt.
De runtimegrens van Wiki.js in kaart brengen
De kleinste verantwoorde Wiki.js-topologie bevat één private listener op poort 3000, een ingress-route en een gedocumenteerde statusgrens. Het netwerkcontract voor Wiki.js is een bereikbare Postgres-, MySQL-, MariaDB-, MSSQL- of SQLite-database. Houd private endpoints op interne DNS, sta alleen noodzakelijke uitgaande verbindingen toe en geef Wiki.js een servicecredential met beperkte rechten.
Valideer de topologie door een schone client de installatie te laten voltooien, een pagina te laten maken en aanpassen, media te laten uploaden, de pagina te laten zoeken en de versiegeschiedenis na een herstart te laten controleren. Houd tijdens deze test de responstijd van de database, search indexing, mediaopslag en latency van de authentication provider in de gaten. Het resultaat laat zien of de volgende verbetering in geheugen, opslag, networking of een aparte worker moet worden gezocht, in plaats van willekeurig de container groter te maken.
Het herstel van Wiki.js ontwerpen vóór de lancering
In de standaard Wiki.js-image wordt geen schrijfbare applicatiestatus verwacht. Bewaar de database plus eventuele lokale uploads en custom assets, inclusief de vastgelegde digest en gecontroleerde routeconfiguratie, in plaats van een leeg containerfilesystem te back-uppen.
Maak Wiki.js vanaf nul aan op een andere host en controleer of pagina's, geschiedenis, gebruikers, groepen, media en navigatie terugkomen en een bekende pagina vindbaar blijft. Als je een aparte database, room server of authenticatielaag toevoegt, geef dat component een eigen, expliciet recovery owner. De Git-to-production-handleiding laat zien hoe een reproduceerbaar artifact een containerbackup vervangt.
Leg het rebuild-commando en de test met de bekende output vast bij de release. Een stateless herstelplan slaagt door gedrag te reproduceren vanuit betrouwbare inputs; het mag niet afhankelijk zijn van het kopiëren van een ondoorzichtige, draaiende container.
De trust boundary van Wiki.js kiezen
Een veilige Wiki.js-deployment begint met het wegnemen van bevoegdheden. Laat het setupscherm niet bereikbaar nadat de eerste administrator is aangemaakt. Verwijder in plaats daarvan publieke toegang tot de setup, beperk beheerfuncties en geef de wikidatabase eigen credentials.
Behandel DB_PASS volgens de rol ervan in Wiki.js: houd gevoelige waarden uit Git, documenteer de gevolgen van rotatie en gebruik in productie nooit een openbaar voorbeeld als vervanging. Beperk administratieve routes, gebruik private DNS voor dependencies en controleer elke bind mount. Wanneer logs centraal worden verzameld, filter je secrets en private content voordat ze de server verlaten.
Wat moet slagen voordat echte Wiki.js-data binnenkomt
Een production gate voor Wiki.js moet uitvoerbaar zijn door iemand die de deployment niet heeft gebouwd. Geef die persoon de vastgelegde versie, een niet-gevoelig testaccount en deze opdracht: voltooi de installatie, maak een pagina, pas die aan, upload media, zoek de pagina op en controleer de versiegeschiedenis na een herstart. Als de instructies ongedocumenteerde shelltoegang vereisen, is de service operationeel nog niet klaar.
Herhaal de gate nadat je alleen de container hebt vervangen. Herstel daarna de database plus eventuele lokale uploads en custom assets naar lege infrastructuur en bewijs dat pagina's, geschiedenis, gebruikers, groepen, media en navigatie terugkomen en een bekende pagina vindbaar blijft. Meet tijdens beide geslaagde runs de responstijd van de database, search indexing, mediaopslag en latency van de authentication provider. Onverwachte verschillen wijzen vaak op een ontbrekende cache, index, worker of datamount.
Voeg een failure drill toe: ontzeg de testidentiteit tijdelijk de toegang tot een bereikbare Postgres-, MySQL-, MariaDB-, MSSQL- of SQLite-database. Wiki.js moet een bruikbare foutmelding geven, de bestaande status behouden en herstellen zodra de geldige situatie terugkeert. Sla de tijdstippen en relevante logregels op en redigeer secrets. Dat bewijs wordt de referentie voor de volgende image- of configuratiewijziging.
Wiki.js starten zonder de bewegende onderdelen te verbergen
Houd de eerste Wiki.js-invocatie voldoende reproduceerbaar om in een pull request te kunnen reviewen.
docker run -d \
--name wiki-js \
--restart unless-stopped \
-p 127.0.0.1:3000:3000 \
-e DB_PASS=replace-with-a-long-random-value \
-e DB_TYPE=postgres \
-e DB_HOST=postgres.internal \
-e DB_PORT=5432 \
-e DB_USER=wiki \
-e DB_NAME=wiki \
ghcr.io/requarks/wiki:2
Vertrouw niet op latest zodra er echte data bestaat. Leg de werkende digest, container user en mount-eigenaarschap vast. Volg het applicatielog door een volledige test heen — voltooi de installatie, maak een pagina, pas die aan, upload media, zoek de pagina op en controleer de versiegeschiedenis na een herstart — en noteer eventuele migrations voordat je de route achter productie-verkeer plaatst.
Interne en externe URL's correct houden
Behandel de externe Wiki.js-URL als configuratie die redeployments overleeft. Configureer eerst de site-URL nadat je de service via HTTPS hebt gerouteerd; routeer vervolgens de hostname naar poort 3000, met de oorspronkelijke host en scheme intact.
De checklist voor deployment-bereikbaarheid kan aantonen dat requests de container binnenkomen. Daarna moet je de bekende fout — DB_HOST is localhost in de container of TLS-proxyheaders ontbreken — onderzoeken in Wiki.js, de bijbehorende status of de workload, en niet in certificate automation.
De workload bewaken, niet alleen de container
Bouw dashboards rond de responstijd van de database, search indexing, mediaopslag en latency van de authentication provider. Een CPU-grafiek zonder context over die workload kan niet verklaren waarom Wiki.js traag is. Voeg een synthetic of geplande check toe die met ongevaarlijke testdata de installatie probeert te voltooien, een pagina maakt en aanpast, media uploadt, de pagina opzoekt en de versiegeschiedenis na een herstart controleert.
Houd vóór een upgrade rekening met dit applicatiespecifieke risico: database migrations en authentication modules van Wiki.js moeten worden gestaged voordat je naar een andere release line overstapt. Herstel een recente backup naar een geïsoleerde deployment, voer daar migrations uit en vergelijk het gedrag. Als DB_HOST localhost is in de container of TLS-proxyheaders ontbreken, controleer dan eerst de betrokken grens — public origin, opslag of dependency — voordat je niet-gerelateerde instellingen aanpast.
Wiki.js expliciet houden terwijl Dockup de routing afhandelt
Routing, certificaten, service replacement en attached storage zijn redelijke doelen voor automation. Dockup handelt die voor Wiki.js af en kan de bijbehorende managed database provisionen of verbinding maken met services op de eigen server van een klant.
Wat het niet moet verzinnen, is het trustbeleid van Wiki.js. Configureer na de deployment de site-URL nadat je de service via HTTPS hebt gerouteerd, dwing deze grens af — verwijder publieke toegang tot de setup, beperk beheerfuncties en geef de wikidatabase eigen credentials — en verifieer het resultaat van dit scenario: voltooi de installatie, maak een pagina, pas die aan, upload media, zoek de pagina op en controleer de versiegeschiedenis na een herstart. Het resultaat is infrastructuur met één klik en een applicatiespecifieke acceptatietest.
Veelgestelde vragen
Wat heeft Wiki.js nodig voor een productiedeployment?
Routeer de Wiki.js-container op poort 3000 via één HTTPS-origin. De bijbehorende netwerkvereiste is een bereikbare Postgres-, MySQL-, MariaDB-, MSSQL- of SQLite-database. Markeer Wiki.js pas als klaar wanneer je de installatie kunt voltooien, een pagina kunt maken en aanpassen, media kunt uploaden, de pagina kunt opzoeken en de versiegeschiedenis na een herstart kunt controleren.
Welke Wiki.js-data hoort in een backup?
De standaard Wiki.js-image heeft geen vereiste mount voor applicatiedata. Bewaar de deploymentconfiguratie en back-up verbonden status afzonderlijk; het herstel slaagt wanneer pagina's, geschiedenis, gebruikers, groepen, media en navigatie terugkomen en een bekende pagina vindbaar blijft.
Heeft Wiki.js HTTPS nodig achter een reverse proxy?
Gebruik HTTPS voor de publieke Wiki.js-origin en houd poort 3000 op de interne route. Pas de Wiki.js-instelling correct toe: configureer de site-URL nadat je de service via HTTPS hebt gerouteerd. Voor Wiki.js beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het voor consistent gedrag van clients die gevoelig zijn voor de origin.
Hoe moet je een Wiki.js-upgrade testen?
Herstel de actuele Wiki.js-status naar een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat database migrations en authentication modules van Wiki.js moeten worden gestaged voordat je naar een andere release line overstapt. Bewaar de vorige Wiki.js-image totdat de grenzen van datamigratie en rollback duidelijk zijn.