बेहतरीन self-hosted Trello विकल्प: तुलना और समीक्षा

आपको कौन सा self-hosted Trello विकल्प चुनना चाहिए?

तीन self-hosted Trello विकल्प आपके समय के योग्य हैं: यदि आपको Trello का सटीक बोर्ड और उसका import file चाहिए तो Planka, यदि टीम को single sign-on और बोर्ड से अधिक सुविधाओं की आवश्यकता है तो Vikunja, और यदि VPS (virtual private server) छोटा है तो Kanboard। Focalboard पर कोई नया प्रोजेक्ट शुरू न करें। इसके standalone server का 783 दिनों से कोई release नहीं आया है, और इसका README अब एक maintainer की मांग कर रहा है।

Wekan यहाँ दिए गए 5 टूल्स में से पांचवां है। यह काम करता है, लेकिन यह बाकी सभी की तुलना में कई गुना अधिक memory लेता है। नीचे दिए गए प्रत्येक version, licence और date की जांच 5 August 2026 को की गई थी।

प्रत्येक बोर्ड टूल को कितनी RAM की आवश्यकता होती है?

[
  {
    "tool": "Planka + Postgres",
    "idle_memory_mb": 280
  },
  {
    "tool": "Vikunja + SQLite",
    "idle_memory_mb": 110
  },
  {
    "tool": "Focalboard + SQLite",
    "idle_memory_mb": 120
  },
  {
    "tool": "Wekan + FerretDB",
    "idle_memory_mb": 750
  },
  {
    "tool": "Kanboard + SQLite",
    "idle_memory_mb": 70
  }
]

ये आंकड़े एक नए इंस्टॉलेशन के लिए सामान्य idle मान हैं, जब कोई उपयोगकर्ता इसका उपयोग नहीं कर रहा हो। ये वे आंकड़े हैं जो stack के शुरू होने के एक मिनट बाद docker stats रिपोर्ट करता है। इनका उपयोग योजना बनाने के लिए करें, और फिर अपने स्वयं के उपयोग के अनुसार मापें। सटीक मेगाबाइट के बजाय उपयोग का पैटर्न अधिक महत्वपूर्ण है।

Kanboard का न्यूनतम स्तर 70 MB है क्योंकि यह PHP और SQLite पर आधारित है। कोई भी long-running application process आपके बोर्ड को मेमोरी में नहीं रखती है, इसलिए requests के बीच container लगभग शून्य मेमोरी का उपयोग करता है। Vikunja एक सिंगल Go binary है जो 110 MB पर चलता है, और SQLite इसका डिफ़ॉल्ट डेटाबेस है, इसलिए एक ही container पूरा stack है। Planka को 280 MB की आवश्यकता होती है क्योंकि इसमें हमेशा दो containers होते हैं: एक Node सर्वर और PostgreSQL। Planka में SQLite का कोई विकल्प नहीं है, इसलिए डेटाबेस को बदला नहीं जा सकता।

Wekan 750 MB पर रहता है क्योंकि यह एक Meteor application है। Meteor एक live query layer को Node मेमोरी में रखता है और हर बोर्ड परिवर्तन को WebSocket के माध्यम से प्रत्येक खुले ब्राउज़र पर भेजता है। इसलिए इसकी मेमोरी उपयोग स्थिर रहने के बजाय जुड़े हुए लोगों की संख्या के साथ बढ़ती है। 1 GB VPS पर Wekan शुरू तो हो जाता है, लेकिन जैसे ही कुछ लोग एक बड़ा बोर्ड खोलते हैं, यह क्रैश हो जाता है। इसका लक्षण यह है कि container गायब हो जाता है और exit code 137 के साथ वापस आता है, जिसे docker compose ps एक restart loop के रूप में दिखाता है। इसे host पर dmesg -T | grep -i "out of memory" के साथ सत्यापित करें, क्योंकि kernel का out-of-memory killer application को कोई सूचना नहीं देता है।

डेटाबेस निर्भरता आपके बैकअप कार्य का आधा हिस्सा निर्धारित करती है, इसलिए यहाँ प्रत्येक का विवरण दिया गया है। Planka के लिए PostgreSQL आवश्यक है। Vikunja डिफ़ॉल्ट रूप से SQLite का उपयोग करता है और PostgreSQL, MySQL या MariaDB को भी सपोर्ट करता है। Kanboard डिफ़ॉल्ट रूप से SQLite का उपयोग करता है और MySQL, MariaDB तथा PostgreSQL को भी सपोर्ट करता है। इसके दस्तावेज़ PostgreSQL का उपयोग करने की सलाह देते हैं और NFS (network file system) पर SQLite का उपयोग न करने की चेतावनी देते हैं। Focalboard डिफ़ॉल्ट रूप से SQLite का उपयोग करता है। Wekan, MongoDB wire protocol का उपयोग करता है, और इसकी डिफ़ॉल्ट Compose फ़ाइल अब वास्तविक MongoDB सर्वर के बजाय एक एम्बेडेड SQLite backend के साथ FerretDB v1 प्रदान करती है। यदि आप चाहें, तो इसके लिए एक अलग MongoDB 7 Compose फ़ाइल भी उपलब्ध है।

इनमें से कौन से प्रोजेक्ट अभी भी maintained हैं?

[
  {
    "tool": "Planka 2.1.1",
    "release_age": 109
  },
  {
    "tool": "Vikunja 2.5.0",
    "release_age": 1
  },
  {
    "tool": "Focalboard 8.0.0",
    "release_age": 783
  },
  {
    "tool": "Wekan 10.67",
    "release_age": 1
  },
  {
    "tool": "Kanboard 1.2.53",
    "release_age": 12
  }
]

Focalboard 783 दिनों के साथ इस सूची में अपवाद है। इसका अंतिम standalone release, v8.0.0, जून 2024 का है। Mattermost ने board development को एक अलग repository में plugin के रूप में स्थानांतरित कर दिया है, और standalone README के अनुसार यह repository वर्तमान में maintained नहीं है। इस तुलना में यह स्पष्ट रूप से "नहीं" (no) वाला प्रोजेक्ट है। बाकी सभी विकल्पों में आपको कुछ न कुछ समझौता करना होगा।

Planka का 109 दिनों का अंतराल उस प्रोजेक्ट के लिए ठीक है जो साल में कुछ ही releases जारी करता है। Version 2.1.1 अप्रैल 2026 का है। Kanboard ने चेक से 12 दिन पहले v1.2.53 जारी किया था, और उससे पहले के दो releases मार्च और अप्रैल 2026 में आए थे।

Vikunja और Wekan दोनों ने चेक के एक दिन के भीतर release जारी किए, लेकिन आपको इन दोनों तथ्यों को अलग तरह से देखना चाहिए। Vikunja ने v2.5.0 को एक सामान्य minor release के रूप में tag किया। Wekan ने एक ही दिन में v10.65, v10.66 और v10.67 को tag किया, जो इसकी सामान्य कार्य-प्रणाली है। बार-बार release आने का मतलब यह नहीं है कि target स्थिर है। Wekan के साथ आप एक तेजी से बदलते version number को track करने का विकल्प चुन रहे हैं, इसलिए tag को pin करें और हर update से पहले notes जरूर पढ़ें।

क्या आपको केवल एक बोर्ड से अधिक कुछ मिलता है?

अधिकांश तुलनात्मक पोस्ट "यह Trello जैसा दिखता है" पर रुक जाते हैं। यह पैमाना RAM से कहीं अधिक महत्वपूर्ण है, क्योंकि समय-सीमा (deadline) वाले किसी भी कार्य के लिए बोर्ड एक खराब प्रारूप है।

• Planka केवल एक बोर्ड टूल है और कुछ नहीं: इसमें प्रोजेक्ट्स, बोर्ड, लिस्ट, कार्ड, लेबल, चेकलिस्ट, कमेंट्स और अटैचमेंट्स मिलते हैं। अगस्त 2026 तक, कैलेंडर और मैप व्यू इसके Pro फीचर्स हैं।
• Vikunja एक ही टास्क सेट पर चार व्यू देता है: List, Kanban, Table और Gantt। एक टास्क केवल एक बार मौजूद होता है, और आप उसे डुप्लिकेट करने के बजाय व्यू बदल सकते हैं।
• Kanboard में work-in-progress लिमिट्स, सबटास्क, अटैचमेंट्स, कमेंट्स, ऑटोमैटिक एक्शन्स और फिल्टरिंग के लिए एक छोटी क्वेरी लैंग्वेज के साथ बोर्ड मिलते हैं। इसका अपना होमपेज कहता है "फीचर्स की संख्या जानबूझकर सीमित रखी गई है", जो इसका सटीक वर्णन है।
• Wekan में स्विमलेन (swimlanes) के साथ बोर्ड, चेकलिस्ट, कस्टम फील्ड्स, एक REST (representational state transfer) API और वेबहुक्स मिलते हैं।
• Focalboard एक ही कार्ड्स पर बोर्ड, टेबल और कैलेंडर व्यू प्रदान करता था। इसे पूर्णता के लिए यहाँ सूचीबद्ध किया गया है।

यदि आप वास्तव में टास्क ट्रैकिंग के साथ एक विकी (wiki) चाहते हैं, तो यह तुलना आपके लिए नहीं है। BookStack, Wiki.js और Outline उस प्रारूप को कवर करते हैं, और self-hosted Notion के विकल्प ऑल-इन-वन वर्कस्पेस को कवर करते हैं।

Multi-user access और single sign-on

Planka अपने मुफ्त Community edition में OpenID Connect को सपोर्ट करता है। आधिकारिक Compose file में ये settings comment की गई हैं, जिनमें OIDC_ISSUER, OIDC_CLIENT_ID और OIDC_CLIENT_SECRET शामिल हैं, इसलिए आपको इन्हें केवल uncomment करना है, upgrade नहीं। बाहरी लोगों के लिए Guest roles एक Pro feature है।

Vikunja एक साथ कई providers के साथ OpenID Connect को सपोर्ट करता है। VIKUNJA_AUTH_OPENID_ENABLED=true को set करें, फिर प्रत्येक provider के लिए VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_* variables का एक block जोड़ें। इसमें teams और per-project sharing की सुविधा भी है, जिसकी वास्तव में बीस लोगों वाली संस्था को आवश्यकता होती है।

Wekan LDAP (lightweight directory access protocol), OAuth2, OIDC और SAML को सपोर्ट करता है। Kanboard में LDAP इन-बिल्ट है और बाकी सब के लिए एक generic OAuth2 plugin है, साथ ही इसमें per-project roles और groups भी उपलब्ध हैं। Focalboard के standalone server में कोई single sign-on नहीं है, जो इसे न चुनने का दूसरा कारण है।

इनमें से किसी को भी स्वयं द्वारा संचालित Authentik identity provider के साथ जोड़ा जा सकता है, जो बीस लोगों को हर app के लिए अलग password देने की तुलना में एक बेहतर समाधान है।

क्या आप अपने Trello boards को import कर सकते हैं?

Planka का तरीका सबसे सरल है। Trello से board को JSON के रूप में export करें, Planka में एक board बनाएँ, Import पर क्लिक करें और Trello चुनें। पहले सीमाओं (limits) को पढ़ लें, क्योंकि वे वास्तविक हैं: users और attachments import नहीं होते, प्रति card केवल एक checklist आती है, और Trello का डिफ़ॉल्ट JSON export बिना किसी चेतावनी के 1,000 actions पर रुक जाता है। परिणाम पर भरोसा करने से पहले फ़ाइल को स्वयं जाँच लें।

Vikunja, Trello के OAuth flow के माध्यम से import करता है, जो Settings के अंतर्गत "Import from other services" में स्थित है। प्रत्येक migrator को config में enable करना आवश्यक है, तभी उसका icon दिखाई देता है, और VIKUNJA_SERVICE_PUBLICURL का सही होना अनिवार्य है, क्योंकि OAuth redirect आपके browser में होता है, न कि सर्वर से। Vikunja, Todoist, Microsoft To Do, TickTick और Wekan को भी import करता है।

Wekan अपने import form में Trello board JSON को paste करने की सुविधा देता है। Kanboard में कोई इन-बिल्ट Trello importer नहीं है, जो इसे छोड़ने का मुख्य कारण है यदि आपके पास Trello का वर्षों का इतिहास है जिसे आप स्थानांतरित करना चाहते हैं।

मोबाइल अनुभव कैसा है?

पाँचों विकल्पों में से केवल Vikunja के पास आधिकारिक mobile apps हैं। Android और iOS builds प्रत्येक release के साथ उपलब्ध होते हैं, और app repository खुद को alpha बताती है, इसलिए इसे मुख्य माध्यम के बजाय web interface के पूरक के रूप में उपयोग करें। Planka के पास प्रोजेक्ट की ओर से कोई आधिकारिक app नहीं है, हालाँकि इसका web interface responsive है और third-party clients मौजूद हैं। Wekan और Kanboard केवल web-आधारित हैं, और Kanboard का interface स्पष्ट रूप से desktop screen के लिए बनाया गया है।

लाइसेंस का प्रश्न, और Planka अलग क्यों है

Planka अब ओपन सोर्स नहीं है, और यह वह तथ्य है जिसे अधिकांश तुलनाओं में छोड़ दिया जाता है। इसकी शुरुआत MIT लाइसेंस के तहत हुई थी, 2023 में यह AGPL-3.0 पर स्थानांतरित हो गया, और 2.0 सीरीज से यह PLANKA Community License के तहत उपलब्ध है, जो PLANKA Software GmbH द्वारा धारित एक फेयर-कोड लाइसेंस है। GitHub इसके लाइसेंस को "Other" के रूप में रिपोर्ट करता है क्योंकि वह लाइसेंस OSI द्वारा अनुमोदित नहीं है। इसे अपने लोगों के लिए सेल्फ-होस्ट करना निःशुल्क है और स्पष्ट रूप से इसकी अनुमति है, जिसमें व्यक्तिगत, आंतरिक, गैर-लाभकारी और शैक्षिक उपयोग शामिल हैं। इसे पुनर्विक्रय (reselling) करने या अन्य कंपनियों के लिए सेवा के रूप में चलाने के लिए कमर्शियल लाइसेंस की आवश्यकता होती है।

दो लोगों के लिए यह एक उचित सौदा है। एक कंपनी के लिए, यह ऐसी शर्त है जिसे बीस लोगों का काम इसमें लगाने से पहले पढ़ लेना चाहिए। अन्य चार सामान्य ओपन सोर्स हैं: Vikunja AGPL-3.0 है, Wekan और Kanboard MIT हैं, और Focalboard Apache 2.0 और AGPL-3.0 का मिश्रण है।

दो विकल्पों के लिए Pinned Compose फाइलें

Image tag को पिन करें। latest का अर्थ है कि अगला docker compose pull आपको एक major version के पार ले जा सकता है, और major versions ऐसे database migrations चलाते हैं जिन्हें आप आसानी से reverse नहीं कर सकते। नीचे दी गई दोनों फाइलें upstream फाइलें हैं जिनमें tag को एक वास्तविक release पर fix किया गया है।

SQLite पर Vikunja, एक container:

services:
  vikunja:
    image: vikunja/vikunja:2.5.0
    restart: unless-stopped
    environment:
      VIKUNJA_SERVICE_PUBLICURL: https://tasks.example.com
      VIKUNJA_SERVICE_SECRET: replace-with-a-long-random-string
      VIKUNJA_SERVICE_TIMEZONE: Europe/Berlin
      VIKUNJA_DATABASE_TYPE: sqlite
      VIKUNJA_DATABASE_PATH: /app/vikunja/files/vikunja.db
    ports:
      - "127.0.0.1:3456:3456"
    volumes:
      - ./files:/app/vikunja/files

सबसे पहले सही owner के साथ data directory बनाएँ, क्योंकि container UID 1000 के रूप में चलता है और root-owned directory में write नहीं कर सकता:

mkdir -p files && sudo chown 1000 files
docker compose up -d
docker compose ps
curl -sf http://127.0.0.1:3456/api/v1/info

एक healthy stack service को running के रूप में दिखाता है, और info endpoint एक version field युक्त JSON लौटाता है। यहाँ Connection refused का अर्थ है कि container exit हो गया है। docker compose logs vikunja कारण बताता है, और database file पर permission error एक सामान्य कारण है।

PostgreSQL पर Planka, दो containers:

services:
  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    restart: unless-stopped
    volumes:
      - data:/app/data
    ports:
      - "127.0.0.1:3000:1337"
    environment:
      - BASE_URL=https://boards.example.com
      - DATABASE_URL=postgresql://postgres@postgres/planka
      - SECRET_KEY=replace-with-openssl-rand-hex-64
    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_HOST_AUTH_METHOD=trust
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  data:
  db-data:

POSTGRES_HOST_AUTH_METHOD=trust का अर्थ है कि PostgreSQL बिना password के किसी भी connection को स्वीकार करता है। यह केवल इसलिए सुरक्षित है क्योंकि database port कभी भी host पर publish नहीं होता है, इसलिए केवल वही चीज़ इसे access कर सकती है जो उसी Compose network पर दूसरा container है। postgres service में ports: entry न जोड़ें।

किसी भी stack को सीधे internet का सामना नहीं करना चाहिए। दोनों 127.0.0.1 पर bind होते हैं, इसलिए सामने एक reverse proxy रखें और वहाँ TLS (transport layer security) terminate करें। कई Compose apps के सामने Traefik ऐसा करने का सामान्य तरीका है जब आप एक से अधिक चीज़ें host करते हैं, और Docker Compose basics guide उन हिस्सों को कवर करता है जिन्हें यह पृष्ठ छोड़ देता है।

आपका बोर्ड एक डेटाबेस है, इसलिए इसका बैकअप लें

एक बोर्ड टूल चुपचाप विफल हो जाता है। जब तक कोई वॉल्यूम गायब नहीं हो जाता, तब तक किसी को बैकअप न होने का पता नहीं चलता, और एक क्षतिग्रस्त SQLite फ़ाइल सामान्य रूप से खुल जाएगी और database disk image is malformed सप्ताह बाद त्रुटि दिखाएगी।

लाइव SQLite फ़ाइल को कभी भी cp से कॉपी न करें। कॉपी के दौरान राइट ऑपरेशन हो सकता है, जिससे आर्काइव पूर्ण दिखाई देगा लेकिन रिस्टोर करने पर डेटाबेस में पंक्तियाँ गायब मिलेंगी। कॉपी करने के लिए लगने वाले कुछ सेकंड के लिए सर्विस को रोक दें:

docker compose stop vikunja
tar czf vikunja-$(date +%F).tgz files
docker compose start vikunja

Planka के लिए, चल रहे क्लस्टर की डेटा डायरेक्टरी को कॉपी करने के बजाय PostgreSQL का डंप लें, और uploads वॉल्यूम को अलग से लें, क्योंकि अटैचमेंट डेटाबेस में नहीं होते हैं:

docker compose exec -T postgres pg_dump -U postgres -Fc planka > planka-db.dump
docker volume ls
docker run --rm -v planka_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/planka-files.tgz -C /data .

docker volume ls वास्तविक वॉल्यूम नाम प्रिंट करता है, जो आपका Compose प्रोजेक्ट नाम और उसके बाद _data होता है। यदि आप ऐसा नाम देते हैं जो मौजूद नहीं है, तो यह एक खाली वॉल्यूम बना देगा और आपको बिना किसी त्रुटि के एक वैध लेकिन खाली आर्काइव मिल जाएगा, इसलिए बाद में फ़ाइल का आकार अवश्य जाँचें।

इसके बाद, इसे एक बार उसी बॉक्स पर एक स्क्रैच स्टैक में रिस्टोर करें, और कोई ऐसा कार्ड खोलें जिसे आप याद रखते हैं। जिस बैकअप को आपने कभी रिस्टोर नहीं किया, वह केवल एक अनुमान है। आर्काइव को सर्वर से बाहर भी भेजें, क्योंकि जिस VPS को आप सुरक्षित कर रहे हैं, उसी पर रखी गई कॉपी बैकअप नहीं है। VPS से restic बैकअप इस विषय को कवर करता है।

दो सुझाव

दो लोगों के लिए 2 GB VPS: Planka चलाएं। यह दिखने और काम करने के तरीके में Trello के सबसे करीब है, Trello import के लिए बस एक फाइल ड्रैग करनी होती है, और 280 MB idle memory के साथ 2 GB का अधिकांश हिस्सा reverse proxy और अन्य होस्ट की गई सेवाओं के लिए खाली रहता है। Community License दो लोगों की आंतरिक टीम के लिए निःशुल्क है। यदि आप source-available लाइसेंस पर निर्भर नहीं रहना चाहते हैं, तो 110 MB पर SQLite के साथ Vikunja उसी सर्वर के लिए एक open-source विकल्प है।

एक संगठन में बीस लोग: PostgreSQL पर Vikunja चलाएं। इस स्तर पर आपको बीस अलग-अलग local passwords के बजाय OpenID Connect की आवश्यकता होती है, आपको teams और per-project sharing की जरूरत होती है, और अधिकांश काम केवल board पर नहीं समाते, इसलिए List, Table और Gantt views केवल अतिरिक्त सुविधा नहीं रह जाते। AGPL-3.0 का अर्थ यह भी है कि जैसे-जैसे टीम बढ़ेगी, लाइसेंस को लेकर कोई समस्या नहीं होगी। इसे SQLite के बजाय PostgreSQL दें, इसे reverse proxy के पीछे रखें, और daily dump को उस सर्वर के अलावा कहीं और सुरक्षित रखें।

यदि सर्वर में 1 GB से कम RAM है, तो इनमें से कोई भी विकल्प लागू नहीं होता। 70 MB पर Kanboard चुनें, यह स्वीकार करें कि आपको अपने Trello cards दोबारा टाइप करने होंगे, और बचाई गई memory का उपयोग 2026 के लिए self-hosting शॉर्टलिस्ट से किसी अन्य चीज़ के लिए करें। आपके द्वारा चुने गए टूल का विस्तृत इंस्टॉलेशन अपनी अलग गाइड में आता है। यह पृष्ठ केवल चयन के लिए है।

FAQ

कौन सा self-hosted Trello विकल्प सबसे कम RAM का उपयोग करता है?

Kanboard, जो idle रहने पर लगभग 70 MB RAM लेता है, क्योंकि यह PHP और SQLite पर आधारित है और requests के बीच memory में कुछ भी store नहीं करता है। इसके बाद Vikunja का नंबर आता है, जो एक single Go binary के रूप में लगभग 110 MB लेता है। Wekan सबसे भारी है और लगभग 750 MB RAM लेता है, क्योंकि Meteor हर connected browser के लिए Node memory में एक live query layer बनाए रखता है। जब stack idle हो, तब docker stats का उपयोग करके स्वयं मापें, क्योंकि ये केवल सामान्य आंकड़े हैं, कोई गारंटी नहीं।

क्या मैं अपने Trello boards को किसी self-hosted tool में import कर सकता हूँ?

Planka और Wekan दोनों सीधे Trello के JSON board export को स्वीकार करते हैं। Vikunja, Trello के OAuth flow के माध्यम से import करता है, और interface में दिखने से पहले migrator को config में enable करना पड़ता है। Kanboard में कोई built-in importer नहीं है। दो सीमाओं का ध्यान रखें: Planka users या attachments को import नहीं करता है और प्रति card केवल एक checklist संभालता है, और Trello का default JSON export बिना किसी चेतावनी के 1,000 actions पर रुक जाता है, जिससे data truncate हो सकता है।

क्या 2026 में Focalboard अभी भी एक अच्छा विकल्प है?

नहीं। इसका आखिरी standalone release, v8.0.0, जून 2024 का है, जो 5 अगस्त 2026 को इस तुलना की जाँच से 783 दिन पहले था, और README में लिखा है कि repository अब maintain नहीं की जा रही है। Mattermost ने board development को केवल एक अलग repository में plugin के रूप में जारी रखा है, इसलिए जिस server को आप self-host करेंगे, वह हिस्सा बंद हो चुका है। इसके बजाय Planka या Vikunja चुनें।

क्या Planka अभी भी open source है?

OSI की परिभाषा के अनुसार नहीं। Planka पहले MIT था, 2023 में AGPL-3.0 पर चला गया, और version 2.0 के बाद से PLANKA Community License के तहत आता है। व्यक्तिगत, आंतरिक, गैर-लाभकारी और शैक्षिक उपयोग के लिए self-hosting मुफ्त है। तीसरे पक्ष के लिए access resell करने या service के रूप में चलाने के लिए commercial licence की आवश्यकता होती है, और calendar view, guest roles तथा recurring cards, Pro tier के अंतर्गत आते हैं। यदि OSI-approved licence एक अनिवार्य आवश्यकता है, तो Vikunja AGPL-3.0 है और Kanboard MIT है।

क्या मुझे PostgreSQL की आवश्यकता है, या SQLite पर्याप्त है?

Vikunja, Kanboard और Focalboard default रूप से SQLite का उपयोग करते हैं, जो एक server पर कुछ लोगों के लिए ठीक है। Planka के लिए PostgreSQL आवश्यक है और इसमें SQLite का कोई विकल्प नहीं है। जब कई लोग एक साथ data लिख रहे हों, तो PostgreSQL पर migrate करें, क्योंकि SQLite writes को serialize करता है और एक व्यस्त instance database is locked error देने लगता है। SQLite file को network share पर भी न रखें: Kanboard का documentation इसी कारण से NFS पर SQLite का उपयोग न करने की चेतावनी देता है।