SSD Nodes Learn 🎉 VPS $5.50/माह से
गाइड Matt Connorलेखक: Matt Connor · अपडेट किया गया: 2026-08-10

Planka को Docker Compose पर कैसे host करें

Docker Compose का उपयोग करके Planka को VPS पर deploy करें। इस गाइड में Postgres और Traefik सेटअप के साथ BASE_URL की वह महत्वपूर्ण सेटिंग शामिल है जो लॉगिन एरर का कारण बनती है।

Planka को self-host करने के लाभ

Planka को self-host करने से आपकी टीम को एक ऐसा Kanban board मिलता है, जिसमें card, list और label का वही मॉडल है जिसे लोग पहले से Trello में इस्तेमाल करते हैं। यह आपके द्वारा नियंत्रित VPS पर चलता है। इसमें कोई seat limit या प्रति-उपयोगकर्ता बिलिंग नहीं है, क्योंकि एकमात्र खर्च सर्वर का है। यह गाइड इसे Traefik के पीछे Docker Compose के साथ deploy करती है, जिसमें डेटा के लिए Postgres और अपलोड की गई प्रत्येक फाइल के लिए एक named volume का उपयोग किया जाता है।

यह गाइड उन दो से पांच लोगों की टीमों के लिए है जो Trello के free tier से बाहर निकल रहे हैं। यदि आप अभी भी यह तय कर रहे हैं कि कौन सा board इस्तेमाल करना है, तो पहले self-hosted Trello विकल्पों की तुलना पढ़ें। यह गाइड मानती है कि आपने चुनाव कर लिया है और केवल deploy करने की प्रक्रिया बताती है।

आपको Docker Engine और Compose plugin के साथ एक VPS की आवश्यकता है, जिस पर एक DNS A record point कर रहा हो। आपको उस box पर पहले से ही TLS (transport layer security) terminate करने वाले एक Traefik instance की भी आवश्यकता है। यदि Traefik अभी तक मौजूद नहीं है, तो पहले कई Compose apps के सामने एक Traefik reverse proxy सेट करें, और यदि नीचे दी गई फाइल अपरिचित लगती है तो VPS के लिए Docker Compose की बुनियादी बातें पढ़ें।

Planka को कितने VPS की आवश्यकता है?

यह प्रोजेक्ट हार्डवेयर की कोई न्यूनतम सीमा प्रकाशित नहीं करता है, इसलिए आपके द्वारा पढ़ी गई किसी भी संख्या को माप के बजाय एक शुरुआती बिंदु मानें। होस्टिंग पेजों पर दोहराया जाने वाला 2 vCPU और 4 GB का आंकड़ा प्रदाता का एक सुविधाजनक डिफ़ॉल्ट है, न कि प्रोजेक्ट द्वारा मापी गई कोई आवश्यकता। पाँच लोगों द्वारा उपयोग किए जाने वाले बोर्ड के लिए यह काफी अधिक है।

जो वास्तव में चलता है वह छोटा है: API और बिल्ट फ्रंटएंड को सर्व करने वाली एक Node.js प्रक्रिया, और डेटा रखने वाली एक Postgres प्रक्रिया। Planka कंटेनर के अंदर आउटगोइंग अनुरोधों को फ़िल्टर करने के लिए एक तीसरी छोटी प्रॉक्सी प्रक्रिया चलती है। 1 vCPU और 2 GB का प्लान दो से पाँच लोगों के बोर्ड को संभाल सकता है, और अधिकांश अतिरिक्त मेमोरी Postgres कैश के रूप में उपयोग होती है।

मेमोरी का आकार तय करने से पहले डिस्क का आकार तय करें, क्योंकि अटैचमेंट ही वह हिस्सा है जो बढ़ता है। इस पैराग्राफ पर भरोसा करने के बजाय अपने स्वयं के इंस्टेंस को मापें:

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

पहला कमांड प्रति कंटेनर लाइव मेमोरी और CPU को प्रिंट करता है। दूसरा दिखाता है कि प्रत्येक वॉल्यूम कितनी जगह ले रहा है। दोनों रीडिंग एक सामान्य कार्य सप्ताह के बाद लें, न कि इंस्टॉलेशन के दिन, क्योंकि एक निष्क्रिय बोर्ड आपकी टीम के बारे में कुछ नहीं बताता है।

Compose file लिखें

Directory बनाएँ और उसका स्वामित्व (ownership) लें, ताकि आपको इन फाइलों को कभी भी sudo के माध्यम से edit न करना पड़े।

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

Secrets को Compose file के बगल में एक .env फाइल में generate करें। Compose उस फाइल को अपने आप पढ़ लेता है और मानों (values) को प्रतिस्थापित (substitute) कर देता है।

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 जानबूझकर चुना गया है। एक hex string में केवल अंक और a से f तक के अक्षर होते हैं, इसलिए यह उस DATABASE_URL connection string को खराब नहीं कर सकता जिसमें इसे paste किया जाता है। एक base64 password जिसमें slash या at sign हो, वह एक connection error पैदा करता है जो गलत hostname जैसा दिखता है, और इसमें आपका एक घंटा बर्बाद हो सकता है। व्यापक पैटर्न keeping secrets out of the Compose file में कवर किया गया है।

अब docker-compose.yml। kanban.example.com को दोनों स्थानों पर अपने स्वयं के hostname से बदलें।

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:

उस फाइल में लिए गए चार निर्णय समझाने योग्य हैं, क्योंकि लोग अक्सर उन्हें बदलते हैं और बाद में पछताते हैं।

  • Planka service पर कोई ports: ब्लॉक नहीं है। Traefik कंटेनर तक proxy नेटवर्क के माध्यम से पहुँचता है, इसलिए port 1337 कभी भी host पर publish नहीं होता है। इसे publish करने से कोई भी आपके proxy और certificate को bypass कर सकता है।
  • loadbalancer.server.port=1337 कंटेनर के अंदर के port का नाम बताता है। Planka 1337 पर listen करता है, और upstream उदाहरण केवल 3000 पर उस तक पहुँचता है क्योंकि वह port को host पर map करता है। यहाँ कोई host mapping नहीं है, इसलिए Traefik को कंटेनर port के बारे में बताना पड़ता है।
  • condition: service_healthy, Postgres healthcheck के साथ जुड़ा है। इसके बिना Planka डेटाबेस द्वारा connection स्वीकार करने से पहले ही start हो जाता है, अपनी पहली query में विफल हो जाता है और exit हो जाता है, जो एक crash loop जैसा दिखता है। इसकी कार्यप्रणाली Compose healthchecks and startup ordering में दी गई है।
  • डेटाबेस service का नाम जानबूझकर postgres रखा गया है। Planka 2 अपने स्वयं के outgoing requests को एक internal filter के माध्यम से भेजता है जिसकी default block list localhost,postgres है। service का नाम बदलने पर आप चुपचाप अपने डेटाबेस को उस सूची से हटा देते हैं।

जाँचें कि कुछ भी शुरू करने से पहले Compose आपके secrets को देख सकता है या नहीं:

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

यह उस फाइल को print करता है जिसमें .env मान पहले से ही प्रतिस्थापित (substituted) हैं। एक खाली मान का अर्थ है कि Compose .env फाइल को नहीं पढ़ रहा है, आमतौर पर ऐसा इसलिए होता है क्योंकि आप किसी दूसरी directory से command चला रहे हैं।

एडमिन बूटस्ट्रैप वेरिएबल्स वास्तव में क्या करते हैं

Planka 1.13 के बाद से आपके लिए कोई एडमिन नहीं बनाया जाता है, इसलिए एक नए डेटाबेस में कोई भी ऐसा व्यक्ति नहीं होता जो लॉग इन कर सके। DEFAULT_ADMIN_* ग्रुप इसे ठीक करने के दो तरीकों में से एक है।

स्टार्टअप पर Planka DEFAULT_ADMIN_EMAIL से मेल खाने वाले यूजर को खोजता है। यदि कोई यूजर नहीं मिलता है, तो यह उसके साथ सेट किए गए पासवर्ड, डिस्प्ले नेम और यूजरनेम का उपयोग करके एक यूजर बनाता है। यह खाली डेटाबेस पर पहली बार बूट होने पर होता है, इसलिए ये वेरिएबल्स अकाउंट को मैनेज करने के बजाय उसे बूटस्ट्रैप करते हैं।

DEFAULT_ADMIN_EMAIL एक दूसरा काम भी करता है जो लोगों को उलझा देता है। जब तक यह वेरिएबल सेट रहता है, तब तक इसके द्वारा नामित अकाउंट को इंटरफ़ेस से कोई भी एडिट या डिलीट नहीं कर सकता है। यह एक लॉक-आउट गार्ड है, और यही कारण है कि आप UI में उस अकाउंट का नाम नहीं बदल सकते या उसका ईमेल पता नहीं बदल सकते। वेरिएबल को हटा दें और रीस्टार्ट करें, फिर वह अकाउंट एक सामान्य एडमिन बन जाएगा जिसे आप किसी अन्य की तरह एडिट कर सकते हैं।

पासवर्ड वाली लाइन के साथ सावधानी बरतनी चाहिए। environment: के अंतर्गत कोई भी जानकारी उसे पढ़ने योग्य होती है जो कंटेनर पर docker inspect चला सकता है, इसलिए DEFAULT_ADMIN_PASSWORD को वहां स्थायी रूप से नहीं रहना चाहिए। लॉग इन करें, इंटरफ़ेस में अपना पासवर्ड बदलें, उस लाइन को डिलीट करें, और फिर दोबारा docker compose up -d चलाएं।

साफ-सुथरा तरीका वेरिएबल्स को पूरी तरह से छोड़ देना है। पूरे DEFAULT_ADMIN_* ग्रुप को कमेंट आउट करें, फिर इंटरैक्टिव तरीके से अकाउंट बनाएं:

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

यह ईमेल, पासवर्ड, डिस्प्ले नेम और एक वैकल्पिक यूजरनेम के लिए प्रॉम्प्ट देता है, और यूजर को सीधे डेटाबेस में लिख देता है। पासवर्ड कभी भी Compose फाइल या कंटेनर एनवायरनमेंट को नहीं छूता है। यदि एक से अधिक व्यक्ति के पास VPS का शेल एक्सेस है, तो इस तरीके का उपयोग करें। यह कमांड depends_on के कारण पहले Postgres को स्टार्ट करती है, इसलिए यह ऐसे स्टैक पर भी काम करता है जो कभी चालू नहीं हुआ हो।

दोनों ही तरीकों में आपको Planka पासवर्ड खुद मैनेज करने पड़ते हैं, और यदि यह आपके द्वारा कलेक्ट किए गए क्रेडेंशियल्स का चौथा सेट है, तो Planka इसके बजाय लॉग इन को OIDC प्रोवाइडर को सौंप सकता है, जैसे कि Authentik जो आपके अपने सिंगल साइन-ऑन सर्वर के रूप में चल रहा हो, जिसमें बूटस्ट्रैप एडमिन को उस दिन के लिए ब्रेक-ग्लास अकाउंट के रूप में रखा जाता है जब प्रोवाइडर डाउन हो।

जब BASE_URL होस्टनेम से मेल नहीं खाता तो लॉगिन क्यों विफल हो जाता है

BASE_URL वह सटीक पता है जिसे लोग ब्राउज़र में टाइप करते हैं, जिसमें स्कीम शामिल होती है और अंत में कोई स्लैश नहीं होता है। इस स्टैक के लिए वह https://kanban.example.com है। Planka उस मान से अपने स्वयं के लिंक और अपना WebSocket कनेक्शन बनाता है, जिसका अर्थ है कि गलत BASE_URL आपको कोई स्पष्ट त्रुटि नहीं देता है। यह आपको एक ऐसा पेज देता है जो लोड तो होता है लेकिन कभी पूरी तरह लोड नहीं हो पाता।

सामान्य स्थिति: आप अपस्ट्रीम उदाहरण को कॉपी करते हैं, BASE_URL=http://localhost:3000 को वैसा ही छोड़ देते हैं, और अपने वास्तविक डोमेन पर HTTPS के माध्यम से साइट तक पहुँचते हैं। लॉगिन फॉर्म सबमिट हो जाता है और आपके क्रेडेंशियल्स स्वीकार कर लिए जाते हैं। बोर्ड कभी दिखाई नहीं देता। ब्राउज़र डेवलपर कंसोल खोलें और आप देखेंगे कि /socket.io/ के अनुरोध विफल हो रहे हैं, क्योंकि क्लाइंट को अपना लाइव कनेक्शन localhost:3000 पर खोलने के लिए कहा गया था, और आपके लैपटॉप पर वह पता मौजूद ही नहीं है।

TRUST_PROXY=true उसी समस्या का दूसरा हिस्सा है। Planka, Traefik के पीछे स्थित है, इसलिए प्रत्येक अनुरोध Docker नेटवर्क के भीतर सादे HTTP पर प्रॉक्सी के पते से उस तक पहुँचता है। TRUST_PROXY के बिना, ऐप उन X-Forwarded-Proto और X-Forwarded-For हेडर को अनदेखा कर देता है जिन्हें Traefik सेट करता है, इसलिए यह मानता है कि कनेक्शन असुरक्षित है और प्रत्येक क्लाइंट को एक साझा IP पते के रूप में मानता है। इसे सेट करने पर, ऐप उन हेडर को पढ़ता है और स्कीम के बारे में ब्राउज़र से सहमत हो जाता है।

Traefik बिना किसी अतिरिक्त कॉन्फ़िगरेशन के WebSockets को प्रॉक्सी करता है, जो यहाँ इसे प्राथमिकता देने का एक कारण है। nginx पर, socket.io को अपने स्वयं के location ब्लॉक की आवश्यकता होती है जिसमें proxy_set_header Upgrade $http_upgrade और proxy_set_header Connection "upgrade" शामिल हों, अन्यथा आपको एक अलग कारण से वही फंसा हुआ स्पिनर दिखाई देगा।

बोर्ड को बाद में किसी नए होस्टनेम पर ले जाने का मतलब है दो चीजों को एक साथ बदलना: BASE_URL मान और Traefik Host() नियम। एक को बदलें और दूसरे को भूल जाएं, तो आप वापस उसी स्पिनर पर आ जाएंगे। Planka को https://example.com/planka जैसे सबपाथ से सर्व करना मार्च 2026 में जारी संस्करण 2.1.0 से काम करता है। पुराने टैग पर, इसे अपना एक अलग सबडोमेन दें।

Planka attachments और avatars कहाँ रखता है

Planka 2 उपयोगकर्ता द्वारा अपलोड की गई हर चीज़ को container के अंदर एक ही path पर रखता है: /app/data। Attachments, user avatars और board background images सभी इसी के अंतर्गत रहते हैं। Version 1 में तीन अलग-अलग directories का उपयोग होता था, इसलिए पुराने लेख से copy किया गया Compose file ऐसे paths को mount करता है जो अब मौजूद नहीं हैं, और वास्तविक data directory unmounted रह जाती है।

वह एक mount ही तय करता है कि upgrade के बाद board सुरक्षित रहेगा या आपका समय खराब होगा। यदि /app/data volume पर नहीं है, तो uploads container की writable layer में चले जाते हैं। जब container को recreate किया जाता है तो वह layer नष्ट हो जाती है, और हर बार image tag बदलने पर container recreate होता है। Board वापस आने पर ठीक दिखता है, cards भी वहीं होते हैं, लेकिन हर attachment link काम करना बंद कर देता है, क्योंकि database rows अब भी उन files की ओर इशारा करती हैं जो मौजूद नहीं हैं।

ऊपर दिए गए Compose file में named volume इसे रोकता है। Bind mount भी काम करता है और साधारण tools के साथ files का backup लेना आसान बनाता है, लेकिन इसके लिए एक अतिरिक्त कदम की आवश्यकता होती है। Container के अंदर Node process UID 1000 के रूप में चलती है, इसलिए root के स्वामित्व वाली host directory पहले upload पर permission error देती है:

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

दोनों के बीच के अंतर को bind mounts बनाम named volumes में समझाया गया है।

यदि attachments आपके plan की disk क्षमता से अधिक हो जाते हैं, तो Planka उन्हें S3_ENDPOINT, S3_BUCKET और संबंधित key variables के माध्यम से S3-compatible storage पर लिख सकता है। यह किसी hosted bucket या किसी अन्य box पर मौजूद self-hosted MinIO object store की ओर इशारा कर सकता है। टीम द्वारा board भरने से पहले ही इसका निर्णय ले लें, क्योंकि यह setting केवल नए uploads पर लागू होती है।

स्टैक को स्टार्ट करें और जाँचें कि यह काम कर रहा है या नहीं

docker compose pull
docker compose up -d
docker compose ps

docker compose ps को postgres के रूप में healthy और planka को running के रूप में दिखाना चाहिए। यदि Planka बार-बार रीस्टार्ट हो रहा है, तो सबसे पहले ऐप के बजाय डेटाबेस कनेक्शन की जाँच करें।

docker compose logs -f planka

एक सफल फर्स्ट बूट डेटाबेस माइग्रेशन चलाता है और फिर रिपोर्ट करता है कि सर्वर पोर्ट 1337 पर लिसन कर रहा है। लॉग पर भरोसा करने के बजाय सीधे Postgres से पूछकर पुष्टि करें कि स्कीमा वास्तव में लोड हो गया है:

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

टेबल की सूची में board और card का होना यह दर्शाता है कि माइग्रेशन चल गए हैं। "Did not find any relations" का अर्थ है कि Planka कभी कनेक्ट नहीं हुआ, इसलिए DATABASE_URL की तुलना अपने .env में मौजूद POSTGRES_USER और POSTGRES_PASSWORD मानों से करें।

इसके बाद VPS से नहीं, बल्कि अपनी मशीन से रूट की जाँच करें:

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

HTTP/2 200 का अर्थ है कि Traefik के पास सर्टिफिकेट है और वह कंटेनर तक पहुँच रहा है। Traefik द्वारा 404 एरर मिलने का मतलब है कि राउटर लेबल मैच नहीं हुए, जिसका सबसे आम कारण यह है कि कंटेनर proxy नेटवर्क से जुड़ा नहीं है। अब साइट खोलें और एडमिन अकाउंट से लॉग इन करें।

हर version bump से पहले pg_dump लें

आपके बोर्ड का डेटा दो अलग-अलग जगहों पर रहता है, इसलिए बैकअप में दोनों को शामिल करना आवश्यक है: Postgres डेटाबेस और planka-data वॉल्यूम। स्टैक के चलते समय ही डेटाबेस का डंप लें।

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

-T वैकल्पिक नहीं है। इसके बिना Compose एक pseudo-terminal आवंटित करता है, और टर्मिनल लेयर स्ट्रीम में लाइन एंडिंग्स को फिर से लिख देती है। इसके परिणामस्वरूप आपको एक ऐसी डंप फाइल मिलती है जो रिस्टोर के दौरान बीच में ही विफल हो जाती है। यह विफलता हफ्तों बाद सामने आती है, जो कि सबसे खराब स्थिति है।

इसके बाद uploads का बैकअप लें। सबसे पहले वास्तविक वॉल्यूम नाम का पता लगाएं, क्योंकि Compose इसे प्रोजेक्ट डायरेक्टरी नाम के साथ प्रीफिक्स करता है।

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 .

प्रोजेक्ट अपनी रिपॉजिटरी में docker-backup.sh और docker-restore.sh भी प्रदान करता है, और आधिकारिक डॉक्यूमेंटेशन इन्हें nightly cron job पर सेट करने का सुझाव देता है। दोनों में से कोई भी तरीका सही है। जो तरीका सही नहीं है, वह है ऐसा बैकअप जिसे आपने कभी रिस्टोर करके नहीं देखा। इसलिए, एक बार किसी स्क्रैच VPS पर बैकअप रिस्टोर करें और पुष्टि करें कि आप लॉग इन कर सकते हैं और कोई अटैचमेंट खोल सकते हैं।

हर version change से ठीक पहले डंप चलाएं। पिछली रात का बैकअप उस बैकअप के समान नहीं है जो आप माइग्रेशन शुरू करने से ठीक पहले लेते हैं।

Tags को पिन करें और release notes पढ़ें

उस फाइल में दोनों image tags को जानबूझकर पिन किया गया है।

ghcr.io/plankanban/planka:2.1.1 एक विशिष्ट release है, जो अगस्त 2026 तक current है। latest तब बदल जाता है जब भी upstream इसे publish करता है, इसलिए एक सामान्य docker compose pull किसी भी समय schema migration ला सकता है, जिसे आपने नहीं चुना होगा। उस नंबर को बदलने से पहले release notes पढ़ें, क्योंकि वहीं पर breaking changes और security fixes का वर्णन होता है। Version 2.0.3 को एक security release के रूप में publish किया गया था, और यह बिल्कुल वैसी ही जानकारी है जिसे आप अचानक से सामना करने के बजाय पढ़ना चाहेंगे।

postgres:16-alpine को एक major version पर पिन करने का एक ठोस कारण है। Postgres अपनी data directory को एक ऐसे format में लिखता है जो major version से जुड़ा होता है, और server किसी अलग version द्वारा लिखी गई directory को खोलने से मना कर देता है। यदि आप postgres:latest लिखते हैं और tag को 17 पर roll होने देते हैं, तो container start नहीं होगा:

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.

कुछ भी खोता नहीं है, और न ही restart करने से कुछ ठीक होता है। नए Postgres major version पर जाने का मतलब है पुराने version से dump लेना और नए version पर एक नई data directory में restore करना। यह stack को down करके किया जाने वाला एक नियोजित कार्य है, न कि image pull का कोई side effect।

यदि आप नए सिरे से शुरुआत करने के बजाय किसी मौजूदा Planka 1.x install को migrate कर रहे हैं, तो उस upgrade की अपनी निर्धारित प्रक्रिया project documentation में दी गई है, और पहले से backup लिए बिना version 1 पर वापस जाने का कोई रास्ता नहीं है।

विफलता के प्रकार और वे स्ट्रिंग्स जो आपको दिखाई देंगी

Planka लूप में रीस्टार्ट होता है और लॉग में डेटाबेस का नाम आता है। DATABASE_URL में मौजूद क्रेडेंशियल्स Postgres एनवायरनमेंट से मेल नहीं खाते हैं। ध्यान दें कि POSTGRES_PASSWORD केवल तभी लागू होता है जब डेटा डायरेक्टरी पहली बार इनिशियलाइज़ की जाती है, इसलिए खराब पहले बूट के बाद वेरिएबल को ठीक करने से कुछ नहीं बदलता है। आपको db-data वॉल्यूम को हटाना होगा और फिर से शुरू करना होगा।

लॉगिन सफल होता है लेकिन बोर्ड लोड नहीं होता है। BASE_URL ब्राउज़र बार में दिए गए पते से मेल नहीं खाता है, या TRUST_PROXY गायब है। ब्राउज़र कंसोल /socket.io/ पर विफल अनुरोध दिखाता है।

बाकी सब कुछ काम करता है लेकिन अपलोड विफल हो जाते हैं। एक बाइंड माउंट जिसका ओनर root है। होस्ट डायरेक्टरी पर sudo chown -R 1000:1000 चलाएं और कंटेनर को रीस्टार्ट करें।

अपग्रेड के बाद अटैचमेंट्स गायब हो गए। /app/data वॉल्यूम पर नहीं था, इसलिए फाइलें उस कंटेनर लेयर में थीं जिसे अपग्रेड ने बदल दिया। बैकअप से फाइलें रिस्टोर करें, फिर इमेज टैग को दोबारा बदलने से पहले वॉल्यूम जोड़ें।

Traefik 404 एरर देता है। कंटेनर proxy नेटवर्क पर नहीं है, या Host() नियम आपके DNS रिकॉर्ड से मेल नहीं खाता है। docker compose config प्रतिस्थापन (substitution) के बाद के लेबल्स दिखाता है, जहाँ टाइपिंग की गलतियाँ स्पष्ट हो जाती हैं।

नोटिफिकेशन या वेबहुक नहीं आते हैं। Planka 2 अपने आउटगोइंग HTTP अनुरोधों को एक इंटरनल फिल्टर के माध्यम से भेजता है, और डिफ़ॉल्ट ब्लॉक लिस्ट में localhost और postgres शामिल हैं। एक ही होस्ट पर किसी अन्य कंटेनर के लिए लक्षित वेबहुक को डिज़ाइन के अनुसार ब्लॉक किया जा सकता है। फिल्टर को हटाने के बजाय OUTGOING_ALLOWED_HOSTS को एडजस्ट करें।

एक बार जब यह चल जाता है, तो ऑपरेशनल लोड कम होता है। रिलीज़ नोट्स पर नज़र रखें, और हर अपग्रेड से पहले डेटाबेस का डंप लें। रीबूट के बाद स्टैक अपने आप वापस आ जाता है क्योंकि restart: unless-stopped सेट है, बशर्ते Docker सर्विस खुद बूट पर इनेबल्ड हो, और वे Compose स्टैक जो रीबूट के बाद वापस आ जाते हैं उन मामलों को कवर करता है जहाँ ऐसा नहीं होता है।

FAQ

Planka login के बाद हमेशा loading क्यों दिखाता है?

Credentials स्वीकार कर लिए गए थे लेकिन live connection नहीं हुआ। Planka अपना WebSocket URL BASE_URL से बनाता है, इसलिए यदि वह variable अभी भी http://localhost:3000 दिखाता है जबकि आप साइट को https://kanban.example.com पर access कर रहे हैं, तो browser एक ऐसे address पर socket खोलने की कोशिश करता है जो आपकी machine पर मौजूद नहीं है। Developer console में /socket.io/ के लिए विफल requests दिखाई देती हैं। BASE_URL को बिना trailing slash के सटीक public address पर set करें, TRUST_PROXY=true जोड़ें ताकि app आपके reverse proxy से X-Forwarded-Proto header का सम्मान करे, फिर docker compose up -d चलाएं।

मैं पहला Planka admin user कैसे बनाऊं?

Version 1.13 के बाद से कोई भी administrator अपने आप नहीं बनता है। या तो DEFAULT_ADMIN_EMAIL को उसके matching password, name और username variables के साथ set करें और stack start करें, या docker compose run --rm planka npm run db:create-admin-user चलाएं और prompts का उत्तर दें। Shared server पर interactive command अधिक सुरक्षित है, क्योंकि password कभी भी container environment में नहीं जाता जहाँ docker inspect उसे पढ़ सके। बाद में DEFAULT_ADMIN_EMAIL को set रखने से वह account interface से edit और delete होने से सुरक्षित हो जाता है।

Planka attachments और avatars कहाँ store करता है?

Planka 2 में सभी uploaded files container के अंदर /app/data के नीचे रहती हैं, जिसमें attachments, user avatars और board backgrounds शामिल हैं। उस path को एक named volume पर mount करें। यदि यह unmounted है, तो files container की writable layer में रहती हैं और अगली बार container recreate होने पर नष्ट हो जाती हैं, जो हर image upgrade पर होता है। Bind mount भी काम करता है, लेकिन Node process UID 1000 के रूप में चलती है, इसलिए host directory पर sudo chown -R 1000:1000 चलाएं अन्यथा uploads permission error के साथ विफल हो जाएंगे।

self-hosted Planka को कितनी RAM चाहिए?

Project कोई न्यूनतम hardware आवश्यकता प्रकाशित नहीं करता है। Hosting pages पर दोहराया गया 2 vCPU और 4 GB का आंकड़ा एक provider का default है, न कि कोई मापन, और यह एक छोटे board के लिए काफी अधिक है। एक Node process और एक Postgres process ही पूरा workload है, इसलिए 1 vCPU और 2 GB का plan दो से पांच लोगों की टीम के लिए पर्याप्त है। एक सामान्य सप्ताह के बाद docker stats --no-stream चलाएं और अपने आंकड़ों के आधार पर size तय करें। Memory की तुलना में disk पर अधिक ध्यान दें, क्योंकि attachments ही बढ़ते हैं।

मैं data खोए बिना Planka को upgrade कैसे करूं?

Upgrade से ठीक पहले database को dump करें और uploads volume को archive करें, न कि पिछली रात के schedule पर। docker compose exec -T postgres pg_dump -U planka -d planka > planka-db.sql का उपयोग करें, और -T को बनाए रखें ताकि pseudo-terminal redirected output को corrupt न करे। जिन versions को आप छोड़ रहे हैं, उनके release notes पढ़ें, image tag को latest के बजाय एक विशिष्ट release पर बदलें, फिर docker compose pull और docker compose up -d चलाएं और migration के लिए log पर नज़र रखें। Postgres tag को उसके major version पर pinned रहने दें, क्योंकि server किसी भिन्न major version द्वारा लिखे गए data directory को खोलने से मना कर देता है।

#planka#सेल्फ़-होस्टिंग#docker-compose#postgres#traefik