Så självhostar du Wiki.js 2026: databas, TLS och återställningstester

De flesta installationsanvisningar för Wiki.js slutar efter den första sidladdningen. Det är för tidigt: DB_HOST är localhost inuti containern eller så saknas TLS proxy headers. Ett användbart produktionstest är mer krävande — slutför installationen, skapa och redigera en sida, ladda upp media, sök efter den och kontrollera versionshistoriken efter en omstart.

Wiki.js har en tydlig roll: en Markdown-baserad wiki med versionshantering och en modern editor. Den operativa gränsen omfattar mer än webbprocessen, så beroendet, det lagrade tillståndet och den publika routen måste namnges explicit innan riktiga data anländer.

Rita upp Wiki.js runtime-gräns

Den minsta ansvarsfulla Wiki.js-topologin innehåller en privat listener på 3000, en ingress-route och en dokumenterad state-gräns. Nätverkskontraktet för Wiki.js är en nåbar Postgres-, MySQL-, MariaDB-, MSSQL- eller SQLite-databas. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge Wiki.js en avgränsad service credential.

Validera topologin genom att låta en ren klient slutföra installationen, skapa och redigera en sida, ladda upp media, söka efter den och kontrollera versionshistoriken efter en omstart. Övervaka databasens svarstid, sökindexering, medielagring och latency hos autentiseringsleverantören medan testet körs. Resultatet visar om nästa förbättring hör hemma i minne, lagring, nätverk eller en separat worker, i stället för att uppmuntra till godtycklig dimensionering av containern.

Planera återställning av Wiki.js före lansering

Ingen skrivbar application state förväntas finnas i standardavbildningen för Wiki.js. Bevara databasen samt lokala uppladdningar och custom assets, inklusive den låsta digest-versionen och den granskade route-konfigurationen, i stället för att säkerhetskopiera ett tomt containerfilsystem.

Skapa Wiki.js från grunden på en annan host och verifiera att sidor, historik, användare, grupper, media och navigation återställs samt att en känd sida fortfarande går att söka fram. Om en separat databas, room server eller autentiseringslager läggs till ska den komponenten få en egen, uttrycklig recovery owner. Guiden från Git till produktion visar hur en reproducerbar artifact ersätter en container backup.

Dokumentera rebuild-kommandot och testet med förväntat resultat tillsammans med releasen. En stateless recovery-plan lyckas genom att återskapa beteendet från betrodda indata; den ska inte vara beroende av att kopiera en ogenomskinlig, körande container.

Välj Wiki.js trust boundary

En säker Wiki.js-deployment börjar med att minska behörigheterna. Undvik att låta installationssidan vara exponerad efter att den första administratören har skapats. Ta i stället bort publik åtkomst till installationen, begränsa administrationen och ge wiki-databasen egna credentials.

Hantera DB_PASS utifrån dess roll i Wiki.js: håll känsliga värden borta från Git, dokumentera effekterna av rotation och ersätt aldrig ett publikt exempel i produktion. Begränsa administrativa routes, använd privat DNS för beroenden och granska varje bind mount. När loggar skickas centralt ska hemligheter och privat innehåll filtreras bort innan de lämnar servern.

Vad måste fungera innan riktiga Wiki.js-data anländer

En production gate för Wiki.js ska kunna genomföras av någon som inte byggde deploymenten. Ge personen den låsta versionen, ett testkonto utan känsliga data och följande uppgift: slutför installationen, skapa och redigera en sida, ladda upp media, sök efter den och kontrollera versionshistoriken efter en omstart. Om instruktionerna kräver odokumenterad shell-åtkomst är tjänsten ännu inte redo ur ett operativt perspektiv.

Upprepa kontrollen efter att endast containern har ersatts. Återställ sedan databasen samt lokala uppladdningar och custom assets till blank infrastruktur och bevisa att sidor, historik, användare, grupper, media och navigation återställs samt att en känd sida fortfarande går att söka fram. Mät databasens svarstid, sökindexering, medielagring och latency hos autentiseringsleverantören under båda lyckade körningarna. Oväntade skillnader avslöjar ofta en cache, ett index, en worker eller en data mount som saknas.

Lägg till en failure drill: neka tillfälligt testidentiteten åtkomst till en nåbar Postgres-, MySQL-, MariaDB-, MSSQL- eller SQLite-databas. Wiki.js ska rapportera ett användbart fel, bevara befintligt state och återhämta sig när det korrekta villkoret återställs. Spara tidsstämplarna och relevanta loggrader, med secrets redigerade. Den evidensen blir referens för nästa ändring av image eller konfiguration.

Starta Wiki.js utan att dölja de rörliga delarna

Håll den första Wiki.js-invocationen tillräckligt reproducerbar för att kunna granskas i en pull request.

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

Förlita dig inte på latest efter att riktiga data har lagrats. Dokumentera den fungerande digest-versionen, containeranvändaren och ägarskapet för mounts. Följ applikationsloggen genom ett komplett test — slutför installationen, skapa och redigera en sida, ladda upp media, sök efter den och kontrollera versionshistoriken efter en omstart — och notera eventuella migrations innan routen placeras bakom produktionstrafik.

Håll interna och externa URL:er isär

Betrakta den externa Wiki.js-URL:en som konfiguration som ska överleva redeployments. Konfigurera först site URL efter att tjänsten har routats via HTTPS. Routa sedan hostname till port 3000 med ursprunglig host och scheme intakta.

Checklistan för deployment-reachability kan bevisa att requests når containern. Därefter ska det kända felet — DB_HOST är localhost inuti containern eller så saknas TLS proxy headers — undersökas i Wiki.js, dess state eller dess workload, inte i certificate automation.

Övervaka workloaden, inte bara containern

Bygg dashboards kring databasens svarstid, sökindexering, medielagring och latency hos autentiseringsleverantören. En CPU-graf utan det workload-sammanhanget kan inte förklara varför Wiki.js är långsamt. Lägg till en synthetic eller schemalagd kontroll som försöker slutföra installationen, skapa och redigera en sida, ladda upp media, söka efter den och kontrollera versionshistoriken efter en omstart med ofarliga testdata.

Ta hänsyn till följande applicationsspecifika risk före en uppgradering: Wiki.js-databasmigrationer och autentiseringsmoduler bör testas stegvis innan du går över till en annan release-linje. Återställ en aktuell backup till en isolerad deployment, kör migrations där och jämför beteendet. Om DB_HOST är localhost inuti containern eller TLS proxy headers saknas ska du undersöka den berörda gränsen — publikt origin, lagring eller dependency — innan du ändrar orelaterade inställningar.

Håll Wiki.js explicit medan Dockup hanterar routing

Routing, certifikat, service replacement och ansluten lagring är rimliga mål för automation. Dockup hanterar detta för Wiki.js och kan provisionera den tillhörande managed databasen eller ansluta till tjänster på kundens egen server.

Det som Dockup inte ska hitta på är Wiki.js trust policy. Efter deployment ska du konfigurera site URL efter att tjänsten har routats via HTTPS, upprätthålla denna gräns — ta bort publik åtkomst till installationen, begränsa administrationen och ge wiki-databasen egna credentials — och verifiera resultatet av följande scenario: slutför installationen, skapa och redigera en sida, ladda upp media, sök efter den och kontrollera versionshistoriken efter en omstart. Resultatet är infrastruktur med one-click-deployment och ett applikationsspecifikt acceptanstest.

Vanliga frågor

Vad behöver Wiki.js för en produktionsdeployment?

Routa Wiki.js-containern på port 3000 via ett HTTPS-origin. Det stödjande nätverkskravet är en nåbar Postgres-, MySQL-, MariaDB-, MSSQL- eller SQLite-databas. Betrakta inte Wiki.js som redo förrän du kan slutföra installationen, skapa och redigera en sida, ladda upp media, söka efter den och kontrollera versionshistoriken efter en omstart.

Vilka Wiki.js-data ska ingå i en backup?

Standardavbildningen för Wiki.js har ingen obligatorisk mount för applikationsdata. Bevara deployment-konfigurationen och säkerhetskopiera anslutet state separat. Återställningen är godkänd när sidor, historik, användare, grupper, media och navigation återställs samt när en känd sida fortfarande går att söka fram.

Kräver Wiki.js HTTPS bakom en reverse proxy?

Använd HTTPS för Wiki.js publika origin och behåll port 3000 på den interna routen. Tillämpa Wiki.js-inställningen korrekt: konfigurera site URL efter att tjänsten har routats via HTTPS. För Wiki.js skyddar HTTPS credentials eller användarinnehåll under överföring och håller origin-känsligt klientbeteende konsekvent.

Hur bör en Wiki.js-uppgradering testas?

Återställ aktuellt Wiki.js-state till en isolerad deployment, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom Wiki.js-databasmigrationer och autentiseringsmoduler bör testas stegvis innan du går över till en annan release-linje. Behåll den tidigare Wiki.js-avbildningen tills gränsen för datamigrering och rollback är förstådd.