Docker Compose ile Planka Kurulumu ve Yapılandırması

Planka self-hosting ile elde ettikleriniz

Planka'yı kendi sunucunuzda barındırmak, ekibinize Trello'dan aşina olduğunuz kart, liste ve etiket modeline sahip bir Kanban panosu sunar; üstelik kontrolü tamamen sizde olan bir VPS üzerinde çalışır. Sunucu maliyeti dışında herhangi bir kullanıcı başına ücretlendirme veya koltuk sınırı bulunmaz. Bu rehber, uygulamayı Docker Compose kullanarak, Traefik arkasında, veriler için Postgres ve yüklenen dosyalar için adlandırılmış bir volume ile dağıtır.

Hedef kitlemiz, Trello'nun ücretsiz planından ayrılan iki ila beş kişilik ekiplerdir. Hangi panoyu kullanacağınıza henüz karar vermediyseniz, önce self-hosted Trello alternatiflerinin karşılaştırması başlıklı yazıyı okuyun. Bu rehber, seçimin yapıldığını varsayar ve yalnızca kurulum sürecini kapsar.

Docker Engine ve Compose eklentisi yüklü bir VPS'e ve bu sunucuya işaret eden bir DNS A kaydına ihtiyacınız vardır. Ayrıca, ilgili sunucuda TLS (transport layer security) sonlandırması yapan bir Traefik örneğinin halihazırda çalışıyor olması gerekir. Eğer Traefik kurulu değilse, önce birden fazla Compose uygulaması önünde Traefik reverse proxy kurulumu rehberini uygulayın; aşağıdaki dosya yapısı yabancı geliyorsa VPS için Docker Compose temelleri konusuna göz atın.

Planka ne kadar VPS kaynağına ihtiyaç duyar?

Proje resmi bir donanım taban değeri yayınlamamıştır, bu nedenle okuduğunuz her sayıyı bir ölçümden ziyade bir başlangıç noktası olarak kabul edin. Barındırma sayfalarında tekrarlanan 2 vCPU ve 4 GB değeri, projenin ölçtüğü bir gereksinim değil, sağlayıcıların sunduğu güvenli bir varsayılandır. Beş kişinin kullandığı bir pano için bu oldukça cömert bir değerdir.

Çalışan süreçler oldukça küçüktür: API ve derlenmiş arayüzü sunan bir Node.js süreci ve verileri tutan bir Postgres süreci. Planka container'ı içerisinde, giden istekleri filtrelemek için üçüncü küçük bir proxy süreci çalışır. 1 vCPU ve 2 GB'lık bir plan, iki ila beş kişilik bir panoyu rahatlıkla taşır; boşta kalan belleğin büyük kısmı Postgres önbelleği olarak kullanılır.

Disk boyutunu bellekten önce belirleyin, çünkü büyüyen kısım ek dosyalardır. Bu paragrafa güvenmek yerine kendi instance'ınızı ölçün:

docker stats --no-stream
docker system df -v

İlk komut, container başına anlık bellek ve CPU kullanımını yazdırır. İkincisi ise her bir volume'ün ne kadar alan kapladığını gösterir. Her iki ölçümü de kurulum gününde değil, normal bir çalışma haftasının ardından alın; çünkü boş bir pano size ekibiniz hakkında hiçbir bilgi vermez.

Compose dosyasını oluşturun

Dizini oluşturun ve sahipliğini alın; böylece bu dosyaları hiçbir zaman sudo üzerinden düzenlemek zorunda kalmazsınız.

sudo mkdir -p /opt/planka
sudo chown "$USER":"$USER" /opt/planka
cd /opt/planka

Gizli verileri (secrets) Compose dosyasının yanındaki bir .env dosyasına oluşturun. Compose bu dosyayı otomatik olarak okur ve değerleri yerine yerleştirir.

umask 077
{
  printf 'SECRET_KEY=%s\n' "$(openssl rand -hex 64)"
  printf 'POSTGRES_PASSWORD=%s\n' "$(openssl rand -hex 24)"
  printf 'ADMIN_PASSWORD=%s\n' "$(openssl rand -hex 12)"
} > .env
chmod 600 .env

openssl rand -hex kullanımı kasıtlıdır. Bir onaltılık (hex) dizge yalnızca rakamları ve a'dan f'ye kadar olan harfleri içerir, bu nedenle içine yapıştırıldığı DATABASE_URL bağlantı dizgesini bozamaz. İçinde eğik çizgi veya "at" işareti bulunan bir base64 parola, yanlış bir ana makine adı (hostname) gibi görünen bir bağlantı hatasına yol açar ve bu size bir saate mal olur. Daha geniş kapsamlı yöntem gizli verileri Compose dosyasının dışında tutma bölümünde ele alınmıştır.

Şimdi docker-compose.yml. kanban.example.com ifadesini, göründüğü her iki yerde de kendi ana makine adınızla değiştirin.

services:
  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    restart: unless-stopped
    volumes:
      - planka-data:/app/data
    environment:
      - BASE_URL=https://kanban.example.com
      - DATABASE_URL=postgresql://planka:${POSTGRES_PASSWORD}@postgres/planka
      - SECRET_KEY=${SECRET_KEY}
      - TRUST_PROXY=true
      - DEFAULT_ADMIN_EMAIL=you@example.com
      - DEFAULT_ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - DEFAULT_ADMIN_NAME=Your Name
      - DEFAULT_ADMIN_USERNAME=admin
    networks:
      - proxy
      - internal
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=proxy"
      - "traefik.http.routers.planka.rule=Host(`kanban.example.com`)"
      - "traefik.http.routers.planka.entrypoints=websecure"
      - "traefik.http.routers.planka.tls.certresolver=default"
      - "traefik.http.services.planka.loadbalancer.server.port=1337"
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=planka
      - POSTGRES_USER=planka
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    networks:
      - internal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U planka -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  planka-data:
  db-data:

networks:
  proxy:
    external: true
  internal:

Bu dosyadaki dört karar açıklanmaya değerdir; çünkü insanlar bunları değiştirip sonra pişman olmaktadır.

• Planka servisinde ports: bloğu yoktur. Traefik, konteynere proxy ağı üzerinden ulaşır, bu nedenle 1337 numaralı port ana makinede hiçbir zaman dışarıya açılmaz (publish edilmez). Bu portu dışarıya açmak, herkesin proxy'nizi ve sertifikanızı baypas etmesine olanak tanır.
• loadbalancer.server.port=1337, konteyner içindeki portu belirtir. Planka 1337 numaralı portu dinler; yukarı akış (upstream) örneği ise yalnızca 3000 numaralı port üzerinden erişim sağlar çünkü portu ana makineye eşler. Burada bir ana makine eşlemesi yoktur, bu nedenle Traefik'e konteyner portunun bildirilmesi gerekir.
• condition: service_healthy, Postgres sağlık kontrolü (healthcheck) ile eşleşir. Bu olmadan Planka, veritabanı bağlantıları kabul etmeden önce başlar, ilk sorgusunda başarısız olur ve çıkar; bu da bir çökme döngüsü (crash loop) gibi görünür. Mekanizmalar Compose sağlık kontrolleri ve başlatma sıralaması bölümündedir.
• Veritabanı servisi kasıtlı olarak postgres şeklinde adlandırılmıştır. Planka 2, kendi giden isteklerini varsayılan engelleme listesi localhost,postgres olan dahili bir filtre üzerinden yönlendirir. Servisi yeniden adlandırırsanız, veritabanınızı sessizce bu listeden çıkarmış olursunuz.

Herhangi bir şeyi başlatmadan önce Compose'un gizli verilerinizi görüp göremediğini kontrol edin:

docker compose config | grep -E 'image:|BASE_URL|POSTGRES_USER'

Bu komut, .env değerleri halihazırda yerleştirilmiş olan dosyayı yazdırır. Boş bir değer, Compose'un .env dosyasını okumadığı anlamına gelir; bu durum genellikle komutu farklı bir dizinden çalıştırmanızdan kaynaklanır.

Yönetici bootstrap değişkenlerinin işlevi

Planka 1.13 sürümünden itibaren sizin için otomatik bir yönetici oluşturulmaz; bu nedenle yeni bir veritabanında giriş yapabilecek kimse bulunmaz. DEFAULT_ADMIN_* grubu, bu durumu düzeltmenin iki yolundan biridir.

Başlangıçta Planka, DEFAULT_ADMIN_EMAIL ile eşleşen bir kullanıcıyı kontrol eder. Eğer böyle bir kullanıcı yoksa, yanında belirtilen parola, görünen ad ve kullanıcı adını kullanarak bir tane oluşturur. Bu işlem, boş bir veritabanına karşı ilk başlatma sırasında gerçekleşir; dolayısıyla bu değişkenler bir hesabı yönetmekten ziyade onu bootstrap eder.

DEFAULT_ADMIN_EMAIL, kullanıcıları yanıltabilen ikinci bir işlev görür. Değişken tanımlı kaldığı sürece, ismi belirtilen hesap arayüz üzerinden kimse tarafından düzenlenemez veya silinemez. Bu bir kilitlenme korumasıdır; hesabın adını değiştirememenizin veya arayüzden e-posta adresini güncelleyememenizin nedeni budur. Değişkeni kaldırıp yeniden başlattığınızda hesap, diğerleri gibi düzenleyebileceğiniz sıradan bir yöneticiye dönüşür.

Parola satırı konusunda dikkatli olunmalıdır. environment: altındaki her şey, container üzerinde docker inspect komutunu çalıştırabilen herkes tarafından okunabilir; bu nedenle DEFAULT_ADMIN_PASSWORD kalıcı olarak orada tutulmamalıdır. Giriş yapın, arayüzden parolanızı değiştirin, ilgili satırı silin ve ardından docker compose up -d komutunu tekrar çalıştırın.

Daha temiz olan yöntem, değişkenleri tamamen atlamaktır. Tüm DEFAULT_ADMIN_* grubunu yorum satırı haline getirin ve ardından hesabı etkileşimli olarak oluşturun:

docker compose run --rm planka npm run db:create-admin-user

Bu komut e-posta, parola, görünen ad ve isteğe bağlı kullanıcı adı bilgilerini ister ve kullanıcıyı doğrudan veritabanına yazar. Parola hiçbir zaman Compose dosyasına veya container ortamına girmez. VPS üzerinde birden fazla kişinin shell erişimi varsa bu yöntemi kullanın. Komut, depends_on nedeniyle önce Postgres'i başlatır, bu sayede daha önce hiç ayağa kalkmamış bir stack üzerinde bile çalışır.

Her iki yöntem de Planka parolalarını manuel olarak yönetmenizi gerektirir. Eğer bu, ekibinizin topladığı dördüncü kimlik bilgisi seti ise, Planka giriş işlemlerini bir OIDC sağlayıcısına devredebilir; örneğin kendi tek oturum açma sunucunuz olarak çalışan Authentik kullanılabilir. Bootstrap yöneticisini ise sağlayıcının erişilemez olduğu durumlar için bir acil durum hesabı olarak tutabilirsiniz.

BASE_URL değeri hostname ile eşleşmediğinde giriş işlemleri neden başarısız olur?

BASE_URL, kullanıcıların tarayıcıya yazdığı, şema içeren ve sonunda eğik çizgi (slash) bulunmayan tam adrestir. Bu yığın için bu değer https://kanban.example.com şeklindedir. Planka, kendi bağlantılarını ve WebSocket bağlantısını bu değer üzerinden oluşturur; bu nedenle hatalı bir BASE_URL değeri size net bir hata mesajı vermez. Bunun yerine, yüklenen ancak yükleme işlemi asla tamamlanmayan bir sayfa ile karşılaşırsınız.

Sık karşılaşılan durum şudur: upstream örneğini kopyalarsınız, BASE_URL=http://localhost:3000 değerini olduğu gibi bırakırsınız ve siteye gerçek alan adınız üzerinden HTTPS ile erişirsiniz. Giriş formu gönderilir ve kimlik bilgileriniz kabul edilir. Ancak pano asla görüntülenmez. Tarayıcı geliştirici konsolunu açtığınızda /socket.io/ adresine yapılan isteklerin başarısız olduğunu görürsünüz; çünkü istemciye canlı bağlantısını localhost:3000 adresine açması söylenmiştir ve dizüstü bilgisayarınızda bu adres hiçbir yere karşılık gelmemektedir.

TRUST_PROXY=true, aynı sorunun diğer yarısıdır. Planka, Traefik arkasında çalıştığı için her istek, Docker ağı içerisinde proxy'nin adresinden düz HTTP üzerinden gelir. TRUST_PROXY olmadan uygulama, Traefik tarafından ayarlanan X-Forwarded-Proto ve X-Forwarded-For başlıklarını görmezden gelir; bu nedenle bağlantının güvensiz olduğuna karar verir ve her istemciyi tek bir paylaşılan IP adresi olarak değerlendirir. Bu ayar yapıldığında ise uygulama ilgili başlıkları okur ve şema konusunda tarayıcı ile uyumlu hale gelir.

Traefik, WebSocket bağlantılarını ek bir yapılandırma gerektirmeden proxy eder; bu da burada tercih edilmesinin bir nedenidir. Nginx üzerinde ise socket.io, proxy_set_header Upgrade $http_upgrade ve proxy_set_header Connection "upgrade" içeren kendi location bloğuna ihtiyaç duyar; aksi takdirde farklı bir nedenden dolayı aynı yükleme ekranında takılı kalma sorunu yaşanır.

Panoyu daha sonra yeni bir hostname adresine taşımak, iki değerin birlikte değiştirilmesi anlamına gelir: BASE_URL değeri ve Traefik Host() kuralı. Birini değiştirip diğerini unutursanız, yükleme ekranı sorunu tekrar ortaya çıkar. Planka'nın https://example.com/planka gibi bir alt yoldan sunulması, Mart 2026'da yayınlanan 2.1.0 sürümünden itibaren desteklenmektedir. Daha eski etiketlerde (tag), uygulamaya kendi alt alan adını (subdomain) atayın.

Planka eklentileri ve avatarları nerede tutar

Planka 2, bir kullanıcının yüklediği her şeyi container içinde tek bir yol altında saklar: /app/data. Eklentiler, kullanıcı avatarları ve pano arka plan görsellerinin tamamı burada bulunur. Sürüm 1 üç ayrı dizin kullanıyordu; bu nedenle eski bir kılavuzdan kopyalanan Compose dosyası artık var olmayan yolları bağlar ve gerçek veri dizini bağlanmamış halde kalır.

Bu tek bağlama noktası, bir yükseltme sonrasında panonun korunması ile kötü bir gün geçirmek arasındaki farktır. Eğer /app/data bir volume üzerinde değilse, yüklemeler container'ın yazılabilir katmanına düşer. Container yeniden oluşturulduğunda bu katman yok olur ve container, image etiketini her değiştirdiğinizde yeniden oluşturulur. Pano geri geldiğinde düzgün görünür, kartların tamamı yerindedir ancak tüm eklenti bağlantıları bozuktur; çünkü veritabanı satırları artık var olmayan dosyaları işaret etmektedir.

Yukarıdaki Compose dosyasında yer alan isimlendirilmiş volume (named volume) bu durumu engeller. Bir bind mount da iş görür ve dosyaların standart araçlarla yedeklenmesini kolaylaştırır, ancak fazladan bir adım gerektirir. Container içindeki Node süreci UID 1000 olarak çalışır; bu nedenle root tarafından sahiplenilen bir host dizini, ilk yüklemede izin hatası verir:

sudo chown -R 1000:1000 /opt/planka/data

İkisi arasındaki tercih, bind mount ve isimlendirilmiş volume karşılaştırması bölümünde ele alınmıştır.

Eklentiler planınızdaki disk alanını aşarsa, Planka bunları S3_ENDPOINT, S3_BUCKET ve ilgili anahtar değişkenleri aracılığıyla S3 uyumlu depolama birimlerine yazabilir. Bu ayar, barındırılan bir bucket'a veya başka bir sunucudaki kendi kendine barındırılan bir MinIO nesne deposuna işaret edebilir. Bu kararı ekip panoyu doldurmadan önce verin, çünkü ayar yalnızca yeni yüklemeler için geçerlidir.

Yığını başlatın ve çalıştığını doğrulayın

docker compose pull
docker compose up -d
docker compose ps

docker compose ps, healthy olarak postgres ve running olarak planka değerlerini göstermelidir. Eğer Planka sürekli yeniden başlatılıyorsa, ilk kontrol edilmesi gereken yer uygulama değil, veritabanı bağlantısıdır.

docker compose logs -f planka

Sağlıklı bir ilk başlatma işlemi, veritabanı migrasyonlarını çalıştırır ve ardından sunucunun 1337 numaralı portta dinleme yaptığını bildirir. Günlük kayıtlarına güvenmek yerine, doğrudan Postgres'e sorarak şemanın gerçekten yüklendiğini doğrulayın:

docker compose exec postgres psql -U planka -d planka -c '\dt'

board ve card içeren bir tablo listesi, migrasyonların çalıştığı anlamına gelir. "Did not find any relations" ifadesi, Planka'nın hiç bağlanamadığını gösterir; bu durumda DATABASE_URL değerini .env dosyanızdaki POSTGRES_USER ve POSTGRES_PASSWORD değerleri ile karşılaştırın.

Ardından, VPS üzerinden değil, kendi makinenizden rotayı kontrol edin:

curl -I https://kanban.example.com

HTTP/2 200, Traefik'in bir sertifikaya sahip olduğunu ve container'a ulaştığını gösterir. Traefik tarafından döndürülen bir 404 hatası, router etiketlerinin eşleşmediği anlamına gelir; bu durum genellikle container'ın proxy ağına bağlı olmamasından kaynaklanır. Şimdi siteyi açın ve yönetici hesabıyla giriş yapın.

Her sürüm yükseltme öncesinde pg_dump alın

Panonuz iki ayrı depoda tutulur, bu nedenle yedekleme her ikisini de kapsamalıdır: Postgres veritabanı ve planka-data birimi. Veritabanı dökümünü yığın çalışırken alın.

docker compose exec -T postgres pg_dump -U planka -d planka > "planka-db-$(date +%F).sql"

-T kullanımı isteğe bağlı değildir. Bu olmadan Compose bir sözde uçbirim (pseudo-terminal) ayırır ve uçbirim katmanı akıştaki satır sonlarını yeniden yazar; bu da geri yükleme sırasında yarıda kesilen bir döküm dosyasıyla sonuçlanır. Hata haftalar sonra ortaya çıkar ki bu da olabilecek en kötü zamandır.

Ardından yüklemeler. Önce gerçek birim adını bulun, çünkü Compose bunu proje dizin adı ile ön ekler.

docker volume ls | grep planka
docker run --rm -v planka_planka-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/planka-files-$(date +%F).tgz -C /data .

Proje ayrıca deposunda docker-backup.sh ve docker-restore.sh dosyalarını sunar ve resmi belgeler bunları günlük bir cron işine eklemenizi önerir. Her iki yaklaşım da uygundur. Uygun olmayan tek şey, daha önce hiç geri yüklemediğiniz bir yedektir; bu nedenle bir yedeği geçici bir VPS üzerinde geri yükleyin, giriş yapabildiğinizi ve bir eki açabildiğinizi doğrulayın.

Dökümü her sürüm değişikliğinden hemen önce çalıştırın. Dün gece alınan bir yedek, gerçekleştirmek üzere olduğunuz geçiş işleminden önceki yedekle aynı şey değildir.

Etiketleri sabitleyin ve sürüm notlarını okuyun

Dosyadaki her iki imaj etiketi de kasıtlı olarak sabitlenmiştir.

ghcr.io/plankanban/planka:2.1.1 belirli bir sürümdür ve Ağustos 2026 itibarıyla günceldir. latest, yukarı akış (upstream) yayın yaptığında değişir; bu nedenle rutin bir docker compose pull işlemi, seçmediğiniz bir anda şema migrasyonunu tetikleyebilir. Bu numarayı değiştirmeden önce sürüm notlarını okuyun; çünkü bozucu değişiklikler ve güvenlik yamaları burada açıklanır. 2.0.3 sürümü bir güvenlik güncellemesi olarak yayınlanmıştır; bu, kazara değil, bilerek haberdar olmanız gereken türden bir gelişmedir.

postgres:16-alpine, daha kritik bir nedenden dolayı ana sürüme sabitlenmiştir. Postgres, veri dizinini ana sürüme bağlı bir formatta yazar ve sunucu, farklı bir sürüm tarafından yazılmış bir dizini açmayı reddeder. postgres:latest yazıp etiketin 17'ye yükselmesine izin verirseniz, container başlamayacaktır:

FATAL:  database files are incompatible with server
DETAIL:  The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.

Hiçbir veri kaybolmaz ve yeniden başlatmak da sorunu çözmez. Yeni bir Postgres ana sürümüne geçmek, eski sürümden bir dump almayı ve yeni sürümdeki temiz bir veri dizinine geri yüklemeyi gerektirir. Bu, stack kapalıyken yapılması gereken planlı bir işlemdir; imaj çekme (pull) işleminin bir yan etkisi değildir.

Eğer sıfırdan başlamak yerine mevcut bir Planka 1.x kurulumunu taşıyorsanız, bu yükseltmenin proje dokümantasyonunda belirtilen kendine has bir prosedürü vardır ve önceden alınmış bir yedek olmadan 1. sürüme geri dönüş yolu bulunmamaktadır.

Hata modları ve karşılaşacağınız dizgeler

Planka döngüsel olarak yeniden başlıyor ve günlük kayıtlarında veritabanı adı geçiyor. DATABASE_URL içindeki kimlik bilgileri Postgres ortam değişkenleriyle eşleşmiyor. POSTGRES_PASSWORD değişkeninin yalnızca veri dizini ilk kez başlatıldığında uygulandığını unutmayın; bu nedenle hatalı bir ilk başlatmadan sonra değişkeni düzeltmek hiçbir şeyi değiştirmez. db-data birimini (volume) silip yeniden başlamanız gerekir.

Giriş başarılı ancak pano yüklenmiyor. BASE_URL tarayıcı çubuğundaki adresle eşleşmiyor veya TRUST_PROXY eksik. Tarayıcı konsolu /socket.io/ adresine yapılan isteklerin başarısız olduğunu gösterir.

Diğer her şey çalışırken dosya yüklemeleri başarısız oluyor. Bir bind mount kök (root) kullanıcıya ait. Ana makinedeki dizin üzerinde sudo chown -R 1000:1000 komutunu çalıştırın ve container'ı yeniden başlatın.

Yükseltme sonrasında ekler kayboldu. /app/data bir birim üzerinde değildi, bu nedenle dosyalar yükseltme ile değiştirilen container katmanında kaldı. Dosyaları yedekten geri yükleyin ve imaj etiketine tekrar dokunmadan önce birimi ekleyin.

Traefik 404 hatası döndürüyor. Container proxy ağında değil veya Host() kuralı DNS kaydınızla eşleşmiyor. docker compose config, değişkenler yerine yerleştirildikten sonraki etiketleri gösterir; yazım hataları burada belirginleşir.

Bildirimler veya webhook'lar ulaşmıyor. Planka 2, giden HTTP isteklerini dahili bir filtreden geçirir ve varsayılan engelleme listesi localhost ve postgres adreslerini kapsar. Aynı ana makinedeki başka bir container'a yönlendirilen webhook, tasarım gereği engellenebilir. Filtreyi kaldırmak yerine OUTGOING_ALLOWED_HOSTS ayarını düzenleyin.

Sistem çalışmaya başladıktan sonra operasyonel yükü düşüktür. Sürüm notlarını takip edin ve her yükseltme öncesinde veritabanı yedeği alın. Docker servisi açılışta etkinleştirildiği sürece, restart: unless-stopped sayesinde yeniden başlatma işleminden sonra yığın kendiliğinden ayağa kalkar; Yeniden başlatma sonrası ayağa kalkan Compose yığınları belgesi, sistemin ayağa kalkmadığı durumları ele almaktadır.

FAQ

Giriş yaptıktan sonra Planka neden sürekli yükleniyor?

Kimlik bilgileriniz kabul edilmiş ancak canlı bağlantı kurulamamıştır. Planka, WebSocket URL'sini BASE_URL değişkeninden oluşturur; bu nedenle siteye https://kanban.example.com üzerinden erişmenize rağmen değişken hala http://localhost:3000 değerini gösteriyorsa, tarayıcı makinenizde bulunmayan bir adrese soket açmaya çalışır. Geliştirici konsolu, /socket.io/ adresine yapılan başarısız istekleri gösterir. BASE_URL değişkenini, sonunda eğik çizgi (slash) olmadan tam genel adresinizle güncelleyin, uygulamanın reverse proxy'nizden gelen X-Forwarded-Proto başlığını dikkate alması için TRUST_PROXY=true ayarını ekleyin ve ardından docker compose up -d komutunu çalıştırın.

İlk Planka yönetici kullanıcısını nasıl oluştururum?

1.13 sürümünden itibaren otomatik olarak yönetici oluşturulmaz. Ya DEFAULT_ADMIN_EMAIL değişkenini ilgili parola, isim ve kullanıcı adı değişkenleriyle birlikte ayarlayıp stack'i başlatın ya da docker compose run --rm planka npm run db:create-admin-user komutunu çalıştırıp soruları yanıtlayın. Etkileşimli komut, paylaşımlı bir sunucuda daha güvenlidir; çünkü parola, docker inspect aracılığıyla okunabileceği container ortamına girilmemiş olur. İşlem sonrasında DEFAULT_ADMIN_EMAIL değişkenini tanımlı tutmak, ilgili hesabın arayüz üzerinden düzenlenmesini veya silinmesini engeller.

Planka ekleri ve avatarları nerede saklar?

Planka 2 sürümünde yüklenen tüm dosyalar, ekler, kullanıcı avatarları ve pano arka planları dahil olmak üzere container içinde /app/data dizininde tutulur. Bu yolu adlandırılmış bir volume (named volume) olarak mount edin. Eğer mount edilmezse, dosyalar container'ın yazılabilir katmanında kalır ve her imaj yükseltmesinde container yeniden oluşturulduğunda silinir. Bind mount da kullanılabilir ancak Node süreci UID 1000 ile çalıştığından, ana makinedeki dizin üzerinde sudo chown -R 1000:1000 komutunu çalıştırın; aksi takdirde yüklemeler izin hatası nedeniyle başarısız olur.

Self-hosted bir Planka ne kadar RAM'e ihtiyaç duyar?

Proje herhangi bir donanım alt sınırı yayınlamamaktadır. Barındırma sayfalarında tekrarlanan 2 vCPU ve 4 GB değeri, bir ölçümden ziyade sağlayıcının varsayılanıdır ve küçük bir pano için oldukça cömerttir. Tüm iş yükü bir Node süreci ve bir Postgres sürecinden ibarettir; bu nedenle 1 vCPU ve 2 GB'lık bir plan, iki ila beş kişilik bir ekibi rahatlıkla taşır. Normal bir haftanın ardından docker stats --no-stream komutunu çalıştırın ve boyutlandırmayı kendi verilerinize göre yapın. Bellekten ziyade diski yakından izleyin, çünkü büyüyen kısım ek dosyalardır.

Veri kaybetmeden Planka'yı nasıl yükseltirim?

Yükseltmeden hemen önce, bir önceki geceye ait yedeklere güvenmek yerine veritabanını dump edin ve uploads volume'unu arşivleyin. docker compose exec -T postgres pg_dump -U planka -d planka > planka-db.sql komutunu kullanın ve yönlendirilen çıktının bozulmaması için -T bayrağını koruyun. Atladığınız her sürüm için sürüm notlarını okuyun, imaj etiketini latest yerine belirli bir sürüme sabitleyin, ardından docker compose pull ve docker compose up -d komutlarını çalıştırarak logları migrasyon süreci için izleyin. Postgres etiketini ana sürümüne (major version) sabit tutun, çünkü sunucu farklı bir ana sürüm tarafından yazılmış bir veri dizinini açmayı reddeder.