2026'da Kanboard'u Kendi Sunucunuzda Barındırma: SQLite, Eklentiler ve Güvenli Güncellemeler

Başarısız bir Kanboard deployment'ı her zaman çökmeyebilir. Bağlanan data directory yanlış owner'a sahip olduğu için SQLite'a yazılamazken login sayfası sunulmaya devam edebilir. Bunun yerine uçtan uca bir kontrolle başlayın: varsayılan login'i değiştirin, bir project ve task oluşturun, task'ı kolonlar arasında taşıyın, bir dosya yükleyin ve kurulu bir plugin'i çalıştırın.

Bu kontrol, Kanboard'un kataloglanmış amacıyla örtüşür: SQLite tarafından desteklenen minimal bir kanban board. Ayrıca eksik dependency'leri, hatalı proxy varsayımlarını ve geçici verileri bir uptime probe'unun tespit edebileceğinden daha erken ortaya çıkarır.

Kanboard'u dependency'lerinden ayırın

Sorumlu bir Kanboard topology'sinin en küçük hâlinde 80 üzerinde tek bir private listener, bir ingress route ve belgelenmiş bir state boundary bulunur. Local runtime requirement, yazılabilir bir data volume ve isteğe bağlı SMTP'dir. Kanboard'u host'lar arasında taşırken davranışın sessizce değişmemesi için lifecycle'ını açıkça yönetin.

Temiz bir client'a varsayılan login'i değiştirtip bir project ve task oluşturun, task'ı kolonlar arasında taşıtın, bir dosya yükletin ve kurulu bir plugin'i çalıştırın; topology'yi bu şekilde doğrulayın. Çalışırken SQLite locking'i, attachment volume'ünü, background action'ları ve eş zamanlı kullanıcılar altındaki plugin davranışını izleyin. Sonuç, bir sonraki iyileştirmenin rastgele container boyutlandırmasını teşvik etmek yerine memory, storage, networking veya ayrı bir worker tarafında mı yapılması gerektiğini gösterir.

Domain'ler, proxy header'ları ve 80 portu

TLS issuance, Kanboard route'unun yalnızca yarısıdır. Board'u HTTPS üzerinden sunun ve plugin'lerin ihtiyaç duyması hâlinde application URL'i ayarlayın. Trafiği dahili olarak 80'e gönderin ve oluşturulan URL'lerin ve secure cookie'lerin tutarlı kalması için external scheme'i forward edin.

Kanboard senaryosunun tamamını yalnızca root page'de değil, temiz bir network'ten test edin. Bir 502 veya certificate failure, automatic domain and TLS setup kullanılarak izole edilebilir. Trafik process'e ulaşıyor ancak bağlı data directory yanlış owner'a sahip olduğu için SQLite yazamıyorsa, redirect'leri üst üste eklemek yerine bu durumu ortaya çıktığı yerde teşhis edin.

Kanboard startup'ını tekrarlanabilir hâle getirin

Production'a uygun bir launch kasıtlı olarak sıkıcıdır: named state, açıkça belirtilmiş port ve image içinde hiçbir secret bulunmaması.

docker run -d \
  --name kanboard \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v kanboard-data:/var/www/app/data \
  kanboard/kanboard:latest

Bu örnek, eksiksiz bir supporting stack'ten ziyade bir baseline'dır. Dış erişime açmadan önce local requirement'ı doğrulayın: yazılabilir bir data volume ve isteğe bağlı SMTP. Effective mount'ları ve listener'ı kontrol edin; ardından varsayılan login'i değiştirmeyi, bir project ve task oluşturmayı, task'ı kolonlar arasında taşımayı, bir dosya yüklemeyi ve kurulu bir plugin'i çalıştırmayı deneyin. Sonraki restart'tan önce çalışan image'ı pin'leyin.

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

Kanboard için bir process yerine transaction'ı izleyin: varsayılan login'i değiştirin, bir project ve task oluşturun, task'ı kolonlar arasında taşıyın, bir dosya yükleyin ve kurulu bir plugin'i çalıştırın. Alert'in hangi component'in kısıtlandığını göstermesi için transaction latency'sini ve error rate'ini SQLite locking, attachment volume, background action'lar ve eş zamanlı kullanıcılar altındaki plugin davranışıyla birlikte değerlendirin.

Upgrade rehearsal, database migration'larının ve plugin compatibility'nin Kanboard image update'inden önce snapshot alınmasını gerektirdiğini kapsamalıdır. Production replacement öncesinde restore edin, migration'ı uygulayın ve transaction'ı çalıştırın. Bağlı data directory yanlış owner'a sahip olduğu için SQLite yazamıyorsa startup'ı green hâle getirmek için verileri silmeyin; version, variables, mounts ve dependency reachability değerlerini bu sırayla karşılaştırın.

Kanboard deployment'ını uçtan uca kanıtlayın

Kanboard için production gate, deployment'ı oluşturmamış biri tarafından çalıştırılabilmelidir. Bu kişiye pin'lenmiş version'ı, hassas olmayan bir test account'u ve şu görevi verin: varsayılan login'i değiştirin, bir project ve task oluşturun, task'ı kolonlar arasında taşıyın, bir dosya yükleyin ve kurulu bir plugin'i çalıştırın. 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 SQLite database'i, yüklenen dosyaları, plugin'leri ve configuration'ı boş bir infrastructure'a restore edin; project'lerin, task history'nin, user'ların, attachment'ların ve plugin'lerin geri geldiğini ve restore edilen board'un yeni bir task kabul ettiğini kanıtlayın. Her iki başarılı çalıştırma sırasında eş zamanlı kullanıcılar altındaki SQLite locking'i, attachment volume'ünü, background action'ları ve plugin davranışını ölçün; beklenmeyen farklılıklar genellikle eksik bir cache, index, worker veya data mount ortaya çıkarır.

Bir failure drill ekleyin: bu boundary ile ilişkili resource veya format limitinin yakınında, zararsız bir input gönderin: bağlı data directory yanlış owner'a sahip olduğu için SQLite yazamıyor. Kanboard anlamlı bir error üretmeli, mevcut state'i korumalı ve geçerli koşul geri geldiğinde toparlanmalıdır. Secret'ları redakte ederek timestamp'leri ve ilgili log satırlarını kaydedin. Bu kanıt, bir sonraki image veya configuration değişikliği için referans olur.

Volume'ler yalnızca ilk recovery katmanıdır

Kanboard için bir recovery manifest oluşturun: SQLite database, yüklenen dosyalar, plugin'ler ve configuration. Bootstrap'ten önce /var/www/app/data mount'unu ekleyin, zararsız örnek veriler yazın ve bu path'in gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Ownership'i ve boş alanı şimdi kontrol edin; çünkü mount edilmiş ancak yazılamayan bir path, hiç persistence yokmuş gibi davranır.

Backup'ları çalışan server'dan ayrı bir failure domain'a alın. Kanboard'u pin'lenmiş image'ından yeniden oluşturun ve project'lerin, task history'nin, user'ların, attachment'ların ve plugin'lerin geri geldiğini ve restore edilen board'un yeni bir task kabul ettiğini doğrulayın. persistent-volume guide, bu çalışmayı snapshot ve retention policy'ye dönüştürmenize yardımcı olur.

Kanboard'un değerli kısmını koruyun

Güvenli bir Kanboard deployment'ı authority'yi azaltarak başlar. Varsayılan admin/admin credential'larını tutmaktan kaçının; bunun yerine admin/admin'i hemen kaldırın, project access'i kısıtlayın ve production verilerine erişim vermeden önce plugin'leri inceleyin.

Bu baseline'da Kanboard için zorunlu bir bootstrap secret yoktur; bunun yerine gerçek administrator account'unu veya upstream authentication'ı koruyun. Administrative route'ları kısıtlayın, dependency'ler için private DNS kullanın ve her bind mount'u inceleyin. Log'lar merkezi olarak gönderiliyorsa server'dan çıkmadan önce secret'ları ve private content'i filtreleyin.

Dockup, Kanboard için işleri nerede azaltır?

Bir Dockup template'i image'ı, 80 portunu, mount'ları, health timing'i, domain'i, TLS'i ve secret delivery'yi tanımlamalıdır. Operatör şu local requirement'ı doğrularken Dockup, Kanboard runtime settings'ini korumalıdır: yazılabilir bir data volume ve isteğe bağlı SMTP. Aynı deployment, Dockup server'larını veya customer-attached capacity'yi hedefleyebilir.

Route aktif olduktan sonra public setting'i uygulayın ve varsayılan login'i değiştirmeyi, bir project ve task oluşturmayı, task'ı kolonlar arasında taşımayı, bir dosya yüklemeyi ve kurulu bir plugin'i çalıştırmayı deneyin. SQLite database'i, yüklenen dosyaları, plugin'leri ve configuration'ı yedekleyin ve restore çalışmasını operating plan'a ekleyin; infrastructure provisioning sonrasında da görünür kalmaya devam eden Kanboard sorumlulukları bunlardır.

Sık sorulan sorular

Kanboard production deployment'ı için ne gerekir?

Kanboard container'ını tek bir HTTPS origin üzerinden 80 portuna yönlendirin. Local runtime requirement, yazılabilir bir data volume ve isteğe bağlı SMTP'dir. Varsayılan login'i değiştirebildiğiniz, bir project ve task oluşturabildiğiniz, task'ı kolonlar arasında taşıyabildiğiniz, bir dosya yükleyebildiğiniz ve kurulu bir plugin'i çalıştırabildiğinizden emin olmadan Kanboard'u hazır kabul etmeyin.

Hangi Kanboard verileri backup'a dahil edilmelidir?

/var/www/app/data'yı kalıcı hâle getirin ve SQLite database'i, yüklenen dosyaları, plugin'leri ve configuration'ı aynı recovery manifest'e dahil edin. Temiz bir Kanboard restore'u yalnızca project'ler, task history, user'lar, attachment'lar ve plugin'ler geri geldiğinde ve restore edilen board yeni bir task kabul ettiğinde başarılı sayılır.

Kanboard reverse proxy arkasında HTTPS gerektirir mi?

Public Kanboard origin için HTTPS kullanın ve dahili route'ta 80 portunu koruyun. Kanboard setting'ini doğru uygulayın: board'u HTTPS üzerinden sunun ve plugin'lerin ihtiyaç duyması hâlinde application URL'i ayarlayın. Kanboard için HTTPS, credentials veya user content'in aktarım sırasında korunmasını ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Kanboard upgrade'i nasıl test edilmelidir?

Mevcut Kanboard state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Database migration'larının ve plugin compatibility'nin Kanboard image update'inden önce snapshot alınmasını gerektirdiği için bu noktalara özellikle dikkat edin. Data migration ve rollback boundary'leri anlaşılana kadar önceki Kanboard image'ını saklayın.