Sådan self-hoster du Wiki.js i 2026: Databaseopsætning, TLS og gendannelsestest

De fleste installationsnoter til Wiki.js slutter ved den første sideindlæsning. Det er for tidligt: DB_HOST er localhost inde i containeren, eller TLS-proxyheaders mangler. En nyttig produktionstest er mere krævende — gennemfør opsætningen, opret og rediger en side, upload medier, søg efter dem, og gennemgå versionshistorikken efter en genstart.

Wiki.js' rolle er enkel: en Markdown-wiki med versionsstyring og en moderne editor. Den driftsmæssige afgrænsning omfatter mere end webprocessen, så afhængigheden, den gemte tilstand og den offentlige route skal navngives eksplicit, før der kommer rigtige data ind.

Tegn Wiki.js' runtimegrænse

Den mindste ansvarlige Wiki.js-topologi består af én privat listener på 3000, en ingress-route og en dokumenteret state-grænse. Netværkskontrakten for Wiki.js er en tilgængelig Postgres-, MySQL-, MariaDB-, MSSQL- eller SQLite-database. Hold private endpoints på intern DNS, tillad kun nødvendige outbound-kald, og giv Wiki.js en service credential med begrænset scope.

Valider topologien ved at bede en ren klient gennemføre opsætningen, oprette og redigere en side, uploade medier, søge efter dem og gennemgå versionshistorikken efter en genstart. Overvåg databasens svartid, search indexing, medielager og latency for authentication-provideren, mens testen kører. Resultatet viser, om den næste forbedring hører hjemme i memory, storage, networking eller en separat worker, i stedet for at opmuntre til vilkårlig dimensionering af containeren.

Design gendannelse af Wiki.js før lancering

Der forventes ingen skrivbar application state i standard-Wiki.js-imaget. Bevar databasen samt eventuelle lokale uploads og custom assets, inklusive den fastlåste digest og den gennemgåede route-konfiguration, i stedet for at tage backup af et tomt container-filsystem.

Opret Wiki.js fra bunden på en anden host, og verificer, at sider, historik, brugere, grupper, medier og navigation kommer tilbage, og at en kendt side fortsat kan findes i søgningen. Hvis der tilføjes en separat database, room server eller authentication layer, skal den komponent have sin egen eksplicitte recovery owner. Guiden fra Git til produktion viser, hvordan et reproducerbart artifact erstatter en container-backup.

Registrer rebuild-kommandoen og testen med det forventede output sammen med releasen. En stateless recovery-plan lykkes ved at reproducere adfærd ud fra pålidelige inputs; den bør ikke afhænge af at kopiere en uigennemsigtig, kørende container.

Vælg Wiki.js' trust boundary

En sikker Wiki.js-deployment starter med at fjerne rettigheder. Undgå at lade opsætningssiden være offentligt tilgængelig, efter den første administrator er oprettet. Fjern i stedet offentlig adgang til opsætningen, begræns administrationen, og giv wikidatabasen sine egne credentials.

Behandl DB_PASS efter den rolle, variablen har i Wiki.js: Opbevar sensitive værdier uden for Git, dokumentér konsekvenserne af rotation, og brug aldrig et offentligt eksempel i produktion. Begræns administrative routes, brug privat DNS til afhængigheder, og gennemgå alle bind mounts. Når logs sendes til et centralt system, skal secrets og privat indhold filtreres, før de forlader serveren.

Hvad skal bestå, før rigtige Wiki.js-data kommer ind

En production gate for Wiki.js skal kunne udføres af en person, der ikke har bygget deploymenten. Giv personen den fastlåste version, en ikke-sensitiv testkonto og denne opgave: gennemfør opsætningen, opret og rediger en side, upload medier, søg efter dem, og gennemgå versionshistorikken efter en genstart. Hvis instruktionerne kræver udokumenteret shell-adgang, er servicen endnu ikke driftsklar.

Gentag testen efter kun at have udskiftet containeren. Gendan derefter databasen samt eventuelle lokale uploads og custom assets til blank infrastruktur, og bevis, at sider, historik, brugere, grupper, medier og navigation kommer tilbage, og at en kendt side fortsat kan findes i søgningen. Mål databasens svartid, search indexing, medielager og latency for authentication-provideren under begge vellykkede kørsler; uventede forskelle afslører ofte en manglende cache, et manglende index, en worker eller et data mount.

Tilføj en failure drill: Afvis midlertidigt testidentitetens adgang til en tilgængelig Postgres-, MySQL-, MariaDB-, MSSQL- eller SQLite-database. Wiki.js skal vise en nyttig fejl, bevare den eksisterende state og gendanne driften, når den gyldige betingelse vender tilbage. Gem timestamps og relevante loglinjer med secrets redacted. Denne dokumentation bliver referencepunktet for det næste image- eller konfigurationsskift.

Start Wiki.js uden at skjule de bevægelige dele

Hold den første Wiki.js-invocation så reproducerbar, at den kan gennemgås 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

Stol ikke på latest, når der først findes rigtige data. Registrer den fungerende digest, containerbrugeren og ejerskabet af mounts. Følg application-loggen gennem en komplet test — gennemfør opsætningen, opret og rediger en side, upload medier, søg efter dem, og gennemgå versionshistorikken efter en genstart — og notér eventuelle migrations, før du sender routen gennem produktionstrafik.

Hold interne og eksterne URL'er adskilt

Betragt den eksterne Wiki.js-URL som konfiguration, der skal overleve redeployments. Konfigurér først site-URL'en, efter at servicen er routet gennem HTTPS. Rout derefter hostnavnet til port 3000 med den oprindelige host og scheme intakt.

Tjeklisten til deployment reachability kan bevise, at requests kommer ind i containeren. Derefter skal den kendte fejl — DB_HOST er localhost inde i containeren, eller TLS-proxyheaders mangler — undersøges i Wiki.js, dens state eller dens workload, ikke i certificate automation.

Overvåg workloaden, ikke kun containeren

Byg dashboards omkring databasens svartid, search indexing, medielager og latency for authentication-provideren. En CPU-graf uden denne workload-kontekst kan ikke forklare, hvorfor Wiki.js er langsom. Tilføj et syntetisk eller scheduled check, der forsøger at gennemføre opsætningen, oprette og redigere en side, uploade medier, søge efter dem og gennemgå versionshistorikken efter en genstart ved hjælp af ufarlige testdata.

Før en upgrade skal du tage højde for denne applikationsspecifikke risiko: Wiki.js-databasemigrationer og authentication modules bør testes trinvist, før du skifter til en anden release-linje. Gendan en nylig backup til en isoleret deployment, kør migrations dér, og sammenlign adfærden. Hvis DB_HOST er localhost inde i containeren, eller TLS-proxyheaders mangler, skal du undersøge den relevante grænse — public origin, storage eller dependency — før du ændrer irrelevante indstillinger.

Hold Wiki.js eksplicit, mens Dockup håndterer routing

Routing, certificates, udskiftning af services og tilknyttet storage er fornuftige mål for automation. Dockup håndterer dette for Wiki.js og kan provisionere den tilknyttede managed database eller forbinde til services på kundens egen server.

Det, Dockup ikke skal opfinde, er Wiki.js' trust policy. Efter deployment skal du konfigurere site-URL'en, efter at servicen er routet gennem HTTPS, håndhæve denne grænse — fjern offentlig adgang til opsætningen, begræns administrationen, og giv wikidatabasen sine egne credentials — og verificere resultatet af dette scenarie: gennemfør opsætningen, opret og rediger en side, upload medier, søg efter dem, og gennemgå versionshistorikken efter en genstart. Resultatet er infrastruktur med ét klik og en applikationsspecifik acceptance-test.

Ofte stillede spørgsmål

Hvad skal Wiki.js bruge til en production deployment?

Rout Wiki.js-containeren på port 3000 gennem én HTTPS-origin. Det understøttende netværkskrav er en tilgængelig Postgres-, MySQL-, MariaDB-, MSSQL- eller SQLite-database. Kald ikke Wiki.js klar, før du kan gennemføre opsætningen, oprette og redigere en side, uploade medier, søge efter dem og gennemgå versionshistorikken efter en genstart.

Hvilke Wiki.js-data hører hjemme i en backup?

Standard-Wiki.js-imaget har ikke noget påkrævet application-data mount. Bevar deployment-konfigurationen, og tag separat backup af al tilknyttet state. Recovery er godkendt, når sider, historik, brugere, grupper, medier og navigation kommer tilbage, og en kendt side fortsat kan findes i søgningen.

Kræver Wiki.js HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Wiki.js-origin, og behold port 3000 på den interne route. Anvend Wiki.js-indstillingen korrekt: Konfigurér site-URL'en, efter at servicen er routet gennem HTTPS. For Wiki.js beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet klientadfærd, der afhænger af origin.

Hvordan bør en Wiki.js-upgrade testes?

Gendan den aktuelle Wiki.js-state til en isoleret deployment, anvend kandidatversionen, og gentag dens acceptance transaction. Vær særligt opmærksom, fordi Wiki.js-databasemigrationer og authentication modules bør testes trinvist, før du skifter til en anden release-linje. Behold det tidligere Wiki.js-image, indtil grænsen for datamigration og rollback er forstået.