Så självhostar du DokuWiki 2026: fillagring, ACL:er och säkerhetskopior
En praktisk guide till self-hosting av DokuWiki med Docker, portar, persistent data, TLS, säkerhet, säkerhetskopior och problemen som hindrar produktionsdrift. Med kontroller.
Se DokuWiki som ett mindre system, inte som en Docker-avbild. Målet för användaren är tydligt: en filbaserad wiki som inte behöver någon databas. Driftsättningen är bara acceptabel när du kan byta ut installationsuppgifterna, redigera en sida, ladda upp media, tillämpa en ACL, visa en revision och återställa en äldre version.
Den skillnaden fångar det fel som driftansvariga stöter på efter lokal testning: filägarskap hindrar sidsparningar trots att gränssnittet laddas. Den gör också planen för säkerhetskopiering och uppgraderingar tillräckligt specifik för att kunna testas.
Portar, processer och privata tjänster
Börja med DokuWikis nätverksutrymme: dess webblyssnare använder port 80, inte en host-port som kopierats från en laptopguide. Det lokala runtime-kravet är en persistent config-volym som innehåller sidor, media och ACL:er. Dokumentera förväntad kapacitet, ägarskap och felbeteende i stället för att lämna detta som en standardinställning i avbilden.
När kravet är uppfyllt kör du hela scenariot — byt ut installationsuppgifterna, redigera en sida, ladda upp media, tillämpa en ACL, visa en revision och återställ en äldre version. Logga mätvärden för filsystemmetadata, mediavolymen, sökindexeringen och PHP-workers. Dessa belägg blir den första kända fungerande arkitekturen och gör senare flyttar mellan Dockup compute och en ansluten server testbara.
Felövningar för DokuWiki
En container med grön status är nödvändig men inte tillräcklig. Tjänstens indikator är att scenariot ”byt ut installationsuppgifterna, redigera en sida, ladda upp media, tillämpa en ACL, visa en revision och återställ en äldre version” slutförs utan fel. De sannolika belastningssignalerna är filsystemmetadata, mediavolymen, sökindexeringen och PHP-workers.
Ändringskontroll är viktig eftersom plugins och templates kan släpa efter DokuWiki-releaser, även om vanliga sidfiler fortfarande är läsbara. Bevara den gamla avbilden, testa migreringar på kopierad state och dokumentera om rollback stöds efter att schemat har ändrats. Om filägarskap hindrar sidsparningar trots att gränssnittet laddas ska du diagnostisera den första gräns där miljön skiljer sig från den fungerande miljön.
Dokumentera en känd fungerande DokuWiki-driftsättning
En releasekandidat för DokuWiki förtjänar trafik genom att slutföra ett fast scenario: byt ut installationsuppgifterna, redigera en sida, ladda upp media, tillämpa en ACL, visa en revision och återställ en äldre version. Dokumentera image digest, effektiv icke-hemlig konfiguration, publik origin och tidsstämplar för scenariot. Testdatan ska kunna raderas, men vara tillräckligt realistisk för att testa samma flöde som användarna.
Kör detta efter att runtime-miljön har ersatts och bygg sedan om tjänsten från sidor, media, metadata, användare, ACL:er och plugins. Återställningen är godkänd när sidor, revisioner, media, användare, ACL:er och plugins kommer tillbaka och den skyddade sidan fortfarande är skyddad. Jämför resursmätningar för filsystemmetadata, mediavolymen, sökindexeringen och PHP-workers med den tidigare releasen och utred betydande avvikelser innan lansering.
Testa slutligen detta kontrollerade fel: skicka ofarlig input nära resurs- eller formatgränsen som hör till detta villkor: filägarskap hindrar sidsparningar trots att gränssnittet laddas. Kontrollera att DokuWiki förklarar felet, inte skadar befintlig state och återhämtar sig när det giltiga tillståndet återkommer. Spara ett avidentifierat loggutdrag och återställningstiden. Tillsammans täcker dessa kontroller beteende, beständighet och driftbarhet – inte bara att processen är igång.
Kör den första produktionsliknande instansen
Använd ett kommando som visar alla viktiga val. Den här baslinjen binder DokuWiki till hostens loopback-adress, lägger till de kända datamountsen och tillhandahåller den första obligatoriska inställningen. Bekräfta det lokala kravet innan exponering: en persistent config-volym som innehåller sidor, media och ACL:er.
docker run -d \
--name dokuwiki \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v dokuwiki-data:/config \
lscr.io/linuxserver/dokuwiki:latest
Ersätt flytande tags med en testad version eller digest. Efter starten granskar du docker logs --tail 200 dokuwiki och bekräftar att processen lyssnar på port 80. Kör sedan DokuWikis acceptanstest. Ett svar från root-sidan kan inte bevisa att hela scenariot fungerar: byt ut installationsuppgifterna, redigera en sida, ladda upp media, tillämpa en ACL, visa en revision och återställ en äldre version.
Volymer är bara det första återställningslagret
För DokuWiki börjar säkerheten vid omdriftsättning med sidor, media, metadata, användare, ACL:er och plugins. Montera /config före bootstrap, skriv ofarlig exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är persistent. Testa sökvägen genom att ersätta containern medan ofarlig exempeldata finns kvar. Då upptäcker du mountningar som pekar en katalog för högt eller lågt.
Testa därefter disaster recovery på en tom host. Använd en applikationskonsistent databasexport där det behövs och verifiera att sidor, revisioner, media, användare, ACL:er och plugins kommer tillbaka och att den skyddade sidan fortfarande är skyddad. Guiden om databasbackup som har återställningstestats ger ett starkare mål än att bara kontrollera att en arkivfil skapades.
Ge DokuWiki en kanonisk adress
TLS-utfärdande är bara halva DokuWiki-rutten. Servera wikin över HTTPS och ange dess kanoniska bas-URL. Skicka trafik internt till port 80 och vidarebefordra det externa schemat så att genererade URL:er och säkra cookies förblir konsekventa.
Kör hela DokuWiki-scenariot från ett rent nätverk, inte bara root-sidan. Ett 502-fel eller ett certifikatfel kan isoleras med automatisk domän- och TLS-konfiguration. Om trafiken når processen och filägarskap hindrar sidsparningar trots att gränssnittet laddas, diagnostiserar du villkoret där det uppstår i stället för att lägga på fler redirects.
Stäng tillfällig åtkomst till installationen
Gör en threat model av den åtgärd DokuWiki utför, inte bara av dess login-formulär. Det stora riskfyllda misstaget här är att lämna installations- eller registreringsinställningar öppna. Implementera följande gräns: ta bort åtkomst till installationen, granska registreringen och bevara ACL-filer tillsammans med sidinnehållet.
DokuWiki har ingen obligatorisk bootstrap-hemlighet i denna baslinje. Skydda i stället det faktiska administratörskontot eller upstream-autentiseringen. Lös inte ett behörighetsfel genom att köra containern som root eller genom att montera hosten brett. Resursgränser hör också till säkerhetsdesignen när filsystemmetadata, mediavolymen, sökindexeringen och PHP-workers kan triggas av användare.
Använd Dockup för plattformslagret
En Dockup-template bör definiera avbilden, port 80, mountningar, health timing, domän, TLS och leverans av secrets. Dockup ska bevara DokuWikis runtime-inställningar medan driftansvarig bekräftar det lokala kravet: en persistent config-volym som innehåller sidor, media och ACL:er. Samma driftsättning kan riktas mot Dockup-servrar eller kundansluten kapacitet.
När rutten är live tillämpar du den publika inställningen och försöker byta ut installationsuppgifterna, redigera en sida, ladda upp media, tillämpa en ACL, visa en revision och återställa en äldre version. Säkerhetskopiera sidor, media, metadata, användare, ACL:er och plugins och behåll återställningstestet i driftplanen. Detta är DokuWikis ansvar som fortfarande är synligt efter att infrastrukturen har provisionerats.
Vanliga frågor
Vad behöver DokuWiki för en produktionsdriftsättning?
Routa DokuWiki-containern på port 80 via en enda HTTPS-origin. Det lokala runtime-kravet är en persistent config-volym som innehåller sidor, media och ACL:er. Förklara inte DokuWiki som redo förrän du kan byta ut installationsuppgifterna, redigera en sida, ladda upp media, tillämpa en ACL, visa en revision och återställa en äldre version.
Vilken DokuWiki-data ska ingå i en säkerhetskopia?
Gör /config persistent och inkludera sidor, media, metadata, användare, ACL:er och plugins i samma återställningsmanifest. En ren DokuWiki-återställning är godkänd först när sidor, revisioner, media, användare, ACL:er och plugins kommer tillbaka och den skyddade sidan fortfarande är skyddad.
Kräver DokuWiki HTTPS bakom en reverse proxy?
Använd HTTPS för den publika DokuWiki-originen och behåll port 80 i den interna rutten. Tillämpa DokuWiki-inställningen korrekt: servera wikin över HTTPS och ange dess kanoniska bas-URL. För DokuWiki skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under överföringen och håller origin-känsligt klientbeteende konsekvent.
Hur bör en DokuWiki-uppgradering testas?
Återställ aktuell DokuWiki-state i en isolerad driftsättning, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom plugins och templates kan släpa efter DokuWiki-releaser, även om vanliga sidfiler fortfarande är läsbara. Behåll den tidigare DokuWiki-avbilden tills gränsen för datamigrering och rollback är klarlagd.