SSD Nodes Learn Hosting plans →
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-30

Planka ను Docker Compose ద్వారా self-host చేయడం ఎలా

Planka ను VPS లో డిప్లాయ్ చేసే విధానం ఇక్కడ ఉంది. Postgres, Traefik కాన్ఫిగరేషన్ మరియు లాగిన్ సమస్యలకు కారణమయ్యే BASE_URL సెట్టింగ్ వంటి ముఖ్యమైన అంశాలను ఇందులో చూడండి.

Planka ను self-host చేయడం వల్ల కలిగే ప్రయోజనాలు

Planka ను self-host చేయడం ద్వారా, మీ బృందానికి Trello లో ఇప్పటికే తెలిసిన కార్డ్, లిస్ట్ మరియు లేబుల్ మోడల్‌తో కూడిన Kanban బోర్డు లభిస్తుంది. ఇది మీరు నియంత్రించే VPS పై నడుస్తుంది. ఇందులో సీట్ల పరిమితి లేదా ప్రతి వినియోగదారునికి బిల్లింగ్ ఉండదు, ఎందుకంటే సర్వర్ ఖర్చు మాత్రమే ఉంటుంది. ఈ గైడ్ దీనిని Traefik వెనుక Docker Compose ద్వారా, డేటా కోసం Postgres ను మరియు వినియోగదారులు అప్‌లోడ్ చేసే ప్రతి ఫైల్ కోసం ఒక named volume ను ఉపయోగించి డిప్లాయ్ చేస్తుంది.

Trello యొక్క ఉచిత ప్లాన్ నుండి బయటకు వస్తున్న ఇద్దరు నుండి ఐదుగురు సభ్యులున్న బృందాల కోసం ఈ గైడ్ రూపొందించబడింది. మీరు ఏ బోర్డును ఉపయోగించాలో ఇంకా నిర్ణయించుకోకపోతే, ముందుగా self-hosted Trello ప్రత్యామ్నాయాల పోలికను చదవండి. ఈ గైడ్ మీరు ఇప్పటికే నిర్ణయం తీసుకున్నారని భావించి, కేవలం డిప్లాయ్‌మెంట్ ప్రక్రియను మాత్రమే వివరిస్తుంది.

మీకు Docker Engine మరియు Compose plugin ఉన్న VPS, మరియు దానికి పాయింట్ చేసే DNS A record అవసరం. అలాగే, ఆ సర్వర్‌లో ఇప్పటికే TLS (transport layer security) ను terminate చేస్తున్న Traefik ఇన్‌స్టాన్స్ ఉండాలి. ఒకవేళ Traefik ఇంకా లేకపోతే, ముందుగా అనేక Compose అప్లికేషన్ల ముందు Traefik reverse proxy ని సెటప్ చేయండి, మరియు కింద ఉన్న ఫైల్ మీకు కొత్తగా అనిపిస్తే VPS కోసం Docker Compose ప్రాథమిక అంశాలను చదవండి.

Planka కు ఎంత VPS అవసరం?

ఈ ప్రాజెక్ట్ ఎటువంటి కనీస హార్డ్‌వేర్ అవసరాలను అధికారికంగా ప్రకటించలేదు, కాబట్టి మీరు ఎక్కడైనా చూసే సంఖ్యలను కొలమానంగా కాకుండా ఒక ప్రాథమిక అంచనాగా మాత్రమే పరిగణించండి. హోస్టింగ్ పేజీలలో తరచుగా కనిపించే 2 vCPU మరియు 4 GB అనేది ప్రొవైడర్లు సూచించే ఒక సాధారణ ప్రమాణం మాత్రమే, ప్రాజెక్ట్ నిర్ధారించిన అవసరం కాదు. ఐదుగురు వ్యక్తులు ఉపయోగించే బోర్డుకు ఇది చాలా ఎక్కువ.

వాస్తవానికి నడిచేవి చాలా తక్కువ: API మరియు బిల్డ్ చేసిన frontend ను అందించే ఒక Node.js ప్రాసెస్, మరియు డేటాను నిల్వ చేసే ఒక Postgres ప్రాసెస్. Planka కంటైనర్ లోపల బయటకు వెళ్లే అభ్యర్థనలను ఫిల్టర్ చేయడానికి మూడవ చిన్న proxy ప్రాసెస్ నడుస్తుంది. 1 vCPU మరియు 2 GB ప్లాన్ ఇద్దరు నుండి ఐదుగురు వ్యక్తులు ఉన్న బోర్డుకు సరిపోతుంది, మరియు మిగిలిన మెమరీలో ఎక్కువ భాగం Postgres cache గా ఉపయోగపడుతుంది. ఒక బోర్డు తక్కువ వనరులను తీసుకుంటుంది, కాబట్టి అదే VPS లో మీ టీమ్ డాక్యుమెంట్లను కూడా ఉంచాలనుకుంటే, ముందుగా ఆ అప్లికేషన్ కోసం పరిమాణాన్ని నిర్ణయించండి: Notion-style workspace గా AFFiNE ను రన్ చేయడం కోసం Planka తో సంబంధం లేకుండానే కొన్ని GB ల మెమరీ అవసరమవుతుంది.

మెమరీని నిర్ణయించే ముందు డిస్క్ పరిమాణాన్ని లెక్కించండి, ఎందుకంటే అటాచ్‌మెంట్లు పెరిగే కొద్దీ డిస్క్ స్థలం అవసరమవుతుంది. ఈ పేరాను నమ్మే బదులు మీ స్వంత instance ను కొలవండి:

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

మొదటి కమాండ్ ప్రతి కంటైనర్ యొక్క లైవ్ మెమరీ మరియు CPU వినియోగాన్ని చూపుతుంది. రెండవది ప్రతి volume ఎంత స్థలాన్ని ఆక్రమిస్తుందో చూపుతుంది. ఈ కొలతలను ఇన్‌స్టాల్ చేసిన రోజున కాకుండా, ఒక సాధారణ పని వారం తర్వాత తీసుకోండి, ఎందుకంటే ఖాళీగా ఉన్న బోర్డు మీ టీమ్ పనితీరు గురించి ఏమీ చెప్పదు.

Compose ఫైల్‌ను వ్రాయండి

డైరెక్టరీని సృష్టించి, దానికి యాజమాన్యాన్ని తీసుకోండి, తద్వారా మీరు ఈ ఫైళ్లను ఎప్పుడూ sudo ద్వారా ఎడిట్ చేయాల్సిన అవసరం ఉండదు.

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

Compose ఫైల్‌ పక్కనే ఉన్న .env ఫైల్‌లోకి రహస్యాలను (secrets) జనరేట్ చేయండి. 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 హోస్ట్‌నేమ్‌తో సరిపోలకపోతే లాగిన్‌లు ఎందుకు విఫలమవుతాయి

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 లేకపోతే, అప్లికేషన్ 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" ఉండాలి, లేకపోతే వేరే కారణంతో అదే విధంగా లోడింగ్ స్పిన్నర్ ఆగిపోతుంది.

తర్వాత బోర్డును కొత్త హోస్ట్‌నేమ్‌కు మార్చాలంటే రెండు విషయాలను కలిపి మార్చాలి: BASE_URL విలువ మరియు Traefik Host() రూల్. ఒకదాన్ని మార్చి మరొకటి మర్చిపోతే, మళ్ళీ స్పిన్నర్ సమస్య వస్తుంది. Planka ను https://example.com/planka వంటి సబ్‌పాత్ నుండి సర్వ్ చేయడం మార్చి 2026లో విడుదలైన 2.1.0 వెర్షన్ నుండి సాధ్యమవుతుంది. పాత ట్యాగ్‌ల కోసం, దానికి ప్రత్యేకమైన సబ్‌డొమైన్‌ను కేటాయించండి.

Planka అటాచ్‌మెంట్‌లు మరియు అవతార్‌లను ఎక్కడ నిల్వ చేస్తుంది

Planka 2 వినియోగదారు అప్‌లోడ్ చేసే ప్రతిదాన్ని కంటైనర్‌లోని ఒకే పాత్ /app/data లో నిల్వ చేస్తుంది. అటాచ్‌మెంట్‌లు, వినియోగదారు అవతార్‌లు మరియు బోర్డ్ బ్యాక్‌గ్రౌండ్ చిత్రాలన్నీ దీని కిందే ఉంటాయి. వెర్షన్ 1 మూడు వేర్వేరు డైరెక్టరీలను ఉపయోగించేది, కాబట్టి పాత గైడ్ల నుండి కాపీ చేసిన Compose ఫైల్ ఇప్పుడు లేని పాత్‌లను మౌంట్ చేస్తుంది, దీనివల్ల అసలైన డేటా డైరెక్టరీ మౌంట్ అవ్వదు.

ఆ ఒక్క మౌంట్ పాయింట్, అప్‌గ్రేడ్ తర్వాత కూడా బోర్డ్ సురక్షితంగా ఉండటానికి లేదా డేటా మొత్తం పోవడానికి మధ్య ఉన్న వ్యత్యాసాన్ని నిర్ణయిస్తుంది. ఒకవేళ /app/data వాల్యూమ్‌లో లేకపోతే, అప్‌లోడ్ చేసిన ఫైళ్లు కంటైనర్ యొక్క writable లేయర్‌లో నిల్వ అవుతాయి. కంటైనర్‌ను రీక్రియేట్ చేసినప్పుడు ఆ లేయర్ తొలగించబడుతుంది, మరియు మీరు ఇమేజ్ ట్యాగ్‌ను మార్చిన ప్రతిసారీ కంటైనర్ రీక్రియేట్ అవుతుంది. అప్పుడు బోర్డ్ చూడటానికి బాగున్నా, కార్డులు అన్నీ ఉన్నా, అటాచ్‌మెంట్ లింక్‌లు పనిచేయవు; ఎందుకంటే డేటాబేస్ రికార్డులు ఇప్పుడు లేని ఫైళ్లను చూపిస్తుంటాయి.

పైన పేర్కొన్న Compose ఫైల్‌లోని named volume ఈ సమస్యను నివారిస్తుంది. Bind mount కూడా పనిచేస్తుంది మరియు సాధారణ టూల్స్‌తో ఫైళ్లను బ్యాకప్ చేయడం సులభతరం చేస్తుంది, కానీ దీనికి ఒక అదనపు దశ అవసరం. కంటైనర్‌లోని Node ప్రాసెస్ UID 1000గా రన్ అవుతుంది, కాబట్టి root యాజమాన్యంలో ఉన్న హోస్ట్ డైరెక్టరీని ఉపయోగిస్తే మొదటి అప్‌లోడ్ సమయంలో పర్మిషన్ ఎర్రర్ వస్తుంది:

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 ను అడగడం ద్వారా స్కీమా (schema) సరిగ్గా అమర్చబడిందో లేదో నిర్ధారించుకోండి:

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

board మరియు card ఉన్న టేబుల్ జాబితా కనిపిస్తే, మైగ్రేషన్లు విజయవంతంగా జరిగినట్లు అర్థం. "Did not find any relations" అని వస్తే, Planka కనెక్ట్ కాలేదని అర్థం; అప్పుడు మీ .env లోని POSTGRES_USER మరియు POSTGRES_PASSWORD విలువలతో DATABASE_URL ను సరిపోల్చండి.

ఆ తర్వాత, 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 దీనికి ప్రాజెక్ట్ డైరెక్టరీ పేరును ప్రిఫిక్స్‌గా చేరుస్తుంది.

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 లో రీస్టోర్ చేసి, మీరు లాగిన్ అవ్వగలరో లేదో మరియు అటాచ్‌మెంట్‌ను తెరవగలరో లేదో నిర్ధారించుకోండి. అప్‌లోడ్లను అనుమతించే ప్రతి Compose అప్లికేషన్‌లోనూ ఇదే విధమైన రెండు స్టోర్లు ఉంటాయి, కాబట్టి మీరు తర్వాత మీ సపోర్ట్ డెస్క్ ఉన్న సర్వర్‌లోనే Chatwoot ను ఇన్‌స్టాల్ చేస్తే, ఇక్కడ మీరు రూపొందించిన విధానమే వాల్యూమ్ పేర్లు మార్చి ఉపయోగపడుతుంది.

ప్రతి వెర్షన్ మార్పుకు వెంటనే ముందు డంప్ రన్ చేయండి. నిన్న రాత్రి తీసుకున్న బ్యాకప్, మీరు చేయబోయే మైగ్రేషన్‌కు ముందు తీసుకున్న బ్యాకప్‌తో సమానం కాదు.

ట్యాగ్‌లను పిన్ చేయడం మరియు రిలీజ్ నోట్స్‌ను చదవడం

ఆ ఫైల్‌లోని రెండు ఇమేజ్ ట్యాగ్‌లు ఉద్దేశపూర్వకంగానే పిన్ చేయబడ్డాయి.

ghcr.io/plankanban/planka:2.1.1 అనేది ఒక నిర్దిష్ట రిలీజ్, ఇది ఆగస్టు 2026 నాటికి ప్రస్తుత వెర్షన్. latest అనేది అప్‌స్ట్రీమ్ వారు కొత్త వెర్షన్‌ను విడుదల చేసినప్పుడల్లా మారుతూ ఉంటుంది, కాబట్టి సాధారణంగా చేసే docker compose pull వల్ల మీరు కోరుకోని సమయంలోనే స్కీమా మైగ్రేషన్ జరగవచ్చు. ఆ నంబర్‌ను మార్చే ముందు రిలీజ్ నోట్స్‌ చదవండి, ఎందుకంటే అక్కడ బ్రేకింగ్ ఛేంజెస్ మరియు సెక్యూరిటీ ఫిక్స్‌ల గురించి వివరించబడి ఉంటుంది. వెర్షన్ 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 ఎందుకు లోడ్ అవుతూనే ఉంటుంది?

మీ ఆధారాలు (credentials) ఆమోదించబడ్డాయి, కానీ live connection విఫలమైంది. Planka తన WebSocket URLను BASE_URL నుండి నిర్మిస్తుంది. కాబట్టి, మీరు https://kanban.example.com ద్వారా సైట్‌ను చేరుకున్నప్పుడు, ఆ వేరియబుల్ ఇంకా http://localhost:3000 అని చూపిస్తుంటే, మీ మెషీన్‌లో లేని చిరునామాకు బ్రౌజర్ సాకెట్‌ను తెరవడానికి ప్రయత్నిస్తుంది. డెవలపర్ కన్సోల్ /socket.io/ కి వెళ్లే అభ్యర్థనలు విఫలమవుతున్నట్లు చూపిస్తుంది. BASE_URL ని చివరన స్లాష్ లేకుండా ఖచ్చితమైన పబ్లిక్ అడ్రస్‌కు సెట్ చేయండి, మీ reverse proxy నుండి వచ్చే X-Forwarded-Proto హెడర్‌ను యాప్ గుర్తించేలా TRUST_PROXY=true ని జోడించండి, ఆపై docker compose up -d ని రన్ చేయండి.

మొదటి Planka అడ్మిన్ యూజర్‌ను ఎలా సృష్టించాలి?

వెర్షన్ 1.13 నుండి అడ్మినిస్ట్రేటర్ స్వయంచాలకంగా సృష్టించబడరు. మీరు DEFAULT_ADMIN_EMAIL ని దాని పాస్‌వర్డ్, పేరు మరియు యూజర్ నేమ్ వేరియబుల్స్‌తో సెట్ చేసి stackను ప్రారంభించండి, లేదా docker compose run --rm planka npm run db:create-admin-user ని రన్ చేసి అడిగే ప్రశ్నలకు సమాధానం ఇవ్వండి. షేర్డ్ సర్వర్‌లో ఈ interactive కమాండ్ సురక్షితమైనది, ఎందుకంటే పాస్‌వర్డ్ కంటైనర్ ఎన్విరాన్‌మెంట్‌లోకి వెళ్లదు, అక్కడ docker inspect దాన్ని చదవగలదు. ఆ తర్వాత DEFAULT_ADMIN_EMAIL ని సెట్ చేసి ఉంచడం వల్ల, ఆ అకౌంట్‌ను ఇంటర్‌ఫేస్ నుండి ఎడిట్ చేయడం లేదా తొలగించడం సాధ్యం కాదు.

Planka అటాచ్‌మెంట్‌లు మరియు అవతార్‌లను ఎక్కడ నిల్వ చేస్తుంది?

Planka 2లో అటాచ్‌మెంట్‌లు, యూజర్ అవతార్‌లు మరియు బోర్డ్ బ్యాక్‌గ్రౌండ్‌లతో సహా అప్‌లోడ్ చేసిన ఫైళ్లన్నీ కంటైనర్ లోపల /app/data లో ఉంటాయి. ఆ పాత్‌ను ఒక named volume పై మౌంట్ చేయండి. అది మౌంట్ చేయకపోతే, ఫైళ్లు కంటైనర్ యొక్క writable layer లో ఉండిపోతాయి మరియు కంటైనర్ మళ్లీ క్రియేట్ అయినప్పుడు (ప్రతి ఇమేజ్ అప్‌గ్రేడ్‌లో ఇది జరుగుతుంది) అవి తొలగిపోతాయి. Bind mount కూడా పనిచేస్తుంది, కానీ Node ప్రాసెస్ UID 1000 గా రన్ అవుతుంది, కాబట్టి హోస్ట్ డైరెక్టరీపై sudo chown -R 1000:1000 ని రన్ చేయండి, లేకపోతే పర్మిషన్ ఎర్రర్ కారణంగా అప్‌లోడ్‌లు విఫలమవుతాయి.

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 ని అలాగే ఉంచండి, తద్వారా pseudo-terminal రీడైరెక్ట్ చేసిన అవుట్‌పుట్‌ను పాడు చేయదు. మీరు దాటవేసే ప్రతి వెర్షన్ యొక్క release notes చదవండి, ఇమేజ్ ట్యాగ్‌ను latest కి బదులుగా నిర్దిష్ట వెర్షన్‌కు మార్చండి, ఆపై docker compose pull మరియు docker compose up -d రన్ చేసి మైగ్రేషన్ కోసం లాగ్‌ను గమనించండి. Postgres ట్యాగ్‌ను దాని మేజర్ వెర్షన్‌కే పరిమితం చేయండి, ఎందుకంటే వేరే మేజర్ వెర్షన్ ద్వారా రాసిన డేటా డైరెక్టరీని సర్వర్ తెరవదు.

#planka#self-hosting#docker-compose#postgres#traefik