Planka کو Docker کے ذریعے self-host کرنے کا طریقہ

Planka کو self-host کرنے کے فوائد

Planka کو self-host کرنے سے آپ کی ٹیم کو ایک ایسا Kanban بورڈ ملتا ہے جس میں کارڈ، لسٹ اور لیبل کا وہی ماڈل موجود ہے جسے لوگ Trello سے پہلے ہی جانتے ہیں، اور یہ آپ کے کنٹرول میں موجود VPS پر چلتا ہے۔ اس میں نشستوں (seats) کی کوئی حد نہیں ہے اور نہ ہی فی صارف کوئی بلنگ ہے، کیونکہ واحد خرچ سرور کا ہے۔ یہ گائیڈ اسے Traefik کے پیچھے Docker Compose کے ذریعے deploy کرتی ہے، جس میں ڈیٹا کے لیے Postgres اور اپ لوڈ کردہ ہر فائل کے لیے ایک named volume استعمال ہوتا ہے۔

میرے ذہن میں موجود قاری دو سے پانچ افراد پر مشتمل وہ ٹیم ہے جو Trello کے فری ٹیر (free tier) کو چھوڑ رہی ہے۔ اگر آپ ابھی تک یہ فیصلہ کر رہے ہیں کہ کون سا بورڈ استعمال کرنا ہے، تو پہلے self-hosted Trello متبادلات کا موازنہ پڑھیں۔ یہ گائیڈ فرض کرتی ہے کہ فیصلہ ہو چکا ہے اور صرف deploy کرنے کا طریقہ بتاتی ہے۔

آپ کو Docker Engine اور Compose پلگ ان کے ساتھ چلنے والا ایک VPS درکار ہے، جس پر ایک DNS A record پوائنٹ کر رہا ہو۔ آپ کو اسی باکس پر پہلے سے موجود ایک Traefik instance کی بھی ضرورت ہے جو TLS (transport layer security) کو terminate کر رہا ہو۔ اگر Traefik ابھی موجود نہیں ہے، تو پہلے متعدد Compose ایپس کے سامنے Traefik reverse proxy سیٹ اپ کریں، اور اگر نیچے دی گئی فائل غیر مانوس لگے تو VPS کے لیے Docker Compose کی بنیادی باتیں پڑھیں۔

Planka کو کتنے VPS کی ضرورت ہے؟

یہ پروجیکٹ ہارڈویئر کی کوئی کم از کم حد شائع نہیں کرتا، لہذا آپ جو بھی اعداد و شمار پڑھیں انہیں پیمائش کے بجائے ایک نقطہ آغاز سمجھیں۔ 2 vCPU اور 4 GB کا جو اعداد و شمار ہوسٹنگ صفحات پر دہرایا جاتا ہے، وہ فراہم کنندہ کا ایک آرام دہ ڈیفالٹ ہے، نہ کہ پروجیکٹ کی طرف سے ماپا گیا کوئی لازمی تقاضا۔ پانچ افراد کے استعمال والے بورڈ کے لیے یہ گنجائش کافی زیادہ ہے۔

جو کچھ درحقیقت چلتا ہے وہ چھوٹا ہے: ایک Node.js پروسیس جو API اور بلٹ ان فرنٹ اینڈ فراہم کرتا ہے، اور ایک Postgres پروسیس جو ڈیٹا کو محفوظ رکھتا ہے۔ Planka کنٹینر کے اندر ایک تیسرا چھوٹا پراکسی پروسیس چلتا ہے جو اس کی آؤٹ گوئنگ درخواستوں کو فلٹر کرتا ہے۔ 1 vCPU اور 2 GB کا پلان دو سے پانچ افراد کے بورڈ کو سنبھال سکتا ہے، اور زیادہ تر اضافی میموری Postgres کیش کے طور پر استعمال ہوتی ہے۔

میموری کا سائز طے کرنے سے پہلے ڈسک کا سائز طے کریں، کیونکہ اٹیچمنٹس ہی وہ حصہ ہیں جو بڑھتا ہے۔ اس پیراگراف پر بھروسہ کرنے کے بجائے اپنے انسٹینس کی خود پیمائش کریں:

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 خود بخود اس فائل کو پڑھتا ہے اور ویلیوز کو تبدیل (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 جان بوجھ کر استعمال کیا گیا ہے۔ ایک ہیکس سٹرنگ میں صرف ہندسے اور 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 سے میل کھاتا ہو۔ اگر کوئی صارف موجود نہ ہو، تو یہ اس کے ساتھ سیٹ کردہ پاس ورڈ، ڈسپلے نام اور یوزر نیم کا استعمال کرتے ہوئے ایک اکاؤنٹ بنا دیتا ہے۔ یہ عمل خالی ڈیٹا بیس پر پہلی بوٹ کے دوران ہوتا ہے، لہذا یہ ویری ایبلز اکاؤنٹ کو مینج کرنے کے بجائے اسے بوٹ اسٹریپ (bootstrap) کرتے ہیں۔

DEFAULT_ADMIN_EMAIL ایک دوسرا کام بھی کرتا ہے جو اکثر لوگوں کے لیے الجھن کا باعث بنتا ہے۔ جب تک یہ ویری ایبل سیٹ رہتا ہے، اس نام کا اکاؤنٹ انٹرفیس سے کوئی بھی شخص ایڈٹ یا ڈیلیٹ نہیں کر سکتا۔ یہ ایک لاک آؤٹ گارڈ (lock-out guard) ہے، اور یہی وجہ ہے کہ آپ 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 فائل یا کنٹینر کے ماحول (environment) تک نہیں پہنچتا۔ اگر VPS تک ایک سے زیادہ افراد کی رسائی ہو تو یہ طریقہ استعمال کریں۔ یہ کمانڈ depends_on کی وجہ سے پہلے Postgres کو اسٹارٹ کرتی ہے، لہذا یہ ایسے اسٹیک پر بھی کام کرتی ہے جو پہلے کبھی آن نہ ہوا ہو۔

دونوں طریقے آپ کو Planka کے پاس ورڈز دستی طور پر مینج کرنے پر چھوڑ دیتے ہیں، اور اگر یہ آپ کی ٹیم کے پاس موجود چوتھا کریڈینشل سیٹ ہے، تو Planka لاگ ان کو OIDC پرووائیڈر کے سپرد کر سکتا ہے، جیسے کہ Authentik جو آپ کے اپنے single sign-on سرور کے طور پر چل رہا ہو، جبکہ بوٹ اسٹریپ ایڈمن کو اس دن کے لیے ایک 'break-glass' اکاؤنٹ کے طور پر رکھا جا سکتا ہے جب پرووائیڈر ڈاؤن ہو۔

جب BASE_URL ہوسٹ نیم سے مطابقت نہ رکھتا ہو تو لاگ ان کیوں ناکام ہو جاتا ہے

BASE_URL وہ درست ایڈریس ہے جسے صارفین براؤزر میں ٹائپ کرتے ہیں، جس میں اسکیم شامل ہوتی ہے اور آخر میں سلیش (/) نہیں ہوتا۔ اس اسٹیک کے لیے یہ https://kanban.example.com ہے۔ Planka اسی ویلیو سے اپنے لنکس اور WebSocket کنکشن بناتا ہے، جس کا مطلب ہے کہ غلط BASE_URL آپ کو کوئی واضح ایرر نہیں دیتا۔ اس کے بجائے، آپ کو ایک ایسا صفحہ ملتا ہے جو لوڈ تو ہوتا ہے لیکن کبھی مکمل نہیں ہوتا۔

عام صورتحال یہ ہے: آپ اپ اسٹریم مثال کو کاپی کرتے ہیں، BASE_URL=http://localhost:3000 کو ویسے ہی رہنے دیتے ہیں، اور اپنی اصل ڈومین پر HTTPS کے ذریعے سائٹ تک رسائی حاصل کرتے ہیں۔ لاگ ان فارم سبمٹ ہو جاتا ہے اور آپ کے اسناد (credentials) قبول کر لیے جاتے ہیں۔ لیکن بورڈ کبھی ظاہر نہیں ہوتا۔ براؤزر کا ڈویلپر کنسول کھولیں تو آپ کو /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" شامل ہوں، ورنہ آپ کو مختلف وجہ سے وہی پھنسا ہوا اسپنر (stuck spinner) نظر آئے گا۔

بورڈ کو بعد میں نئے ہوسٹ نیم پر منتقل کرنے کا مطلب ہے دو چیزوں کو ایک ساتھ تبدیل کرنا: BASE_URL کی ویلیو اور Traefik کا Host() رول۔ ایک کو تبدیل کریں اور دوسرے کو بھول جائیں، تو آپ دوبارہ اسپنر پر واپس آ جائیں گے۔ Planka کو کسی سب پاتھ جیسے کہ https://example.com/planka سے سرو کرنا ورژن 2.1.0 سے ممکن ہے، جو مارچ 2026 میں ریلیز ہوا تھا۔ پرانے ٹیگز پر، اسے اس کا اپنا سب ڈومین دیں۔

Planka attachments اور avatars کہاں محفوظ کرتا ہے

Planka 2 صارف کی جانب سے اپ لوڈ کردہ تمام مواد کو کنٹینر کے اندر ایک ہی پاتھ /app/data پر محفوظ کرتا ہے۔ منسلکات (attachments)، صارف کے avatars اور بورڈ کے پس منظر کی تصاویر سب اسی کے نیچے موجود ہوتے ہیں۔ ورژن 1 میں تین الگ الگ ڈائریکٹریز استعمال ہوتی تھیں، لہذا پرانی تحریروں سے کاپی کی گئی Compose فائل ایسے پاتھس کو ماؤنٹ کرتی ہے جو اب موجود نہیں ہیں، اور اصل ڈیٹا ڈائریکٹری ان ماؤنٹ رہ جاتی ہے۔

یہ واحد ماؤنٹ اس بات کا تعین کرتا ہے کہ آیا اپ گریڈ کے بعد بورڈ محفوظ رہے گا یا آپ کا وقت ضائع ہوگا۔ اگر /app/data کسی والیم پر نہیں ہے، تو اپ لوڈز کنٹینر کی writable لیئر میں چلے جاتے ہیں۔ جب کنٹینر کو دوبارہ تخلیق کیا جاتا ہے تو وہ لیئر ختم ہو جاتی ہے، اور ہر بار جب آپ امیج ٹیگ تبدیل کرتے ہیں تو کنٹینر دوبارہ تخلیق ہوتا ہے۔ بورڈ واپس آ جاتا ہے اور ٹھیک نظر آتا ہے، کارڈز بھی موجود ہوتے ہیں، لیکن ہر اٹیچمنٹ لنک ناکارہ ہو جاتا ہے، کیونکہ ڈیٹا بیس کی قطاریں اب بھی ایسی فائلوں کی طرف اشارہ کر رہی ہوتی ہیں جو موجود نہیں ہیں۔

اوپر دی گئی 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_ENDPOINT، S3_BUCKET اور متعلقہ کلیدی متغیرات (key variables) کے ذریعے S3 سے مطابقت رکھنے والی اسٹوریج پر لکھ سکتا ہے۔ یہ کسی ہوسٹڈ بکٹ یا کسی دوسرے باکس پر موجود سیلف ہوسٹڈ MinIO آبجیکٹ اسٹور کی طرف اشارہ کر سکتا ہے۔ اس کا فیصلہ ٹیم کے بورڈ بھرنے سے پہلے کریں، کیونکہ یہ ترتیب صرف نئی اپ لوڈز پر لاگو ہوتی ہے۔

اسٹیک کو شروع کریں اور تصدیق کریں کہ یہ کام کر رہا ہے

docker compose pull
docker compose up -d
docker compose ps

docker compose ps کو postgres کے طور پر healthy اور planka کو running کے طور پر دکھانا چاہیے۔ اگر Planka ایک لوپ میں دوبارہ شروع (restart) ہو رہا ہے، تو سب سے پہلے ایپ کے بجائے ڈیٹا بیس کنکشن کو چیک کریں۔

docker compose logs -f planka

ایک صحت مند پہلے بوٹ کے دوران ڈیٹا بیس مائیگریشنز چلتی ہیں اور پھر سرور پورٹ 1337 پر لسننگ (listening) کی اطلاع دیتا ہے۔ لاگ پر بھروسہ کرنے کے بجائے براہ راست Postgres سے پوچھ کر تصدیق کریں کہ اسکیما (schema) واقعی بن گیا ہے:

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 مختص کر دیتا ہے، اور ٹرمینل لیئر اسٹریم میں لائن اینڈنگز کو دوبارہ لکھ دیتی ہے، جس کے نتیجے میں آپ کو ایک ایسی ڈمپ فائل ملتی ہے جو بحالی (restore) کے دوران ناکام ہو جاتی ہے۔ یہ ناکامی ہفتوں بعد ظاہر ہوتی ہے، جو کہ بدترین وقت ہوتا ہے۔

اس کے بعد اپ لوڈز کا مرحلہ ہے۔ پہلے والیوم کا اصل نام تلاش کریں، کیونکہ 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) پر رکھنے کا مشورہ دیتی ہیں۔ دونوں طریقے درست ہیں۔ جو طریقہ درست نہیں ہے وہ ایسا بیک اپ ہے جسے آپ نے کبھی بحال (restore) کر کے نہیں دیکھا، لہذا ایک بار کسی عارضی VPS پر بیک اپ بحال کریں اور تصدیق کریں کہ آپ لاگ ان ہو سکتے ہیں اور اٹیچمنٹ کھول سکتے ہیں۔

ہر ورژن کی تبدیلی سے فوراً پہلے ڈمپ چلائیں۔ گزشتہ رات کا بیک اپ اس بیک اپ جیسا نہیں ہے جو آپ کے مائیگریشن شروع کرنے سے پہلے لیا گیا ہو۔

ٹیگز کو پن کریں اور ریلیز نوٹس پڑھیں

اس فائل میں دونوں امیج ٹیگز کو جان بوجھ کر پن کیا گیا ہے۔

ghcr.io/plankanban/planka:2.1.1 ایک مخصوص ریلیز ہے، جو اگست 2026 تک کرنٹ ہے۔ latest تب تبدیل ہوتا ہے جب اپ اسٹریم (upstream) اسے پبلش کرتا ہے، لہذا ایک معمول کا docker compose pull کسی ایسے وقت میں schema migration لا سکتا ہے جس کا آپ نے انتخاب نہیں کیا تھا۔ اس نمبر کو تبدیل کرنے سے پہلے ریلیز نوٹس پڑھیں، کیونکہ وہیں پر بریکنگ چینجز (breaking changes) اور سیکیورٹی فکسز کی تفصیل دی جاتی ہے۔ ورژن 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.

کچھ بھی ضائع نہیں ہوتا، اور نہ ہی ری اسٹارٹ کرنے سے کچھ ٹھیک ہوتا ہے۔ Postgres کے نئے میجر ورژن پر جانے کا مطلب ہے پرانے ورژن سے ڈمپ (dump) لینا اور نئے ورژن پر ایک نئی ڈیٹا ڈائریکٹری میں اسے ریسٹور (restore) کرنا۔ یہ ایک منصوبہ بند کام ہے جو اسٹیک (stack) کو بند کر کے کیا جاتا ہے، نہ کہ امیج پل (image pull) کا کوئی ضمنی اثر۔

اگر آپ نئے سرے سے شروعات کرنے کے بجائے موجودہ Planka 1.x انسٹالیشن کو منتقل کر رہے ہیں، تو اس اپ گریڈ کا اپنا ایک دستاویزی طریقہ کار پروجیکٹ کی دستاویزات میں موجود ہے، اور پہلے سے لیے گئے بیک اپ کے بغیر ورژن 1 پر واپس جانے کا کوئی راستہ نہیں ہے۔

ناکام ہونے کے طریقے اور وہ پیغامات جو آپ دیکھیں گے

Planka ایک لوپ میں ری اسٹارٹ ہوتا ہے اور لاگ میں ڈیٹا بیس کا نام آتا ہے۔ DATABASE_URL میں موجود اسناد (credentials) Postgres کے ماحول سے مطابقت نہیں رکھتیں۔ یاد رکھیں کہ POSTGRES_PASSWORD صرف اس وقت لاگو ہوتا ہے جب ڈیٹا ڈائریکٹری پہلی بار انیشلائز (initialise) ہوتی ہے، لہذا پہلی بار غلط بوٹ ہونے کے بعد ویری ایبل کو درست کرنے سے کچھ نہیں ہوگا۔ آپ کو db-data والیوم کو ہٹا کر دوبارہ شروع کرنا ہوگا۔

لاگ ان کامیاب ہوتا ہے لیکن بورڈ لوڈ نہیں ہوتا۔ BASE_URL براؤزر بار میں موجود ایڈریس سے میل نہیں کھاتا، یا TRUST_PROXY غائب ہے۔ براؤزر کنسول /socket.io/ پر ناکام ہونے والی درخواستیں دکھاتا ہے۔

باقی سب کچھ ٹھیک کام کرتا ہے لیکن اپ لوڈ ناکام ہو جاتے ہیں۔ ایک بائنڈ ماؤنٹ (bind mount) جس کا مالک root ہے۔ ہوسٹ ڈائریکٹری پر sudo chown -R 1000:1000 چلائیں اور کنٹینر کو ری اسٹارٹ کریں۔

اپ گریڈ کے بعد اٹیچمنٹس غائب ہو گئیں۔ /app/data کسی والیوم پر نہیں تھا، اس لیے فائلیں کنٹینر کی اس تہہ (layer) میں تھیں جسے اپ گریڈ نے تبدیل کر دیا ہے۔ بیک اپ سے فائلیں بحال کریں، اور امیج ٹیگ کو دوبارہ چھیڑنے سے پہلے والیوم شامل کریں۔

Traefik 404 ایرر دیتا ہے۔ کنٹینر proxy نیٹ ورک پر نہیں ہے، یا Host() رول آپ کے DNS ریکارڈ سے میل نہیں کھاتا۔ docker compose config سبٹی ٹیوشن کے بعد لیبلز دکھاتا ہے، جہاں ٹائپنگ کی غلطیاں واضح ہو جاتی ہیں۔

نوٹیفکیشنز یا ویب ہکس موصول نہیں ہوتے۔ Planka 2 اپنی آؤٹ گوئنگ HTTP درخواستیں ایک اندرونی فلٹر کے ذریعے بھیجتا ہے، اور ڈیفالٹ بلاک لسٹ میں localhost اور postgres شامل ہیں۔ اسی ہوسٹ پر موجود کسی دوسرے کنٹینر کے لیے ویب ہک کو ڈیزائن کے مطابق بلاک کیا جا سکتا ہے۔ فلٹر کو ہٹانے کے بجائے OUTGOING_ALLOWED_HOSTS کو ایڈجسٹ کریں۔

ایک بار جب یہ چل جائے تو آپریشنل بوجھ کم ہوتا ہے۔ ریلیز نوٹس پر نظر رکھیں، اور ہر اپ گریڈ سے پہلے ڈیٹا بیس کا ڈمپ (dump) لیں۔ restart: unless-stopped کی وجہ سے ری بوٹ ہونے پر اسٹیک خود بخود واپس آ جاتا ہے، بشرطیکہ Docker سروس خود بوٹ کے وقت فعال (enabled) ہو، اور Compose اسٹیکس جو ری بوٹ کے بعد واپس آ جاتے ہیں ان صورتوں کا احاطہ کرتا ہے جہاں ایسا نہیں ہوتا۔

FAQ

لاگ ان کرنے کے بعد Planka لوڈ کیوں ہوتا رہتا ہے؟

اسناد (credentials) قبول کر لی گئیں لیکن لائیو کنکشن قائم نہیں ہوا۔ Planka اپنا WebSocket URL BASE_URL سے بناتا ہے، لہذا اگر اس ویری ایبل میں اب بھی http://localhost:3000 درج ہے جبکہ آپ سائٹ تک https://kanban.example.com کے ذریعے پہنچ رہے ہیں، تو براؤزر ایک ایسے پتے پر ساکٹ کھولنے کی کوشش کرتا ہے جو آپ کی مشین پر موجود ہی نہیں ہے۔ ڈویلپر کنسول /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 کے نیچے رہتی ہیں، بشمول اٹیچمنٹس، صارف کے اوتار اور بورڈ کے پس منظر۔ اس پاتھ کو ایک named volume پر ماؤنٹ کریں۔ اگر یہ ماؤنٹ نہ ہو تو فائلیں کنٹینر کی writable لیئر میں رہتی ہیں اور اگلی بار کنٹینر کے دوبارہ بننے پر ضائع ہو جاتی ہیں، جو کہ ہر امیج اپ گریڈ پر ہوتا ہے۔ ایک bind mount بھی کام کرتا ہے، لیکن 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 کو برقرار رکھیں تاکہ pseudo-terminal ری ڈائریکٹ شدہ آؤٹ پٹ کو خراب نہ کرے۔ ہر اس ورژن کے ریلیز نوٹس پڑھیں جسے آپ چھوڑ رہے ہیں، امیج ٹیگ کو latest کے بجائے کسی مخصوص ریلیز پر تبدیل کریں، پھر docker compose pull اور docker compose up -d چلائیں اور مائیگریشن کے لیے لاگ کو مانیٹر کریں۔ Postgres ٹیگ کو اس کے میجر ورژن پر پن رکھیں، کیونکہ سرور کسی مختلف میجر ورژن سے لکھی گئی ڈیٹا ڈائریکٹری کو کھولنے سے انکار کر دیتا ہے۔