2026'da Wiki.js Kendi Sunucunda Nasıl Barındırılır: Veritabanı Kurulumu, TLS ve Geri Yükleme Testleri

Wiki.js kurulum notlarının çoğu ilk sayfa yüklemesinde sona erer. Bu çok erken bir noktadır: container içinde DB_HOST değeri localhost olabilir veya TLS proxy header'ları eksik olabilir. Kullanışlı bir production testi daha kapsamlıdır — kurulumu tamamlayın, bir sayfa oluşturup düzenleyin, medya yükleyin, sayfayı arayın ve yeniden başlatmanın ardından sürüm geçmişini inceleyin.

Wiki.js'in rolü açıktır: sürümlemeli Markdown wiki ve modern bir editor. Operasyonel kapsamı web process'inden daha fazlasını içerir; bu nedenle gerçek veriler gelmeden önce dependency'lerin, saklanan state'in ve public route'un tamamı açıkça tanımlanmalıdır.

Wiki.js runtime sınırını çizin

Sorumlu bir Wiki.js topology'sinin en küçük hâli, 3000 portunda bir private listener, bir ingress route ve belgelenmiş bir state sınırı içerir. Wiki.js'in network contract'ı, erişilebilir bir Postgres, MySQL, MariaDB, MSSQL veya SQLite veritabanıdır. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve Wiki.js'e kapsamı sınırlandırılmış bir service credential verin.

Temiz bir client'tan kurulumu tamamlamasını, bir sayfa oluşturup düzenlemesini, medya yüklemesini, sayfayı aramasını ve yeniden başlatmanın ardından sürüm geçmişini incelemesini isteyerek topology'yi doğrulayın. Çalışırken veritabanı yanıt süresini, search indexing'i, medya depolamasını ve authentication-provider latency'yi izleyin. Sonuç, bir sonraki iyileştirmenin rastgele container boyutlandırmasını teşvik etmek yerine memory, storage, networking veya ayrı bir worker katmanında mı yapılması gerektiğini gösterir.

Wiki.js geri yüklemesini launch öncesinde tasarlayın

Standart Wiki.js image'ında writable application state beklenmez. Boş bir container filesystem'ını yedeklemek yerine database'i ve tüm local uploads ile custom assets'ları, pinned digest'i ve gözden geçirilmiş route configuration'ını koruyun.

Wiki.js'i başka bir host üzerinde sıfırdan oluşturun ve sayfaların, geçmişin, kullanıcıların, grupların, medyanın ve navigation'ın geri geldiğini; bilinen bir sayfanın arama sonuçlarında kalmaya devam ettiğini doğrulayın. Ayrı bir database, room server veya authentication layer eklenirse bu component'e kendi açık recovery owner'ını atayın. Git-to-production guide, yeniden üretilebilir bir artifact'in container backup'ın yerini nasıl aldığını gösterir.

Rebuild command'ını ve beklenen output testini release ile birlikte kaydedin. Stateless recovery planı, güvenilir girdilerden davranışı yeniden üreterek başarılı olur; opaque bir running container'ın kopyalanmasına bağlı olmamalıdır.

Wiki.js trust boundary'sini seçin

Güvenli bir Wiki.js deployment'ı authority'yi azaltarak başlar. İlk administrator oluşturulduktan sonra setup screen'ini açık bırakmayın; bunun yerine setup'a public access'i kaldırın, administration'ı kısıtlayın ve wiki database'i için ayrı credentials kullanın.

DB_PASS'i Wiki.js'teki rolüne uygun şekilde ele alın: hassas değerleri Git dışında tutun, rotation etkilerini belgeleyin ve production'da hiçbir zaman public bir example kullanmayın. Administrative route'ları kısıtlayın, dependency'ler için private DNS kullanın ve tüm bind mount'ları gözden geçirin. Log'lar merkezi olarak gönderildiğinde, server'dan çıkmadan önce secret'ları ve private content'i filtreleyin.

Gerçek Wiki.js verileri gelmeden önce neler geçmeli?

Wiki.js için production gate, deployment'ı oluşturmamış biri tarafından çalıştırılabilmelidir. Bu kişiye pinned version'ı, hassas olmayan bir test account'unu ve şu görevi verin: kurulumu tamamla, bir sayfa oluşturup düzenle, medya yükle, sayfayı ara ve yeniden başlatmanın ardından sürüm geçmişini incele. Talimatlar belgelenmemiş shell access gerektiriyorsa service henüz operasyonel olarak hazır değildir.

Yalnızca container'ı değiştirerek gate'i tekrarlayın. Ardından database'i ve tüm local uploads ile custom assets'ları boş infrastructure'a geri yükleyin; sayfaların, geçmişin, kullanıcıların, grupların, medyanın ve navigation'ın geri geldiğini ve bilinen bir sayfanın aranmaya devam ettiğini kanıtlayın. Her iki başarılı çalıştırma sırasında database response time'ı, search indexing'i, media storage'ı ve authentication-provider latency'yi ölçün; beklenmeyen farklar çoğu zaman eksik bir cache, index, worker veya data mount olduğunu ortaya çıkarır.

Bir failure drill ekleyin: test identity'nin erişebildiği bir Postgres, MySQL, MariaDB, MSSQL veya SQLite database'ine erişimini geçici olarak engelleyin. Wiki.js yararlı bir error üretmeli, mevcut state'i korumalı ve geçerli koşul geri geldiğinde düzelmelidir. Secret'ları redakte ederek timestamp'leri ve ilgili log satırlarını kaydedin. Bu kanıt, sonraki image veya configuration değişikliği için referans olur.

Hareketli parçaları gizlemeden Wiki.js'i başlatın

İlk Wiki.js invocation'ını pull request'te incelenebilecek kadar reproducible tutun.

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

Gerçek veriler oluştuktan sonra latest tag'ine güvenmeyin. Çalışan digest'i, container user'ını ve mount ownership'ini kaydedin. Application log'unu eksiksiz bir test boyunca takip edin — kurulumu tamamlayın, bir sayfa oluşturup düzenleyin, medya yükleyin, sayfayı arayın ve yeniden başlatmanın ardından sürüm geçmişini inceleyin — ve route'u production traffic'in arkasına almadan önce tüm migration'ları not edin.

Internal ve external URL'leri birbirinden ayırın

External Wiki.js URL'sini redeploy'lar arasında korunacak bir configuration olarak ele alın. Service'i HTTPS üzerinden route ettikten sonra önce site URL'sini configure edin; ardından hostname'i, original host ve scheme bilgilerini koruyarak 3000 portuna yönlendirin.

deployment reachability checklist, request'lerin container'a girdiğini kanıtlayabilir. Bundan sonraki bilinen failure — container içinde DB_HOST değerinin localhost olması veya TLS proxy header'larının eksik olması — certificate automation'da değil, Wiki.js'te, onun state'inde veya workload'unda araştırılmalıdır.

Yalnızca container'ı değil, workload'u izleyin

Dashboard'ları database response time, search indexing, media storage ve authentication-provider latency etrafında oluşturun. Workload context'i olmayan bir CPU grafiği Wiki.js'in neden yavaş olduğunu açıklayamaz. Zararsız test verileri kullanarak kurulumu tamamlamayı, bir sayfa oluşturup düzenlemeyi, medya yüklemeyi, sayfayı aramayı ve yeniden başlatmanın ardından sürüm geçmişini incelemeyi deneyen synthetic veya scheduled bir check ekleyin.

Upgrade öncesinde uygulamaya özgü şu riski hesaba katın: Wiki.js database migration'ları ve authentication module'leri başka bir release line'a geçmeden önce aşamalı olarak test edilmelidir. Yakın tarihli bir backup'ı isolated bir deployment'a restore edin, migration'ları orada çalıştırın ve davranışı karşılaştırın. Container içinde DB_HOST localhost ise veya TLS proxy header'ları eksikse, ilgisiz ayarlara dokunmadan önce ilgili boundary'yi — public origin, storage veya dependency — inceleyin.

Dockup routing'i yönetirken Wiki.js'i açıkça yapılandırın

Routing, certificate'lar, service replacement ve attached storage makul automation hedefleridir. Dockup bunları Wiki.js için yönetebilir; ayrıca ilgili managed database'i provision edebilir veya müşterinin kendi server'ındaki service'lere bağlanabilir.

Ancak Wiki.js trust policy'sini kendisi uydurmamalıdır. Deployment sonrasında service'i HTTPS üzerinden route ettikten sonra site URL'sini configure edin, şu boundary'yi uygulayın — setup'a public access'i kaldırın, administration'ı kısıtlayın ve wiki database'i için ayrı credentials kullanın — ve şu senaryonun sonucunu doğrulayın: kurulumu tamamlayın, bir sayfa oluşturup düzenleyin, medya yükleyin, sayfayı arayın ve yeniden başlatmanın ardından sürüm geçmişini inceleyin. Sonuç, application-specific acceptance test'i olan one-click infrastructure'dır.

Sık sorulan sorular

Production deployment için Wiki.js'in nelere ihtiyacı var?

Wiki.js container'ını 3000 portunda tek bir HTTPS origin üzerinden route edin. Supporting network requirement, erişilebilir bir Postgres, MySQL, MariaDB, MSSQL veya SQLite database'idir. Kurulumu tamamlayamıyor, bir sayfa oluşturup düzenleyemiyor, medya yükleyemiyor, sayfayı arayamıyor veya yeniden başlatmanın ardından sürüm geçmişini inceleyemiyorsanız Wiki.js'i hazır kabul etmeyin.

Hangi Wiki.js verileri backup'a dahil edilmelidir?

Standart Wiki.js image'ında zorunlu bir application-data mount'ı yoktur. Deployment configuration'ını koruyun ve bağlı state'i ayrı olarak yedekleyin; sayfalar, geçmiş, kullanıcılar, gruplar, medya ve navigation geri geldiğinde ve bilinen bir sayfa aranmaya devam ettiğinde recovery başarılıdır.

Wiki.js reverse proxy arkasında HTTPS gerektirir mi?

Public Wiki.js origin'i için HTTPS kullanın ve 3000 portunu internal route'ta tutun. Wiki.js ayarını doğru uygulayın: service'i HTTPS üzerinden route ettikten sonra site URL'sini configure edin. Wiki.js için HTTPS, credentials veya user content'in transit hâlinde korunmasını sağlar ve origin'e duyarlı client davranışını tutarlı kılar.

Wiki.js upgrade'i nasıl test edilmelidir?

Güncel Wiki.js state'ini isolated bir deployment'a restore edin, aday version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Wiki.js database migration'ları ve authentication module'leri başka bir release line'a geçmeden önce aşamalı olarak test edilmesi gerektiğinden bu noktaya özellikle dikkat edin. Data-migration ve rollback boundary'leri anlaşılana kadar önceki Wiki.js image'ını saklayın.