Planka self-host कसे करावे: Docker Compose मार्गदर्शक

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

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

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

तुमच्याकडे Docker Engine आणि Compose प्लगइन असलेला VPS असणे आवश्यक आहे, ज्याकडे एक DNS A record निर्देशित करत असावा. तसेच, त्या सर्व्हरवर TLS (transport layer security) टर्मिनेट करणारे Traefik इन्स्टन्स आधीच कार्यरत असणे आवश्यक आहे. जर Traefik नसेल, तर आधी अनेक Compose अॅप्सच्या पुढे 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 फाईल लिहा

डिरेक्टरी तयार करा आणि तिची मालकी (ownership) स्वतःकडे घ्या, जेणेकरून तुम्हाला या फाईल्स कधीही 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 कनेक्शन स्ट्रिंगमध्ये पेस्ट केली जाते, ती स्ट्रिंग खराब होत नाही. जर base64 पासवर्डमध्ये स्लॅश (/) किंवा ॲट (@) चिन्ह असेल, तर कनेक्शन एरर येते जी चुकीच्या होस्टनेमसारखी वाटते आणि ती शोधण्यात तुमचा एक तास वाया जाऊ शकतो. या पद्धतीचा सविस्तर तपशील 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 लॉगइनची जबाबदारी OIDC प्रोव्हायडरकडे सोपवू शकते, जसे की तुमच्या स्वतःच्या सिंगल साइन-ऑन सर्व्हरवर चालणारे Authentik. अशा वेळी बूटस्ट्रॅप ॲडमिनला केवळ आपत्कालीन वापरासाठी (break-glass account) राखून ठेवा, जेणेकरून प्रोव्हायडर डाऊन असताना त्याचा वापर करता येईल.

BASE_URL आणि hostname जुळत नसल्यास लॉगिन का अयशस्वी होते

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) दिसेल.

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

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

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

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

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

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

या दोघांमधील तुलना bind mounts आणि named volumes मध्ये स्पष्ट केली आहे.

जर तुमच्या प्लॅननुसार अटॅचमेंट्सची साईज डिस्कच्या क्षमतेपेक्षा वाढली, तर Planka त्यांना S3-compatible स्टोरेजवर लिहू शकते, यासाठी S3_ENDPOINT, S3_BUCKET आणि संबंधित की व्हेरिएबल्सचा वापर करावा लागतो. हे एखाद्या होस्ट केलेल्या बकेटला किंवा दुसऱ्या मशीनवरील 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 कनेक्ट होऊ शकला नाही, म्हणून DATABASE_URL ची तुलना तुमच्या .env मधील 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) अलोकेट करते आणि टर्मिनल लेयर स्ट्रीममधील ओळींचे शेवट (line endings) पुन्हा लिहिते. यामुळे तुम्हाला अशी डंप फाईल मिळते जी रिस्टोर करताना मध्येच निकामी होते. ही त्रुटी काही आठवड्यांनंतर समोर येते, जी अत्यंत गैरसोयीची वेळ असते.

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

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

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

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

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

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.

यामुळे काहीही गहाळ होत नाही आणि पुन्हा सुरू केल्याने (restart) काहीही दुरुस्त होत नाही. नवीन 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 जोडा जेणेकरून ॲप तुमच्या reverse proxy कडून येणारे 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 मध्ये असतात, ज्यामध्ये अटॅचमेंट्स, युजर अवतार आणि बोर्ड बॅकग्राउंड्सचा समावेश आहे. तो पाथ एका named volume वर माउंट करा. जर तो माउंट केलेला नसेल, तर फाइल्स कंटेनरच्या writable layer मध्ये राहतात आणि कंटेनर पुन्हा तयार केल्यावर (जे प्रत्येक इमेज अपग्रेडच्या वेळी होते) त्या नष्ट होतात. bind mount देखील काम करते, परंतु Node प्रक्रिया UID 1000 म्हणून चालते, त्यामुळे होस्ट डिरेक्टरीवर sudo chown -R 1000:1000 चालवा, अन्यथा परवानगीच्या त्रुटीमुळे (permission error) अपलोड अयशस्वी होतील.

self-hosted 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 टॅग त्याच्या मेजर आवृत्तीवरच पिन करून ठेवा, कारण वेगळ्या मेजर आवृत्तीने लिहिलेली डेटा डिरेक्टरी सर्व्हर उघडण्यास नकार देतो.