बेहतरीन 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 का कोई भी software ships 783 दिनों से नहीं हुआ है, और इसकी 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 मान हैं, जब कोई इसका उपयोग नहीं कर रहा हो। ये वे आंकड़े हैं जिन्हें docker stats स्टैक शुरू होने के एक मिनट बाद रिपोर्ट करता है। इनका उपयोग योजना का आकार निर्धारित करने के लिए करें, और फिर स्वयं मापें। सटीक मेगाबाइट के बजाय उपयोग का पैटर्न अधिक मायने रखता है। यदि उसी VPS पर आपकी फोटो लाइब्रेरी भी होनी है, तो पहले उसका आकार निर्धारित करें, क्योंकि PhotoPrism और Immich की तुलना में आवश्यकताएं पूरी तरह अलग स्तर की होती हैं और बोर्ड टूल को बची हुई जगह में फिट करना होता है।

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

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

डेटाबेस निर्भरता आपके बैकअप कार्य का आधा हिस्सा तय करती है, इसलिए यहाँ प्रत्येक का विवरण दिया गया है। Planka के लिए PostgreSQL की आवश्यकता होती है। Vikunja डिफ़ॉल्ट रूप से SQLite का उपयोग करता है और PostgreSQL, MySQL या MariaDB का भी समर्थन करता है। Kanboard डिफ़ॉल्ट रूप से SQLite का उपयोग करता है और MySQL, MariaDB तथा PostgreSQL का भी समर्थन करता है। इसका डॉक्यूमेंटेशन PostgreSQL की सिफारिश करता है और NFS (network file system) पर SQLite का उपयोग न करने की चेतावनी देता है। Focalboard डिफ़ॉल्ट रूप से SQLite का उपयोग करता है। Wekan, MongoDB वायर प्रोटोकॉल का उपयोग करता है। इसका डिफ़ॉल्ट Compose फ़ाइल अब वास्तविक MongoDB सर्वर के बजाय एम्बेडेड SQLite बैकएंड के साथ 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 नहीं है। इस तुलना में यह स्पष्ट रूप से "नहीं" वाला एकमात्र प्रोजेक्ट है। बाकी सब में आपको समझौता करना होगा।

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

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

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

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

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

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

Multi-user access और single sign-on

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

Vikunja एक साथ कई providers के साथ OpenID Connect को सपोर्ट करता है। VIKUNJA_AUTH_OPENID_ENABLED=true सेट करें, फिर प्रति 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 के लिए अलग पासवर्ड देने की तुलना में आमतौर पर एक बेहतर समाधान है।

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

Planka का तरीका सबसे सरल है। Trello से board को JSON के रूप में export करें, Planka में एक board बनाएँ, Import पर क्लिक करें और Trello चुनें। पहले सीमाओं को पढ़ लें, क्योंकि वे वास्तविक हैं: 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 में कोई built-in Trello importer नहीं है, जो इसे छोड़ने का मुख्य कारण है यदि आपके पास Trello का वर्षों का इतिहास है जिसे स्थानांतरित करना है।

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

पाँचों विकल्पों में से केवल Vikunja के पास आधिकारिक मोबाइल ऐप्स हैं। Android और iOS बिल्ड प्रत्येक release के साथ आते हैं, और ऐप रिपॉजिटरी खुद को alpha बताती है, इसलिए इसे मुख्य माध्यम के बजाय वेब इंटरफेस के पूरक के रूप में इस्तेमाल करें। Planka के पास प्रोजेक्ट की ओर से कोई आधिकारिक ऐप नहीं है, हालाँकि इसका वेब इंटरफेस responsive है और इसके लिए third-party क्लाइंट मौजूद हैं। Wekan और Kanboard केवल वेब-आधारित हैं, और Kanboard का इंटरफेस स्पष्ट रूप से डेस्कटॉप स्क्रीन के लिए बनाया गया है।

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

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

दो लोगों के लिए यह एक उचित सौदा है। एक कंपनी के लिए, यह एक ऐसी शर्त है जिसे बीस लोगों का काम इसमें लगाने से पहले पढ़ लेना चाहिए। अन्य चार सामान्य open source हैं: 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 सेवा को running के रूप में दिखाता है, और info endpoint एक JSON लौटाता है जिसमें version field होता है। यहाँ 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 नहीं होता है, इसलिए केवल वही एक चीज जो उस तक पहुँच सकती है, वह उसी 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 चलाएं। इस स्तर पर आपको बीस स्थानीय पासवर्ड के बजाय OpenID Connect की आवश्यकता होती है, आपको टीमों और प्रति-प्रोजेक्ट शेयरिंग की जरूरत होती है, और अधिकांश काम केवल बोर्ड पर फिट नहीं होगा, इसलिए List, Table और Gantt views केवल अतिरिक्त सुविधा नहीं रह जाते। AGPL-3.0 का मतलब यह भी है कि जैसे-जैसे कर्मचारियों की संख्या बढ़ती है, लाइसेंस को लेकर कोई समस्या नहीं होती। इसे SQLite के बजाय PostgreSQL दें, इसे reverse proxy के पीछे रखें, और दैनिक डंप को उस सर्वर के अलावा कहीं और सुरक्षित रखें।

यदि इस box में 1 GB से कम RAM है, तो इनमें से कोई भी विकल्प लागू नहीं होता। 70 MB वाला Kanboard चुनें, यह स्वीकार करें कि आपको अपने Trello cards फिर से दर्ज करने होंगे, और बची हुई memory को 2026 की self-hosting shortlist में दिए किसी अन्य विकल्प पर खर्च करें। यदि उस box पर पहले से Jellyfin चल रहा है, तो Halcyon library को चलकर देखे जा सकने वाले 90s video store में फिर से बनाता है, जो दूसरे board tool की तुलना में अधिक मनोरंजक tenant है। आप जो भी tool चुनें, उसकी विस्तृत installation प्रक्रिया अलग guide में होनी चाहिए। यह page केवल चयन के लिए है।

FAQ

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

Kanboard, जो idle रहने पर लगभग 70 MB RAM लेता है, क्योंकि यह PHP और SQLite पर आधारित है और requests के बीच memory में कुछ भी store नहीं करता है। इसके बाद Vikunja है, जो एक single Go binary के रूप में लगभग 110 MB लेता है। Wekan सबसे भारी है और लगभग 750 MB लेता है, क्योंकि 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 वर्तमान में maintained नहीं है। 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 पर move करें, क्योंकि SQLite writes को serialize करता है और एक busy instance database is locked error देना शुरू कर देता है। SQLite file को network share पर भी न रखें: Kanboard का documentation इसी कारण से NFS पर SQLite का उपयोग न करने की चेतावनी देता है।