2026'da Vikunja'yı Self-Host Etme: Genel URL, Veritabanı ve Dosya Depolama

Vikunja'yı daha önce self-host etmeyi denediyseniz şu can sıkıcı duruma muhtemelen aşinasınızdır: UI açılır, ancak API genel URL'si yanlıştır veya yüklenen dosyalar bir volume üzerinde değildir. Container'ı yeniden oluşturmak, URL'ler, state ve dependency'ler arasındaki uyumsuzluğu nadiren düzeltir.

Bu walkthrough'da tek bir somut tamamlanma kriteri kullanacağız: bir project, task, attachment ve reminder oluşturmak, task'ı bir board üzerinde taşımak ve ilgili calendar event ile notification'ı doğrulamak. Her configuration seçimi, yeşil container rozeti yerine bu kritere göre değerlendirilecektir.

Vikunja neleri gerektirir?

Vikunja'nın etrafına üç sınır çizin: port 3456'ya ingress, kalıcı state ve supporting requirement'lar. Container değiştirilebilir, ancak diğer ikisinin açıkça belirlenmiş sahipleri olmalıdır. Vikunja'nın network contract'ı production ekipleri için Postgres veya MySQL ve SMTP'dir. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve Vikunja'ya kapsamı sınırlandırılmış bir service credential verin.

Temiz bir client bir project, task, attachment ve reminder oluşturabildiğinde, task'ı bir board üzerinde taşıyabildiğinde ve ilgili calendar event ile notification'ı doğrulayabildiğinde diagram tamamlanmış sayılır. Yalnızca küçük API process'ine odaklanmak yerine attachment trafiği, database sorguları, background job'lar ve outbound email için timing ve resource verilerini kaydedin. Transaction başarısız olursa, belgelerde açıklandığı gibi davranmayan ilk sınır; routing, local capacity veya supporting service alanlarından hangisini incelemeniz gerektiğini gösterir.

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

İlk gerçek record oluşturulmadan önce state'i listeleyin: database, yüklenen dosyalar ve configuration. Bootstrap işleminden önce /app/vikunja/files'i mount edin, zararsız örnek veriler yazın ve bu path'in gerçekten persistent olduğunu kanıtlamak için container'ı değiştirin. Zararsız veriler yazarak, Vikunja'yı değiştirerek ve verileri yeniden okuyarak mount'u doğrulayın.

Snapshot'lar hızlı rollback için değerlidir, ancak host veya volume ortadan kaybolduğunda bağımsız bir backup gerekir. Pinned image ile boş bir environment'a restore işlemi yapın ve project'lerin, task history'nin, attachment'ların, reminder'ların ve user'ların geri geldiğini; ayrıca schedule edilmiş bir notification'ın hâlâ gönderildiğini doğrulayın. Bu iki recovery mekanizmasını birbirinden ayrı tutmak için persistent volume'leri ve snapshot'ları kullanın.

Vikunja'nın değerli kısmını koruyun

İlk login işleminden sonra anonim bir ziyaretçinin, sıradan bir user'ın ve administrator'ın neler yapabildiğini ayrı ayrı inceleyin. Kaçınılması gereken Vikunja failure durumu, değiştirilmemiş bir JWT secret kullanmak veya registration'ı yanlışlıkla açık bırakmaktır. Hedeflenen policy; sabit bir JWT secret kullanmak, enrollment sona erdiğinde registration'ı kapatmak ve sıradan member'ları project administrator'larından ayırmaktır.

VIKUNJA_SERVICE_JWTSECRET'i uzun ve rastgele bir değer olarak oluşturun; bunu rotate etmek normalde session'ları veya token'ları geçersiz kılar. Bu nedenle işlemi bir encryption migration gibi ele almak yerine user etkisini planlayın. Dependency account'larını human account'larından ayrı tutun, mümkün olduğunda kullanılmayan egress'i engelleyin ve yalnızca küçük API process'ini değil, attachment trafiği, database sorguları, background job'lar ve outbound email tarafından etkilenebilecek iş yükünü de sınırlandırın.

Vikunja smoke test'ini bir release kontrolüne dönüştürün

Vikunja için bir release candidate, sabit bir senaryoyu tamamlayarak trafik almaya hak kazanır: bir project, task, attachment ve reminder oluşturmak, task'ı bir board üzerinde taşımak ve ilgili calendar event ile notification'ı doğrulamak. Bu senaryo için image digest'ini, secret içermeyen etkin configuration'ı, public origin'i ve timestamp'leri kaydedin. Test verileri disposable olmalı, ancak user'ların izlediği path'in aynısını çalıştıracak kadar gerçekçi olmalıdır.

Runtime'ı değiştirdikten sonra bu testi çalıştırın; ardından service'i database, yüklenen dosyalar ve configuration'dan yeniden build edin. Recovery; project'ler, task history, attachment'lar, reminder'lar ve user'lar geri geldiğinde ve schedule edilmiş bir notification hâlâ gönderildiğinde başarılıdır. Önceki release ile karşılaştırmak için attachment trafiği, database sorguları, background job'lar ve outbound email ölçümlerini yalnızca küçük API process'iyle değil, önceki release ile karşılaştırın ve promotion öncesinde anlamlı sapmaları inceleyin.

Son olarak şu kontrollü failure durumunu uygulayın: test identity'sinin production ekipleri için Postgres veya MySQL ve SMTP erişimini geçici olarak engelleyin. Vikunja'nın failure'ı açıkladığını, mevcut state'e zarar vermediğini ve geçerli koşul geri döndüğünde çalışmaya devam ettiğini doğrulayın. Redact edilmiş bir log excerpt'i ve recovery time'ı kaydedin. Bu kontroller birlikte yalnızca process uptime'ını değil, behavior, durability ve operability'yi kapsar.

Değiştirilebilir bir Vikunja container'ı oluşturun

Aşağıdaki command, her external service'i provision ediyormuş gibi davranmadan container sınırını görünür kılar.

docker run -d \
  --name vikunja \
  --restart unless-stopped \
  -p 127.0.0.1:3456:3456 \
  -v vikunja-data:/app/vikunja/files \
  -e VIKUNJA_SERVICE_JWTSECRET=replace-with-a-long-random-value \
  vikunja/vikunja:latest

Ingress'i açmadan önce resolved environment'ı, mount'ları ve listener'ı inceleyin. Postgres veya MySQL ile production ekipleri için SMTP'ye ilişkin gözden geçirilmiş connection setting'lerini ekleyin; private service'ler için private name'ler kullanın. Başarılı bir launch, docker ps çıktısında Up görülmesiyle değil; bir project, task, attachment ve reminder oluşturabildiğinizde, task'ı bir board üzerinde taşıyabildiğinizde ve ilgili calendar event ile notification'ı doğrulayabildiğinizde tamamlanır.

HTTPS konusunda Vikunja'yı yanıltmayacak şekilde route edin

Vikunja için temporary ve permanent public origin'leri birlikte kullanmaktan kaçının. Bunun yerine VIKUNJA_SERVICE_PUBLICURL'i tam HTTPS origin'ine ayarlayın, seçilen DNS name'i platform route'una yönlendirin ve proxy'yi yalnızca port 3456'ya bağlayın.

Bu işlemi host'un dışından test edin: bir project, task, attachment ve reminder oluşturun, task'ı bir board üzerinde taşıyın ve ilgili calendar event ile notification'ı doğrulayın. Ingress başarısız olursa 502 troubleshooting rehberi port ve listener hatalarını ele alır. Vikunja request'i alıyor, ancak API genel URL'si yanlış veya yüklenen dosyalar bir volume üzerinde değilse, kanıtlar artık proxy'nin ötesine işaret eder.

Sağlıklı görünen bir Vikunja'yı teşhis edin

Vikunja için process yerine bir transaction'ı izleyin: bir project, task, attachment ve reminder oluşturun, task'ı bir board üzerinde taşıyın ve ilgili calendar event ile notification'ı doğrulayın. Bir alert'in kısıtlanan component'i belirleyebilmesi için latency ve error rate'i yalnızca küçük API process'iyle değil, attachment trafiği, database sorguları, background job'lar ve outbound email ile birlikte değerlendirin.

Upgrade provası, database migration'larının ve frontend/API compatibility'sinin Vikunja version'ını değiştirmeden önce test edilmesini kapsamalıdır. Production replacement işleminden önce restore, migrate ve transaction adımlarını çalıştırın. API genel URL'si yanlışsa veya yüklenen dosyalar bir volume üzerinde değilse startup'ı yeşile çevirmek için verileri silmeyin; version, variable'lar, mount'lar ve dependency erişilebilirliğini bu sırayla karşılaştırın.

Sınırlarını kaybetmeden Vikunja'yı Dockup üzerinde deploy edin

Dockup, değiştirilebilir platform parçalarını üstlenebilir: trafiği port 3456'ya yönlendirebilir, domain ve certificate sağlayabilir, secret'ları inject edebilir, persistent storage bağlayabilir ve Vikunja'yı managed veya private olarak bağlanmış service'lere connect edebilir. Bunu Dockup infrastructure'ı üzerinde veya bağladığınız bir server'da gerçekleştirebilir.

Vikunja acceptance çalışmaları açıkça sürdürülmelidir. One-click deployment sonrasında VIKUNJA_SERVICE_PUBLICURL'i tam HTTPS origin'ine ayarlayın, Postgres veya MySQL ile production ekipleri için SMTP'yi bağlayıp test edin ve şu senaryoyu çalıştırın: bir project, task, attachment ve reminder oluşturun, task'ı bir board üzerinde taşıyın ve ilgili calendar event ile notification'ı doğrulayın. Bu ayrım bilinçlidir: Dockup, application role'lerinin, provider credential'larının veya restore policy'nin kendiliğinden seçildiği izlenimini vermeden tekrarlayan infrastructure kurulumunu ortadan kaldırır.

Sık sorulan sorular

Production deployment için Vikunja'nın neye ihtiyacı vardır?

Vikunja container'ını port 3456 üzerinden tek bir HTTPS origin'ine route edin. Supporting network requirement, production ekipleri için Postgres veya MySQL ve SMTP'dir. Bir project, task, attachment ve reminder oluşturamadığınız, task'ı bir board üzerinde taşıyamadığınız ve ilgili calendar event ile notification'ı doğrulayamadığınız sürece Vikunja'yı hazır kabul etmeyin.

Vikunja'nın hangi verileri backup'a dahil edilmelidir?

/app/vikunja/files'i persistent hale getirin ve database, yüklenen dosyalar ile configuration'ı aynı recovery manifest'ine dahil edin. Temiz bir Vikunja restore işlemi ancak project'ler, task history, attachment'lar, reminder'lar ve user'lar geri geldiğinde ve schedule edilmiş bir notification hâlâ gönderildiğinde başarılıdır.

Reverse proxy arkasında Vikunja için HTTPS gerekir mi?

Public Vikunja origin'i için HTTPS kullanın ve port 3456'yı internal route üzerinde tutun. Vikunja ayarını doğru uygulayın: VIKUNJA_SERVICE_PUBLICURL'i tam HTTPS origin'ine ayarlayın. Vikunja için HTTPS, credentials veya user content'in transit sırasında korunmasını ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

Vikunja upgrade'i nasıl test edilmelidir?

Mevcut Vikunja state'ini isolated bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Database migration'larının ve frontend/API compatibility'sinin Vikunja version'ını değiştirmeden önce test edilmesi gerektiğinden özellikle bu noktaya dikkat edin. Data migration ve rollback sınırları anlaşılana kadar önceki Vikunja image'ını saklayın.