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

Planka'yı self-host etmenin avantajları

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 tüm kontrol sizin elinizde olan bir VPS üzerinde çalışır. Kullanıcı başına ücretlendirme veya kişi sınırı yoktur; tek maliyet sunucu gideridir. Bu kılavuz, uygulamayı Docker Compose ile Traefik arkasında, veriler için Postgres kullanarak ve yüklenen dosyalar için adlandırılmış bir volume tanımlayarak dağıtır.

Bu kılavuz, Trello'nun ücretsiz planından ayrılan iki ila beş kişilik ekipler için hazırlanmıştır. Hangi panoyu kullanacağınıza henüz karar vermediyseniz, önce self-hosted Trello alternatiflerinin karşılaştırmasına göz atın. Bu kılavuz, seçimin yapıldığını varsayar ve yalnızca dağıtım sürecini ele alır.

Docker Engine ve Compose eklentisi kurulu 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ını yapan bir Traefik örneğinin halihazırda çalışıyor olması gerekir. Eğer Traefik kurulu değilse, önce birden fazla Compose uygulaması önünde bir Traefik reverse proxy kurulumunu tamamlayın; aşağıdaki dosya yapısı size yabancı geliyorsa Docker Compose temel bilgilerini inceleyin.

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

Proje resmi bir donanım taban değeri yayınlamamaktadı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 sistem oldukça küçüktür: API'yi 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. Bir pano hafif bir komşudur; eğer aynı VPS üzerinde ekibinizin belgelerini de tutmayı planlıyorsanız, önce o uygulamanın boyutunu hesaplayın: Notion benzeri bir çalışma alanı olarak AFFiNE çalıştırmak, Planka herhangi bir kaynak talep etmeden önce kendi başına birkaç gigabayt bellek gerektirir.

Disk boyutunu bellekten önce belirleyin, çünkü ekler zamanla büyüyen kısımdır. Bu paragrafa güvenmek yerine kendi örneğinizi ölçün:

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

İlk komut, her container için anlık bellek ve CPU kullanımını yazdırır. İkincisi ise her bir volume'un 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şta duran bir pano ekibinizin kullanımı hakkında size hiçbir veri sağlamaz.

Compose dosyasını yazın

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ğerlerin 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ı bilinçlidir. Bir onaltılık (hex) dizi 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ı dizisini bozamaz. İçinde eğik çizgi veya "at" işareti bulunan bir base64 parola, yanlış bir ana bilgisayar adı (hostname) gibi görünen bir bağlantı hatasına yol açar ve bu size bir saat kaybettirir. 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, geçtiği her iki yerde de kendi ana bilgisayar 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 bir ports: bloğu yoktur. Traefik, konteynere proxy ağı üzerinden ulaşır, bu nedenle 1337 numaralı port ana bilgisayarda hiçbir zaman dışarıya açılmaz (publish). Bunu 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 sadece 3000 numaralı portu ana bilgisayara eşlediği için ona ulaşabilir. Burada bir ana bilgisayar eşlemesi yoktur, bu yüzden 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 kapanır; bu durum 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ünde açıklanmıştır.
• 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ğerlerinin halihazırda yerleştirilmiş olduğu 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 gerçek işlevi

Planka 1.13 sürümünden itibaren otomatik olarak yönetici hesabı oluşturulmamaktadır; bu nedenle yeni bir veritabanında giriş yapabilecek kimse bulunmaz. DEFAULT_ADMIN_* grubu, bu durumu çözmenin iki yolundan biridir.

Planka, başlatma sırasında 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 hesap 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 hesabı yönetmekten ziyade ilk kurulumu (bootstrap) sağlar.

DEFAULT_ADMIN_EMAIL, kullanıcıların sıkça gözden kaçırdığı ikinci bir göreve sahiptir. Bu değişken tanımlı kaldığı sürece, söz konusu hesap arayüz üzerinden kimse tarafından düzenlenemez veya silinemez. Bu bir kilitlenme korumasıdır ve hesabın adının veya e-posta adresinin arayüzden değiştirilememesinin nedeni de budur. Değişkeni kaldırıp servisi yeniden başlattığınızda, hesap diğerleri gibi düzenlenebilir sıradan bir yönetici hesabına dönüşür.

Parola satırı konusunda dikkatli olunmalıdır. environment: altındaki her veri, 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üz üzerinden 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 devre dışı bırakmaktır. DEFAULT_ADMIN_* grubunun tamamını yorum satırı haline getirin ve 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, Compose dosyasına veya container ortamına hiçbir şekilde girmez. VPS üzerinde birden fazla kişinin shell erişimi varsa bu yöntemi kullanın. Komut, depends_on nedeniyle önce Postgres servisini başlatır, bu sayede daha önce hiç çalıştırılmamış bir stack üzerinde bile sorunsuz çalışır.

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

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 yanlış bir BASE_URL değeri size net bir hata mesajı vermez. Bunun yerine, sayfa yüklenir ancak yükleme işlemi hiçbir zaman tamamlanmaz.

Sık karşılaşılan durum şudur: Yukarı akış (upstream) örneğini kopyalar, BASE_URL=http://localhost:3000 değerini olduğu gibi bırakır ve siteye gerçek alan adınız üzerinden HTTPS ile erişirsiniz. Giriş formu gönderilir ve kimlik bilgileriniz kabul edilir. Ancak pano ekranı asla gelmez. 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 karşılığa sahip değildir.

TRUST_PROXY=true, aynı sorunun diğer yarısıdır. Planka, Traefik arkasında çalıştığı için her istek, Docker ağı içindeki proxy adresinden düz HTTP üzerinden ulaşır. TRUST_PROXY olmadan uygulama, Traefik tarafından ayarlanan X-Forwarded-Proto ve X-Forwarded-For başlıklarını yok sayar; bu nedenle bağlantının güvensiz olduğunu varsayar ve her istemciyi tek bir paylaşılan IP adresi olarak değerlendirir. Bu değer ayarlandığı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 üzerinden iletir; bu durum, 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 döngüsü sorunuyla karşılaşırsınız.

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 döngüsü sorununa geri dönersiniz. Planka'yı https://example.com/planka gibi bir alt yoldan (subpath) sunmak, Mart 2026'da yayınlanan 2.1.0 sürümünden itibaren mümkündür. Daha eski etiketlerde (tag), uygulamaya kendine ait bir alt alan adı (subdomain) tanımlayın.

Planka eklentileri ve avatarları nerede tutar

Planka 2, kullanıcı tarafından yüklenen 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 mevcut olmayan yolları bağlar ve gerçek veri dizini bağlanmamış halde kalır.

Bu tek bağlama noktası, yükseltme sonrasında hayatta kalan bir pano ile kötü geçen bir öğleden sonra 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 veritabanı satırları artık var olmayan dosyalara işaret ettiği için tüm eklenti bağlantıları bozulmuştur.

Yukarıdaki Compose dosyasında yer alan isimlendirilmiş volume (named volume) bu durumu önler. 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 ana makine dizini, ilk yüklemede izin hatası verir:

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

İkisi arasındaki ödünleşim 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 alanına yazabilir. Bu, barındırılan bir bucket'a veya başka bir makinedeki kendi kendine barındırılan MinIO nesne deposuna işaret edebilir. Bu kararı ekip panoyu doldurmadan önce verin, çünkü ayar yalnızca yeni yüklemeler için geçerlidir.

Stack'i başlatın ve çalıştığını doğrulayın

docker compose pull
docker compose up -d
docker compose ps

docker compose ps komutu, postgres değerini healthy olarak ve planka değerini running olarak 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 Postgres'e doğrudan sorgu göndererek şemanın oluştuğunu doğrulayın:

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

board ve card tablolarını içeren bir liste, migrasyonların çalıştığı anlamına gelir. "Did not find any relations" mesajı, Planka'nın bağlantı kuramadığı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 çıktısı, 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ınızla giriş yapın.

Her sürüm yükseltmesinden önce 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 en kötü zamandır.

Ardından yüklemeler gelir. Önce gerçek birim adını bulun, çünkü Compose bunu proje dizini adıyla ö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 yüzden bir kez boş bir VPS üzerinde geri yükleme yapın, giriş yapabildiğinizi ve bir eki açabildiğinizi doğrulayın. Aynı depolama çifti, yükleme kabul eden her Compose uygulamasında karşınıza çıkar; bu nedenle daha sonra Chatwoot'u destek masanızla aynı sunucuya kurarsanız, burada oluşturduğunuz rutin, yalnızca birim adları değiştirilerek aynen uygulanabilir.

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şten hemen önce alınan bir 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ıkça değişir; bu nedenle rutin bir docker compose pull işlemi, siz 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 sürümü olarak yayınlanmıştır; bu, kazara değil, bilerek haberdar olmanız gereken türden bir gelişmedir. Yukarı akış sağlayıcısı imaj yayınladığı için burada sabitleme yapmak kolaydır. Bir proje imaj yayınlamıyorsa, git etiketinden yerel olarak derlenen openGym örneğinde olduğu gibi, aynı disiplini fazladan bir adım atarak uygulamanız gerekir.

postgres:16-alpine, daha ciddi 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, ancak yeniden başlatma işlemi de 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, servisler kapalıyken planlanarak yapılması gereken bir işlemdir; imaj çekme işleminin bir yan etkisi değildir.

Sıfırdan başlamak yerine mevcut bir Planka 1.x kurulumunu taşıyorsanız, bu yükseltmenin proje belgelerinde kendi prosedürü mevcuttur. Önceden alınmış bir yedek olmadan 1. sürüme geri dönüş yolu yoktur.

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ıyla 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) kaldırmanız ve yeniden başlamanız gerekir.

Giriş başarılı oluyor ancak pano asla 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österiyor.

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ükseltmenin yerini aldığı container katmanında kaldı. Dosyaları yedekten geri yükleyin, ardından görüntü etiketine (image tag) 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 görünür hale gelir.

Bildirimler veya webhook'lar asla 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 bir 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 servisinin kendisi önyüklemede etkinleştirildiği sürece, restart: unless-stopped sayesinde bir yeniden başlatma işlemi yığını kendiliğinden ayağa kaldırır; Yeniden başlatma sonrası ayağa kalkan Compose yığınları belgesi, bunun gerçekleşmediği durumları ele alır.

FAQ

Planka giriş yaptıktan sonra 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. DEFAULT_ADMIN_EMAIL değişkenini daha sonra ayarlı tutmak, ilgili hesabın arayüz üzerinden düzenlenmesini ve silinmesini engeller.

Planka ekleri ve avatarları nerede saklar?

Planka 2'de 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 Planka ne kadar RAM'e ihtiyaç duyar?

Proje herhangi bir alt donanım 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ı 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 veritabanını dump edin ve uploads volume'unu arşivleyin; bunu bir önceki gecenin yedekleme planına bırakmayın. -T bayrağını koruyarak docker compose exec -T postgres pg_dump -U planka -d planka > planka-db.sql komutunu kullanın; böylece pseudo-terminal, yönlendirilen çıktıyı bozmaz. 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ırıp migrasyon sürecini loglardan 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.