Docker Compose वापरून Planka कसे self-host करावे?

Planka self-host केल्याने मिळणारे फायदे

Planka self-host केल्यामुळे तुमच्या टीमला Trello सारखेच कार्ड, लिस्ट आणि लेबल मॉडेल असलेले Kanban बोर्ड मिळते, जे तुमच्या नियंत्रणाखालील VPS वर चालते. यामध्ये वापरकर्त्यांच्या संख्येवर कोणतीही मर्यादा नाही आणि प्रति-वापरकर्ता शुल्कही नाही, कारण सर्व्हरचा खर्च हाच एकमेव खर्च असतो. हे मार्गदर्शक Docker Compose आणि Traefik वापरून Planka तैनात (deploy) करते, ज्यामध्ये डेटासाठी Postgres आणि अपलोड केलेल्या फाइल्ससाठी named volume वापरले जाते.

हे मार्गदर्शक अशा टीमसाठी आहे ज्यांची संख्या दोन ते पाच आहे आणि ज्या Trello च्या मोफत प्लॅनमधून बाहेर पडत आहेत. जर तुम्ही अजूनही कोणता बोर्ड वापरायचा हे ठरवत असाल, तर आधी self-hosted Trello पर्यायांची तुलना वाचा. हे मार्गदर्शक तुम्ही निवड निश्चित केली आहे असे गृहीत धरते आणि फक्त deployment वर लक्ष केंद्रित करते.

तुमच्याकडे Docker Engine आणि Compose plugin असलेला VPS असणे आवश्यक आहे, ज्यावर एक DNS A record पॉइंट केलेला असावा. तसेच, त्या सर्व्हरवर TLS (transport layer security) हाताळणारे Traefik चे instance आधीच कार्यरत असणे आवश्यक आहे. जर Traefik अजून सेट केले नसेल, तर आधी अनेक Compose ॲप्सच्या पुढे Traefik reverse proxy सेट करा आणि जर खालील फाइल तुम्हाला नवीन वाटत असेल, तर VPS साठी Docker Compose ची मूलभूत माहिती वाचा.

Planka साठी किती VPS क्षमतेची आवश्यकता आहे?

या प्रकल्पाने हार्डवेअरच्या किमान मर्यादा अधिकृतपणे जाहीर केलेल्या नाहीत, त्यामुळे तुम्ही वाचलेली कोणतीही आकडेवारी ही एक सुरुवात समजा, अंतिम मापदंड नाही. होस्टिंग पेजेसवर वारंवार दिसणारी 2 vCPU आणि 4 GB ची आकडेवारी ही प्रोव्हायडरची एक सोयीस्कर डीफॉल्ट निवड आहे, प्रकल्पाने मोजलेली गरज नाही. पाच लोक वापरत असलेल्या बोर्डसाठी ही क्षमता खूप जास्त आहे.

प्रत्यक्षात चालणारी प्रक्रिया लहान आहे: API आणि बिल्ट फ्रंटएंड सर्व्ह करण्यासाठी एक Node.js प्रोसेस आणि डेटा साठवण्यासाठी एक Postgres प्रोसेस. Planka कंटेनरमध्ये बाहेरील विनंत्या फिल्टर करण्यासाठी तिसरी एक लहान प्रॉक्सी प्रोसेस चालते. 1 vCPU आणि 2 GB चा प्लॅन दोन ते पाच व्यक्तींच्या बोर्डसाठी पुरेसा आहे आणि उरलेली बहुतेक मेमरी Postgres कॅशे म्हणून वापरली जाते. बोर्ड हा एक हलका शेजारी आहे, त्यामुळे जर त्याच VPS वर तुमच्या टीमची कागदपत्रेही ठेवायची असतील, तर आधी त्या ॲपसाठी आकार निश्चित करा: AFFiNE ला Notion-शैलीतील वर्कस्पेस म्हणून चालवण्यासाठी Planka च्या आधीच काही गिगाबाइट्सची गरज भासते.

मेमरीचा आकार ठरवण्यापूर्वी डिस्कचा आकार निश्चित करा, कारण अटॅचमेंट्समुळेच डेटा वाढतो. या परिच्छेदावर विश्वास ठेवण्याऐवजी तुमच्या स्वतःच्या इन्स्टन्सचे मोजमाप करा:

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

पहिली कमांड प्रत्येक कंटेनरची चालू मेमरी आणि CPU वापर दर्शवते. दुसरी कमांड प्रत्येक व्हॉल्यूम किती जागा व्यापत आहे हे दाखवते. दोन्ही नोंदी इन्स्टॉल केलेल्या दिवशी न घेता, एका सामान्य कामकाजाच्या आठवड्यानंतर घ्या, कारण रिकाम्या बोर्डवरून तुमच्या टीमच्या वापराचा अंदाज येत नाही.

Compose फाईल लिहा

डिरेक्टरी तयार करा आणि तिची मालकी घ्या, जेणेकरून तुम्हाला या फाईल्स कधीही sudo द्वारे एडिट करण्याची गरज पडणार नाही.

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

Compose फाईलच्या शेजारी .env फाईलमध्ये सीक्रेट्स तयार करा. Compose ही फाईल आपोआप वाचते आणि त्यातील व्हॅल्यूज सबस्टिट्यूट करते.

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 हे मुद्दाम वापरले आहे. हेक्स स्ट्रिंगमध्ये फक्त अंक आणि a ते f ही अक्षरे असतात, त्यामुळे ती ज्या DATABASE_URL कनेक्शन स्ट्रिंगमध्ये पेस्ट केली जाते, ती खराब होत नाही. बेस64 पासवर्डमध्ये स्लॅश किंवा 'at' चिन्ह असल्यास कनेक्शन एरर येते, जी चुकीच्या होस्टनेमसारखी वाटते आणि त्यामुळे तुमचा एक तास वाया जाऊ शकतो. याच्या व्यापक पद्धतीबद्दल Compose फाईलमध्ये सीक्रेट्स न ठेवणे येथे अधिक माहिती दिली आहे.

आता docker-compose.yml. जिथे kanban.example.com दोनदा आले आहे, तिथे तुमचे स्वतःचे होस्टनेम लिहा.

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 सर्व्हिसवर कोणताही ports: ब्लॉक नाही. Traefik हे कंटेनरपर्यंत proxy नेटवर्कद्वारे पोहोचते, त्यामुळे पोर्ट 1337 कधीही होस्टवर पब्लिश होत नाही. ते पब्लिश केल्यास कोणालाही तुमच्या प्रॉक्सी आणि प्रमाणपत्राला बगल देण्याचा मार्ग मिळेल.
• loadbalancer.server.port=1337 हे कंटेनरमधील पोर्टचे नाव दर्शवते. Planka 1337 वर लिसन करते आणि अपस्ट्रीम उदाहरणात ते 3000 वर पोहोचते कारण ते पोर्ट होस्टवर मॅप केलेले असते. येथे कोणतेही होस्ट मॅपिंग नसल्यामुळे, Traefik ला कंटेनर पोर्टबद्दल माहिती देणे आवश्यक आहे.
• condition: service_healthy हे Postgres हेल्थचेकसोबत जोडलेले आहे. त्याशिवाय, डेटाबेस कनेक्शन स्वीकारण्यापूर्वीच Planka सुरू होते, त्याची पहिली क्वेरी अपयशी ठरते आणि ते बंद होते, जे क्रॅश लूपसारखे दिसते. याची कार्यपद्धती Compose हेल्थचेक्स आणि स्टार्टअप ऑर्डरिंग मध्ये दिली आहे.
• डेटाबेस सर्व्हिसला मुद्दाम postgres असे नाव दिले आहे. Planka 2 त्याच्या स्वतःच्या आउटगोइंग विनंत्या एका अंतर्गत फिल्टरद्वारे राउट करते, ज्याची डीफॉल्ट ब्लॉक लिस्ट localhost,postgres आहे. सर्व्हिसचे नाव बदलल्यास तुम्ही तुमचा डेटाबेस त्या लिस्टवरून नकळत काढून टाकाल.

काहीही सुरू करण्यापूर्वी Compose ला तुमचे सीक्रेट्स दिसत आहेत का ते तपासा:

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

हे कमांड .env व्हॅल्यूज आधीच सबस्टिट्यूट केलेली फाईल प्रिंट करते. रिकामी व्हॅल्यू म्हणजे Compose ही .env फाईल वाचत नाहीये, याचे कारण सहसा असे असते की तुम्ही वेगळ्या डिरेक्टरीमधून कमांड चालवत आहात.

अ‍ॅडमिन बूटस्ट्रॅप व्हेरिएबल्स प्रत्यक्षात काय करतात

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 लॉगिन्सचे अधिकार तुमच्या स्वतःच्या सिंगल साइन-ऑन सर्व्हरवर चालणाऱ्या Authentik सारख्या OIDC प्रोव्हायडरकडे सोपवू शकते. अशा वेळी बूटस्ट्रॅप अ‍ॅडमिनला 'ब्रेक-ग्लास' खाते म्हणून ठेवा, जे प्रोव्हायडर डाऊन असताना उपयोगी पडेल.

BASE_URL जुळत नसल्यास लॉगिन का निकामी होते

BASE_URL हा तो अचूक पत्ता आहे जो वापरकर्ते ब्राउझरमध्ये टाईप करतात, ज्यामध्ये स्कीमचा समावेश असतो आणि शेवटी स्लॅश नसतो. या स्टॅकसाठी तो https://kanban.example.com असा आहे. Planka स्वतःच्या लिंक्स आणि WebSocket कनेक्शन याच व्हॅल्यूवरून तयार करते, याचा अर्थ असा की चुकीच्या BASE_URL मुळे तुम्हाला स्पष्ट त्रुटी (error) दिसत नाही. त्याऐवजी, पेज लोड होते पण ते पूर्णपणे लोड होणे कधीच थांबत नाही.

सामान्य प्रकार असा आहे: तुम्ही अपस्ट्रीम उदाहरण कॉपी करता, BASE_URL=http://localhost:3000 तसेच ठेवता आणि तुमच्या खऱ्या डोमेनवर HTTPS द्वारे साईट उघडता. लॉगिन फॉर्म सबमिट होतो आणि तुमची क्रेडेन्शियल्स स्वीकारली जातात. पण बोर्ड कधीच दिसत नाही. ब्राउझर डेव्हलपर कन्सोल उघडल्यास तुम्हाला /socket.io/ कडे जाणाऱ्या विनंत्या निकामी होताना दिसतील, कारण क्लायंटला त्याचे लाईव्ह कनेक्शन localhost:3000 वर उघडण्यास सांगितले गेले होते, आणि तुमच्या लॅपटॉपवर तो पत्ता अस्तित्वातच नाही.

TRUST_PROXY=true ही याच समस्येची दुसरी बाजू आहे. Planka हे Traefik च्या मागे असते, त्यामुळे प्रत्येक विनंती प्रॉक्सीच्या पत्त्यावरून Docker नेटवर्कमध्ये साध्या HTTP द्वारे येते. TRUST_PROXY शिवाय, ॲप Traefik ने सेट केलेले X-Forwarded-Proto आणि X-Forwarded-For हेडर दुर्लक्षित करते, त्यामुळे त्याला वाटते की कनेक्शन असुरक्षित आहे आणि ते प्रत्येक क्लायंटला एकाच सामायिक IP ॲड्रेसप्रमाणे वागवते. हे सेट केल्यावर, ॲप ते हेडर्स वाचते आणि स्कीमबद्दल ब्राउझरशी सहमत होते.

Traefik कोणत्याही अतिरिक्त कॉन्फिगरेशनशिवाय WebSockets प्रॉक्सी करते, म्हणूनच येथे त्याला प्राधान्य दिले जाते. nginx वर, socket.io ला स्वतःचा location ब्लॉक आवश्यक असतो ज्यामध्ये proxy_set_header Upgrade $http_upgrade आणि proxy_set_header Connection "upgrade" समाविष्ट असतात, अन्यथा तुम्हाला वेगळ्या कारणाने तोच फिरणारा स्पिनर (stuck spinner) दिसेल.

बोर्ड नंतर नवीन होस्टनेमवर हलवताना दोन गोष्टी एकत्र बदलणे आवश्यक असते: BASE_URL व्हॅल्यू आणि Traefik Host() नियम. एक बदलला आणि दुसरा विसरलात, तर तुम्ही पुन्हा स्पिनरवर येऊन पोहोचता. Planka ला https://example.com/planka सारख्या सबपाथवरून सर्व्ह करणे मार्च 2026 मध्ये रिलीज झालेल्या 2.1.0 आवृत्तीपासून शक्य आहे. जुन्या टॅग्सवर, त्याला स्वतःचे सबडोमेन द्या.

Planka अटॅचमेंट्स आणि अवतारांची साठवणूक कोठे करतो

Planka 2 मध्ये वापरकर्ता अपलोड करत असलेली सर्व माहिती कंटेनरमधील एकाच पाथवर साठवली जाते: /app/data. अटॅचमेंट्स, वापरकर्त्यांचे अवतार आणि बोर्डची बॅकग्राउंड इमेजेस हे सर्व याच पाथखाली असतात. व्हर्जन 1 मध्ये तीन स्वतंत्र डिरेक्टरीज वापरल्या जात होत्या, त्यामुळे जुन्या लेखामधून कॉपी केलेली Compose फाईल असे पाथ माउंट करते जे आता अस्तित्वात नाहीत आणि प्रत्यक्ष डेटा डिरेक्टरी माउंट न होता तशीच राहते.

तो एकच माउंट म्हणजे अपग्रेडनंतर टिकून राहणारा बोर्ड आणि वाया गेलेला दुपारचा वेळ यातील फरक आहे. जर /app/data व्हॉल्यूमवर नसेल, तर अपलोड्स कंटेनरच्या रायटेबल लेयरमध्ये (writable layer) साठवले जातात. जेव्हा कंटेनर पुन्हा तयार (recreate) केला जातो, तेव्हा तो लेयर नष्ट होतो आणि तुम्ही दरवेळी इमेज टॅग बदलता तेव्हा कंटेनर पुन्हा तयार केला जातो. बोर्ड पुन्हा व्यवस्थित दिसतो, सर्व कार्ड्स तिथे असतात, पण प्रत्येक अटॅचमेंट लिंक निकामी झालेली असते, कारण डेटाबेस रोज (rows) अशा फाईल्सकडे निर्देश करत असतात ज्या आता अस्तित्वात नाहीत.

वरील Compose फाईलमधील नेमड व्हॉल्यूम (named volume) हे टाळते. बाइंड माउंट (bind mount) देखील काम करते आणि सामान्य टूल्स वापरून फाईल्सचा बॅकअप घेणे सोपे करते, परंतु त्यासाठी एक अतिरिक्त पायरी आवश्यक असते. कंटेनरमधील Node प्रोसेस UID 1000 म्हणून चालते, त्यामुळे root च्या मालकीची होस्ट डिरेक्टरी पहिल्या अपलोडच्या वेळी परमिशन एरर देते:

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

या दोघांमधील तडजोड bind mounts against named volumes मध्ये स्पष्ट केली आहे.

जर तुमच्या प्लॅननुसार अटॅचमेंट्स डिस्कच्या क्षमतेपेक्षा जास्त वाढल्या, तर Planka त्यांना S3-सुसंगत स्टोरेजवर लिहू शकतो, यासाठी S3_ENDPOINT, S3_BUCKET आणि संबंधित की व्हेरिएबल्सचा वापर करावा लागतो. हे एखाद्या होस्ट केलेल्या बकेटकडे किंवा दुसऱ्या मशीनवरील a self-hosted MinIO object store कडे निर्देश करू शकते. टीमने बोर्ड भरण्यापूर्वीच याचा निर्णय घ्या, कारण हे सेटिंग फक्त नवीन अपलोड्सना लागू होते.

स्टॅक सुरू करा आणि तो योग्यरित्या काम करत असल्याची खात्री करा

docker compose pull
docker compose up -d
docker compose ps

docker compose ps ने postgres हे healthy म्हणून आणि planka हे running म्हणून दाखवले पाहिजे. जर Planka वारंवार रीस्टार्ट होत असेल, तर सर्वात आधी ॲपऐवजी डेटाबेस कनेक्शन तपासा.

docker compose logs -f planka

यशस्वीरित्या सुरू झाल्यावर, सिस्टिम डेटाबेस मायग्रेशन्स पूर्ण करते आणि सर्व्हर पोर्ट 1337 वर ऐकत (listening) असल्याचे दर्शवते. लॉगवर विश्वास ठेवण्याऐवजी थेट Postgres ला विचारून स्कीमा तयार झाला आहे का ते तपासा:

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

जर टेबलच्या यादीत board आणि card समाविष्ट असतील, तर याचा अर्थ मायग्रेशन्स यशस्वीरित्या पूर्ण झाले आहेत. "Did not find any relations" असा संदेश आल्यास Planka कनेक्ट होऊ शकला नाही, अशा वेळी तुमच्या .env मधील DATABASE_URL ची तुलना POSTGRES_USER आणि POSTGRES_PASSWORD मूल्यांशी करा.

त्यानंतर, VPS वरून नाही तर तुमच्या स्वतःच्या मशीनवरून रूट तपासा:

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

HTTP/2 200 चा अर्थ असा की Traefik कडे प्रमाणपत्र आहे आणि तो कंटेनरपर्यंत पोहोचत आहे. Traefik कडून 404 एरर येत असल्यास, याचा अर्थ राउटर लेबल्स जुळत नाहीत, जे सहसा कंटेनर proxy नेटवर्कशी जोडलेला नसल्यामुळे घडते. आता साइट उघडा आणि ॲडमिन अकाउंट वापरून लॉग इन करा.

प्रत्येक व्हर्जन अपडेटपूर्वी 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) अलोकेट करतो आणि टर्मिनल लेयर स्ट्रीममधील लाइन एंडिंग्स पुन्हा लिहितो. परिणामी, तुम्हाला अशी डंप फाइल मिळते जी रिस्टोर करताना मध्येच निकामी होते. ही त्रुटी काही आठवड्यांनंतर समोर येते, जी अत्यंत गैरसोयीची वेळ असते.

त्यानंतर, अपलोड्सचा विचार करा. प्रथम व्हॉल्यूमचे खरे नाव शोधा, कारण Compose त्याला प्रोजेक्ट डिरेक्टरीच्या नावाचा उपसर्ग (prefix) जोडतो.

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 जॉबवर ठेवले जातात. दोन्ही पद्धती योग्य आहेत. जी बॅकअप तुम्ही कधीही रिस्टोर करून पाहिली नाही, ती बॅकअप सुरक्षित नाही. त्यामुळे एकदा एका स्क्रॅच VPS वर ती रिस्टोर करून पहा आणि तुम्ही लॉग इन करू शकता तसेच अटॅचमेंट उघडू शकता याची खात्री करा. अपलोड स्वीकारणाऱ्या प्रत्येक Compose ॲपमध्ये हे दोन स्टोरेज प्रकार असतात. त्यामुळे जर तुम्ही भविष्यात तुमच्या सपोर्ट डेस्कसोबतच Chatwoot एकाच सर्व्हरवर ठेवले, तर तुम्ही येथे तयार केलेली कार्यपद्धती केवळ व्हॉल्यूमची नावे बदलून पुन्हा वापरता येईल.

प्रत्येक व्हर्जन बदलण्यापूर्वी लगेच डंप घ्या. काल रात्री घेतलेली बॅकअप आणि तुम्ही आता करणार असलेल्या मायग्रेशनपूर्वी घेतलेली बॅकअप यात फरक असतो.

टॅग्स पिन करा आणि रिलीज नोट्स वाचा

त्या फाईलमधील दोन्ही इमेज टॅग्स हेतुपुरस्सर पिन केलेले आहेत.

ghcr.io/plankanban/planka:2.1.1 हे एक विशिष्ट रिलीज आहे, जे ऑगस्ट 2026 पर्यंत अद्ययावत आहे. latest हे अपस्ट्रीमने नवीन आवृत्ती प्रसिद्ध केल्यावर बदलते, त्यामुळे नियमित docker compose pull केल्यास तुमच्या नकळत स्कीमा मायग्रेशन (schema migration) होऊ शकते. तो क्रमांक बदलण्यापूर्वी रिलीज नोट्स वाचा, कारण तिथेच ब्रेकिंग चेंजेस आणि सुरक्षेच्या उपाययोजनांची माहिती दिलेली असते. आवृत्ती 2.0.3 ही सुरक्षा रिलीज म्हणून प्रसिद्ध करण्यात आली होती; अशा प्रकारच्या गोष्टी अपघाताने स्वीकारण्यापेक्षा वाचून समजून घेणे केव्हाही चांगले. येथे इमेज पिन करणे सोपे आहे कारण अपस्ट्रीम स्वतः इमेजेस प्रसिद्ध करते. ज्या प्रोजेक्टमध्ये इमेजेस उपलब्ध नसतात, तिथे तुम्हाला अधिक शिस्त पाळावी लागते, जसे की git टॅगवरून चेक-आउट करून बॉक्सवर openGym तयार करणे.

postgres:16-alpine हे एका मेजर व्हर्जनला पिन केलेले आहे, ज्याचे कारण अधिक गंभीर आहे. Postgres आपला डेटा डिरेक्टरी फॉरमॅट मेजर व्हर्जनशी जोडून ठेवते आणि सर्व्हर दुसऱ्या व्हर्जनने लिहिलेली डिरेक्टरी उघडण्यास नकार देतो. जर तुम्ही postgres:latest असे लिहिले आणि टॅग 17 वर गेला, तर कंटेनर सुरू होणार नाही:

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.

यात काहीही गमावले जात नाही आणि पुन्हा सुरू केल्याने काहीही दुरुस्त होत नाही. Postgres च्या नवीन मेजर व्हर्जनवर जाणे म्हणजे जुन्या व्हर्जनमधून डंप घेणे आणि नवीन व्हर्जनच्या रिकाम्या डेटा डिरेक्टरीमध्ये तो रिस्टोर करणे होय. हे काम स्टॅक बंद असताना नियोजित पद्धतीने करायचे असते, ते इमेज पुल करण्याचा अनपेक्षित परिणाम नसावा.

जर तुम्ही नवीन सुरुवात करण्याऐवजी अस्तित्वात असलेले Planka 1.x इन्स्टॉल अपग्रेड करत असाल, तर त्या अपग्रेडची स्वतःची प्रक्रिया प्रोजेक्ट डॉक्युमेंटेशनमध्ये दिलेली आहे. आधी बॅकअप घेतल्याशिवाय आवृत्ती 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 सबस्टिट्यूशननंतरचे लेबल्स दाखवते, जिथे टायपिंगच्या चुका स्पष्टपणे दिसतात.

नोटिफिकेशन्स किंवा वेबहुक्स पोहोचत नाहीत. Planka 2 त्याच्या आउटगोइंग HTTP विनंत्या एका अंतर्गत फिल्टरद्वारे पाठवते आणि डीफॉल्ट ब्लॉक लिस्टमध्ये localhost आणि postgres समाविष्ट आहेत. त्याच होस्टवरील दुसऱ्या कंटेनरला उद्देशून असलेला वेबहूक डिझाइननुसार ब्लॉक केला जाऊ शकतो. फिल्टर काढून टाकण्याऐवजी OUTGOING_ALLOWED_HOSTS मध्ये बदल करा.

एकदा का ते सुरू झाले की, ऑपरेशनल लोड कमी असतो. रिलीज नोट्सवर लक्ष ठेवा आणि प्रत्येक अपग्रेडपूर्वी डेटाबेसचा डंप घ्या. रीबूटनंतर स्टॅक आपोआप पुन्हा सुरू होतो कारण restart: unless-stopped सेट केलेले असते, बशर्ते Docker सर्व्हिस स्वतः बूट वेळी इनेबल केलेली असेल. रीबूटनंतर पुन्हा सुरू होणारे Compose स्टॅक्स मध्ये अशा प्रकरणांची माहिती दिली आहे जिथे हे घडत नाही.

FAQ

लॉग इन केल्यानंतर Planka कायमचे लोड का होत राहते?

तुमची क्रेडेन्शियल्स स्वीकारली जातात, परंतु लाइव्ह कनेक्शन होत नाही. Planka त्याच्या WebSocket URL ची निर्मिती BASE_URL वरून करते. त्यामुळे, जर तुम्ही https://kanban.example.com वरून साइट उघडत असाल आणि त्या व्हेरिएबलमध्ये अजूनही http://localhost:3000 असेल, तर ब्राउझर अशा पत्त्यावर सॉकेट उघडण्याचा प्रयत्न करतो जो तुमच्या मशीनवर अस्तित्वात नाही. डेव्हलपर कन्सोलमध्ये /socket.io/ कडे जाणाऱ्या विनंत्या अयशस्वी झाल्याचे दिसते. BASE_URL मध्ये कोणताही ट्रेलिंग स्लॅश न देता अचूक सार्वजनिक पत्ता सेट करा, TRUST_PROXY=true जोडा जेणेकरून ॲप तुमच्या रिव्हर्स प्रॉक्सीकडून येणारे X-Forwarded-Proto हेडर स्वीकारेल आणि त्यानंतर docker compose up -d रन करा.

मी पहिला Planka ॲडमिन युजर कसा तयार करू?

आवृत्ती 1.13 पासून कोणताही ॲडमिनिस्ट्रेटर आपोआप तयार होत नाही. एकतर DEFAULT_ADMIN_EMAIL आणि त्यासोबतचे पासवर्ड, नाव आणि युजरनेम व्हेरिएबल्स सेट करून स्टॅक सुरू करा, किंवा docker compose run --rm planka npm run db:create-admin-user रन करा आणि विचारलेल्या प्रश्नांची उत्तरे द्या. शेअर केलेल्या सर्व्हरवर इंटरअॅक्टिव्ह कमांड वापरणे अधिक सुरक्षित आहे, कारण पासवर्ड कंटेनरच्या एन्व्हायरनमेंटमध्ये जात नाही जिथे docker inspect तो वाचू शकेल. त्यानंतरही DEFAULT_ADMIN_EMAIL सेट ठेवल्यास, तो अकाउंट इंटरफेसवरून एडिट किंवा डिलीट करण्यापासून सुरक्षित राहते.

Planka अटॅचमेंट्स आणि अवतारांची साठवणूक कुठे करते?

Planka 2 मध्ये सर्व अपलोड केलेल्या फाइल्स कंटेनरच्या आत /app/data मध्ये असतात, ज्यामध्ये अटॅचमेंट्स, युजर अवतार आणि बोर्ड बॅकग्राउंड्सचा समावेश आहे. तो पाथ एका नेमड व्हॉल्यूमवर माउंट करा. जर तो माउंट केलेला नसेल, तर फाइल्स कंटेनरच्या रायटेबल लेयरमध्ये राहतात आणि कंटेनर पुन्हा तयार केल्यावर (जे प्रत्येक इमेज अपग्रेडच्या वेळी घडते) त्या नष्ट होतात. बाइंड माउंट देखील काम करते, परंतु Node प्रोसेस UID 1000 म्हणून चालते, त्यामुळे होस्ट डिरेक्टरीवर sudo chown -R 1000:1000 रन करा, अन्यथा परवानगीच्या त्रुटीमुळे (permission error) अपलोड अयशस्वी होतील.

सेल्फ-होस्टेड Planka ला किती RAM लागते?

प्रोजेक्टद्वारे कोणतीही किमान हार्डवेअर मर्यादा जाहीर केलेली नाही. होस्टिंग पेजेसवर दिसणारा 2 vCPU आणि 4 GB चा आकडा हा प्रोव्हायडरचा डिफॉल्ट आहे, मोजमाप नाही; लहान बोर्डसाठी हे प्रमाण पुरेसे आहे. एक Node प्रोसेस आणि एक Postgres प्रोसेस एवढाच एकूण वर्कलोड असतो, त्यामुळे 1 vCPU आणि 2 GB चा प्लॅन दोन ते पाच जणांच्या टीमसाठी पुरेसा आहे. सामान्य आठवड्यानंतर docker stats --no-stream रन करा आणि तुमच्या स्वतःच्या आकडेवारीनुसार आकार निश्चित करा. मेमरीपेक्षा डिस्कवर अधिक लक्ष ठेवा, कारण अटॅचमेंट्समुळेच डिस्कचा वापर वाढतो.

डेटा न गमावता मी Planka अपग्रेड कसा करू?

अपग्रेडच्या लगेच आधी डेटाबेस डंप करा आणि अपलोड्स व्हॉल्यूमची आर्काइव्ह तयार करा, काल रात्रीच्या शेड्युलवर अवलंबून राहू नका. docker compose exec -T postgres pg_dump -U planka -d planka > planka-db.sql वापरा आणि -T कायम ठेवा, जेणेकरून स्यूडो-टर्मिनल रिडायरेक्ट केलेल्या आउटपुटला करप्ट करणार नाही. तुम्ही वगळलेल्या प्रत्येक आवृत्तीचे रिलीज नोट्स वाचा, इमेज टॅग latest ऐवजी विशिष्ट रिलीजवर बदला, त्यानंतर docker compose pull आणि docker compose up -d रन करा आणि मायग्रेशनसाठी लॉग मॉनिटर करा. Postgres टॅग त्याच्या मेजर व्हर्जनवरच पिन करून ठेवा, कारण वेगळ्या मेजर व्हर्जनने लिहिलेली डेटा डिरेक्टरी सर्व्हर उघडण्यास नकार देतो.