सर्वोत्तम Self-hosted Trello पर्याय: तुलना आणि माहिती

तुम्ही कोणता self-hosted Trello पर्याय निवडावा?

Trello चे तीन self-hosted पर्याय विचारात घेण्यासारखे आहेत: जर तुम्हाला Trello चे हुबेहूब बोर्ड आणि त्याचे import फाइल हवी असेल तर Planka वापरा, जर टीमला single sign-on आणि बोर्डपेक्षा अधिक सुविधांची गरज असेल तर Vikunja वापरा, आणि जर तुमचा VPS (virtual private server) लहान असेल तर Kanboard वापरा. Focalboard वर नवीन प्रकल्प सुरू करू नका. त्याच्या standalone server चे गेल्या 783 दिवसांत कोणतेही नवीन release आलेले नाही आणि त्याच्या README मध्ये आता maintainer ची मागणी केली आहे.

Wekan हे येथे दिलेल्या 5 साधनांपैकी पाचवे साधन आहे. ते कार्यक्षम आहे, परंतु ते इतर सर्व साधनांच्या तुलनेत कित्येक पटीने जास्त memory वापरते. खालील प्रत्येक version, licence आणि तारीख 5 ऑगस्ट 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
  }
]

हे आकडे एका नवीन इन्स्टॉलसाठी आहेत, जेव्हा कोणीही त्याचा वापर करत नसेल. स्टॅक सुरू झाल्यानंतर एका मिनिटाने docker stats जे आकडे दाखवते, हे त्या प्रकारचे आहेत. प्लॅन तयार करण्यासाठी यांचा वापर करा आणि त्यानंतर तुमच्या स्वतःच्या वापराचे मोजमाप करा. अचूक मेगाबाइट्सपेक्षा वापराचे स्वरूप अधिक महत्त्वाचे असते.

Kanboard हे सर्वात कमी RAM वापरणारे टूल आहे, जे 70 MB घेते, कारण ते PHP आणि SQLite वर आधारित आहे. कोणतीही दीर्घकाळ चालणारी ॲप्लिकेशन प्रक्रिया तुमच्या बोर्ड्सना मेमरीमध्ये धरून ठेवत नाही, त्यामुळे विनंत्यांच्या दरम्यान कंटेनर जवळजवळ काहीही वापरत नाही. 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" वापरून तपासा, कारण कर्नलचा 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 ची गरज असेल, तर त्यासाठी स्वतंत्र MongoDB 7 Compose फाईल उपलब्ध आहे.

यापैकी कोणते प्रकल्प अजूनही मेंटेन केले जातात?

[
  {
    "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 दिवसांच्या कालावधीसह अपवाद आहे. त्याची शेवटची स्वतंत्र रिलीज, v8.0.0, जून 2024 मधील आहे. Mattermost ने बोर्ड डेव्हलपमेंट एका वेगळ्या रिपॉझिटरीमधील प्लगइनमध्ये हलवली आहे आणि स्टँडअलोन README मध्ये नमूद केले आहे की ही रिपॉझिटरी सध्या मेंटेन केली जात नाही. या तुलनेत हे एक स्पष्ट "नाही" आहे. इतर सर्व गोष्टींमध्ये तडजोड करावी लागते.

Planka चे 109 दिवस हे वर्षातून काही वेळा रिलीज देणाऱ्या प्रकल्पासाठी योग्य आहेत. व्हर्जन 2.1.1 एप्रिल 2026 मधील आहे. Kanboard ने तपासणीच्या 12 दिवस आधी v1.2.53 रिलीज केली होती आणि त्याआधीच्या दोन रिलीज मार्च आणि एप्रिल 2026 मध्ये आल्या होत्या.

Vikunja आणि Wekan या दोघांनीही तपासणीच्या एका दिवसाच्या आत रिलीज दिली आहे, परंतु या दोन तथ्यांकडे तुम्ही वेगळ्या दृष्टीकोनातून पाहिले पाहिजे. Vikunja ने v2.5.0 ला एक सामान्य मायनर रिलीज म्हणून टॅग केले आहे. Wekan ने एकाच दिवशी v10.65, v10.66 आणि v10.67 टॅग केले, जी त्यांची सामान्य पद्धत आहे. वारंवार होणाऱ्या रिलीजचा अर्थ असा नाही की ते एक स्थिर टार्गेट आहे. Wekan वापरताना तुम्ही वेगाने बदलणाऱ्या व्हर्जन नंबरला ट्रॅक करण्याचे निवडत आहात, त्यामुळे प्रत्येक अपडेटपूर्वी टॅग पिन करा आणि नोट्स वाचा.

तुम्हाला फक्त बोर्डपेक्षा जास्त काही मिळते का?

बहुतेक तुलनात्मक पोस्ट "हे Trello सारखे दिसते" इथपर्यंतच मर्यादित असतात. हा निकष RAM पेक्षाही महत्त्वाचा आहे, कारण डेडलाइन असलेल्या कोणत्याही कामासाठी बोर्ड हे एक अपुरे स्वरूप आहे.

• Planka हे केवळ एक बोर्ड टूल आहे: प्रोजेक्ट्स, बोर्ड्स, लिस्ट्स, कार्ड्स, लेबल्स, चेकलिस्ट्स, कमेंट्स आणि अटॅचमेंट्स. ऑगस्ट 2026 पर्यंत कॅलेंडर आणि मॅप व्ह्यूज हे Pro फीचर्स आहेत.
• Vikunja एकाच टास्क सेटसाठी चार व्ह्यूज देते: List, Kanban, Table आणि Gantt. टास्क एकदाच तयार केला जातो आणि तुम्ही तो डुप्लिकेट करण्याऐवजी व्ह्यू बदलू शकता.
• Kanboard मध्ये वर्क-इन-प्रोग्रेस लिमिट्स, सबटास्क्स, अटॅचमेंट्स, कमेंट्स, ऑटोमॅटिक ॲक्शन्स आणि फिल्टरिंगसाठी एक छोटी क्वेरी लँग्वेज असलेले बोर्ड्स असतात. त्यांच्या स्वतःच्या होमपेजवर "फीचर्सची संख्या मुद्दाम मर्यादित ठेवली आहे" असे म्हटले आहे, जे याचे योग्य वर्णन आहे.
• Wekan मध्ये स्विमलेन्ससह बोर्ड्स, तसेच चेकलिस्ट्स, कस्टम फील्ड्स, REST (representational state transfer) API आणि वेबहुक्स असतात.
• Focalboard एकाच कार्ड्ससाठी बोर्ड, टेबल आणि कॅलेंडर व्ह्यूज ऑफर करत असे. माहिती पूर्ण असावी म्हणून याचा येथे उल्लेख केला आहे.

जर तुम्हाला खरोखर टास्क ट्रॅकिंगसह विकी (wiki) हवे असेल, तर ही तुलना चुकीची आहे. BookStack, Wiki.js आणि Outline मध्ये त्या स्वरूपाची माहिती दिली आहे आणि self-hosted Notion पर्याय हे ऑल-इन-वन वर्कस्पेस कव्हर करतात.

मल्टी-युजर ॲक्सेस आणि सिंगल साइन-ऑन

Planka च्या मोफत Community edition मध्ये OpenID Connect ला सपोर्ट आहे. अधिकृत Compose फाईलमध्ये या सेटिंग्ज कमेंट केलेल्या असतात, ज्यामध्ये OIDC_ISSUER, OIDC_CLIENT_ID आणि OIDC_CLIENT_SECRET यांचा समावेश आहे, त्यामुळे तुम्हाला अपग्रेड करण्याऐवजी फक्त कमेंट काढून (uncomment) त्या सक्रिय कराव्या लागतात. तुमच्या संस्थेबाहेरील लोकांसाठी गेस्ट रोल्स हे Pro फीचर आहे.

Vikunja एकाच वेळी अनेक प्रोव्हायडर्ससह OpenID Connect ला सपोर्ट करते. VIKUNJA_AUTH_OPENID_ENABLED=true सेट करा आणि त्यानंतर प्रत्येक प्रोव्हायडरसाठी VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_* व्हेरिएबल्सचा एक ब्लॉक जोडा. यामध्ये टीम्स आणि प्रति-प्रोजेक्ट शेअरिंगची सुविधा देखील आहे, ज्याची खऱ्या अर्थाने वीस लोकांच्या संस्थेला गरज असते.

Wekan मध्ये LDAP (lightweight directory access protocol), OAuth2, OIDC आणि SAML ला सपोर्ट आहे. Kanboard मध्ये LDAP इन-बिल्ट आहे आणि इतर सर्व गोष्टींसाठी एक जेनेरिक OAuth2 प्लगइन उपलब्ध आहे, तसेच यामध्ये प्रति-प्रोजेक्ट रोल्स आणि ग्रुप्सची सुविधाही आहे. Focalboard च्या स्टँडअलोन सर्व्हरमध्ये सिंगल साइन-ऑनची कोणतीही सुविधा नाही, हे त्याला वगळण्याचे दुसरे कारण आहे.

यापैकी कोणतीही सेवा तुम्ही स्वतः चालवत असलेल्या Authentik आयडेंटिटी प्रोव्हायडरसोबत वापरता येते, जे वीस लोकांना प्रत्येक ॲपसाठी वेगळा पासवर्ड देण्यापेक्षा अधिक चांगला पर्याय आहे.

तुम्ही तुमचे Trello बोर्ड इम्पोर्ट करू शकता का?

Planka मध्ये ही प्रक्रिया सर्वात सोपी आहे. Trello मधून बोर्ड JSON फॉरमॅटमध्ये एक्सपोर्ट करा, Planka मध्ये एक नवीन बोर्ड तयार करा, 'Import' वर क्लिक करा आणि Trello निवडा. मात्र, आधी मर्यादा वाचून घ्या, कारण त्या महत्त्वाच्या आहेत: युजर्स आणि अटॅचमेंट्स इम्पोर्ट होत नाहीत, प्रत्येक कार्डसाठी फक्त एकच चेकलिस्ट येते आणि Trello चे डीफॉल्ट JSON एक्सपोर्ट 1,000 ॲक्शन्सवर थांबते, ज्याची कोणतीही पूर्वसूचना मिळत नाही. निकालावर विश्वास ठेवण्यापूर्वी फाईल स्वतः तपासा.

Vikunja मध्ये Trello च्या OAuth फ्लोद्वारे इम्पोर्ट करता येते, जे Settings मध्ये 'Import from other services' अंतर्गत उपलब्ध आहे. प्रत्येक मायग्रेटरचा आयकॉन दिसण्यापूर्वी तो कॉन्फिगरेशनमध्ये इनेबल करणे आवश्यक आहे आणि VIKUNJA_SERVICE_PUBLICURL अचूक असणे गरजेचे आहे, कारण OAuth रीडायरेक्ट सर्व्हरवरून न होता तुमच्या ब्राउझरमधून होतो. Vikunja मध्ये Todoist, Microsoft To Do, TickTick आणि Wekan देखील इम्पोर्ट करता येतात.

Wekan त्याच्या इम्पोर्ट फॉर्ममध्ये पेस्ट केलेले Trello बोर्ड JSON स्वीकारते. Kanboard मध्ये इन-बिल्ट Trello इम्पोर्टर नाही, त्यामुळे जर तुम्हाला Trello चा अनेक वर्षांचा इतिहास हलवायचा असेल, तर हा पर्याय टाळणेच योग्य ठरेल.

मोबाईल अनुभव कसा आहे?

पाचपैकी केवळ Vikunja कडे अधिकृत मोबाईल ॲप्स उपलब्ध आहेत. प्रत्येक release सोबत Android आणि iOS बिल्ड्स दिले जातात. ॲप रिपॉझिटरीमध्ये याला 'alpha' असे संबोधले आहे, त्यामुळे याकडे मुख्य प्रवेशाऐवजी वेब इंटरफेसचा एक पूरक भाग म्हणून पहावे. Planka कडे प्रकल्पाचे कोणतेही अधिकृत ॲप नाही, जरी त्याचा वेब इंटरफेस रिस्पॉन्सिव्ह आहे आणि काही थर्ड-पार्टी क्लायंट्स उपलब्ध आहेत. Wekan आणि Kanboard हे केवळ वेबवर आधारित आहेत आणि Kanboard चा इंटरफेस स्पष्टपणे डेस्कटॉप स्क्रीनसाठी तयार केला आहे.

परवान्याबाबतचा प्रश्न आणि Planka वेगळे का आहे

Planka आता ओपन सोर्स राहिलेले नाही, आणि बहुतेक तुलनांमध्ये हा महत्त्वाचा मुद्दा वगळला जातो. याची सुरुवात MIT परवान्याअंतर्गत झाली होती, 2023 मध्ये ते AGPL-3.0 वर स्थलांतरित झाले आणि 2.0 मालिकेपासून ते PLANKA Community License अंतर्गत उपलब्ध आहे. हा PLANKA Software GmbH द्वारे नियंत्रित 'fair-code' परवाना आहे. GitHub वर याचा परवाना "Other" म्हणून दर्शवला जातो, कारण हा परवाना OSI द्वारे मान्यताप्राप्त नाही. स्वतःच्या वापरासाठी (self-hosting) हे मोफत आहे आणि वैयक्तिक, अंतर्गत, ना-नफा आणि शैक्षणिक वापरासाठी स्पष्टपणे परवानगी आहे. याच्या ॲक्सेसची पुनर्विक्री करणे किंवा इतर कंपन्यांसाठी सेवा म्हणून हे चालवणे यासाठी व्यावसायिक परवान्याची (commercial licence) आवश्यकता असते.

दोन लोकांसाठी हा एक योग्य व्यवहार आहे. मात्र, कंपनीसाठी वीस लोकांचे काम यात गुंतवण्यापूर्वी या अटी वाचणे आवश्यक आहे. इतर चार पर्याय पूर्णपणे ओपन सोर्स आहेत: Vikunja हे AGPL-3.0 आहे, Wekan आणि Kanboard हे MIT आहेत, आणि Focalboard हे Apache 2.0 आणि AGPL-3.0 यांचे मिश्रण आहे.

दोन निवडींसाठी पिन केलेले Compose फाइल्स

इमेज टॅग पिन करा. latest चा अर्थ असा आहे की पुढील docker compose pull तुम्हाला एका मेजर व्हर्जनवरून दुसऱ्या व्हर्जनवर नेऊ शकते आणि मेजर व्हर्जनमध्ये डेटाबेस मायग्रेशन्स होतात, जे सहजपणे मागे घेता येत नाहीत. खालील दोन्ही फाइल्स अपस्ट्रीम फाइल्स आहेत, ज्यामध्ये टॅग एका निश्चित रिलीजवर सेट केला आहे.

SQLite वर Vikunja, एक कंटेनर:

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) डेटा डिरेक्टरी तयार करा, कारण कंटेनर UID 1000 म्हणून चालतो आणि तो root-owned डिरेक्टरीमध्ये लिहू शकत नाही:

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

एक निरोगी स्टॅक सर्व्हिसला running म्हणून दर्शवतो आणि इन्फो एंडपॉइंट एक JSON परत करतो ज्यामध्ये version फील्ड असते. येथे 'Connection refused' येण्याचा अर्थ असा आहे की कंटेनर बंद झाला आहे. docker compose logs vikunja याचे कारण स्पष्ट करते आणि डेटाबेस फाइलवर परवानगीची त्रुटी (permission error) हे याचे सामान्य कारण आहे.

PostgreSQL वर Planka, दोन कंटेनर:

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 पासवर्डशिवाय कोणतेही कनेक्शन स्वीकारते. हे सुरक्षित आहे कारण डेटाबेस पोर्ट कधीही होस्टवर पब्लिश केले जात नाही, त्यामुळे फक्त त्याच Compose नेटवर्कवरील दुसरा कंटेनरच त्याला पोहोचू शकतो. postgres सर्व्हिसमध्ये ports: एन्ट्री जोडू नका.

कोणताही स्टॅक थेट इंटरनेटला तोंड देऊ नये. दोन्ही 127.0.0.1 वर बाइंड होतात, म्हणून समोर एक रिव्हर्स प्रॉक्सी ठेवा आणि तिथे TLS (transport layer security) टर्मिनेट करा. अनेक Compose ॲप्सच्या समोर Traefik वापरणे हा यासाठीचा सामान्य मार्ग आहे, जेव्हा तुम्ही एकापेक्षा जास्त गोष्टी होस्ट करता, आणि Docker Compose मूलभूत मार्गदर्शक या पानावर वगळलेल्या या फाइल्सच्या भागांची माहिती देते.

तुमचे बोर्ड एक डेटाबेस आहे, त्यामुळे त्याचा बॅकअप घ्या

बोर्ड टूल शांतपणे निकामी होते. जोपर्यंत एखादे व्हॉल्यूम गहाळ होत नाही तोपर्यंत कोणाच्याही लक्षात बॅकअप नसल्याची बाब येत नाही, आणि खराब झालेली SQLite फाईल सामान्यपणे उघडते आणि database disk image is malformed आठवड्यांनंतर त्रुटी दर्शवते.

चालू असलेली SQLite फाईल कधीही cp ने कॉपी करू नका. कॉपी करताना लिहिण्याची प्रक्रिया (write) मध्येच अडकू शकते, त्यामुळे आर्काइव्ह पूर्ण दिसते परंतु रिस्टोर केल्यावर डेटाबेसमध्ये ओळी (rows) गहाळ असतात. कॉपी करण्यासाठी लागणाऱ्या काही सेकंदांसाठी सर्व्हिस थांबवा:

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 चे संरक्षण करत आहात त्यावरच साठवलेली प्रत हा बॅकअप नसतो. restic backups from a VPS मध्ये या विषयाचा अर्धा भाग कव्हर केला आहे.

दोन शिफारसी

दोन व्यक्तींसाठी 2 GB VPS: Planka वापरा. हे दिसण्यात आणि कार्यपद्धतीत Trello च्या सर्वात जवळ आहे. Trello मधील डेटा इम्पोर्ट करण्यासाठी फक्त एक फाईल ड्रॅग करायची असते आणि 280 MB आयडल मेमरी वापरल्यामुळे 2 GB पैकी बहुतेक मेमरी reverse proxy आणि इतर सेवांसाठी मोकळी राहते. Community License अंतर्गत दोन व्यक्तींची अंतर्गत टीम हे विनामूल्य वापरू शकते. जर तुम्हाला source-available लायसन्सवर अवलंबून राहायचे नसेल, तर त्याच सर्व्हरसाठी 110 MB मेमरी वापरणारे Vikunja (SQLite सह) हा एक open-source पर्याय आहे.

संस्थेतील वीस व्यक्तींसाठी: PostgreSQL वर Vikunja चालवा. या आकाराच्या टीमसाठी तुम्हाला वीस स्वतंत्र पासवर्डऐवजी OpenID Connect ची गरज असते. तुम्हाला टीम्स आणि प्रोजेक्ट-निहाय शेअरिंगची आवश्यकता असते आणि कामाचा मोठा भाग फक्त बोर्डवर मावत नाही, त्यामुळे List, Table आणि Gantt व्ह्यूज केवळ अतिरिक्त सोय न राहता आवश्यक ठरतात. AGPL-3.0 लायसन्समुळे कर्मचाऱ्यांची संख्या वाढली तरी लायसन्सबाबत कोणतीही अडचण येत नाही. याला SQLite ऐवजी PostgreSQL द्या, reverse proxy च्या मागे ठेवा आणि दररोजचा डेटा डंप सर्व्हरच्या बाहेर इतरत्र सुरक्षित ठेवा.

जर सर्व्हरची RAM 1 GB पेक्षा कमी असेल, तर वरील दोन्ही पर्याय लागू होत नाहीत. अशा वेळी 70 MB मेमरी वापरणारे Kanboard निवडा. तुम्हाला तुमचे Trello कार्ड्स पुन्हा टाईप करावे लागतील हे स्वीकारा आणि वाचलेली मेमरी 2026 साठीच्या self-hosting शॉर्टलिस्ट मधील इतर गोष्टींसाठी वापरा. तुम्ही निवडलेल्या कोणत्याही टूलची सविस्तर इन्स्टॉलेशन प्रक्रिया त्याच्या स्वतंत्र मार्गदर्शिकेमध्ये दिली आहे. हे पान केवळ निवडीसाठी आहे.

FAQ

सर्वात कमी RAM वापरणारा self-hosted Trello पर्याय कोणता आहे?

Kanboard, जो साधारणपणे 70 MB RAM वापरतो, कारण तो PHP आणि SQLite वर आधारित आहे आणि विनंत्यांच्या दरम्यान मेमरीमध्ये काहीही साठवून ठेवत नाही. त्यानंतर Vikunja चा क्रमांक लागतो, जो एकच Go binary म्हणून सुमारे 110 MB RAM वापरतो. Wekan हा सर्वात जास्त मेमरी वापरणारा पर्याय आहे, जो सुमारे 750 MB RAM घेतो, कारण Meteor प्रत्येक कनेक्ट केलेल्या ब्राउझरसाठी Node मेमरीमध्ये एक live query layer राखून ठेवतो. हे आकडे केवळ सरासरी आहेत, त्यामुळे तुमचा स्टॅक idle असताना docker stats वापरून स्वतःची मोजणी करा.

मी माझ्या Trello बोर्ड्सना self-hosted टूलमध्ये इम्पोर्ट करू शकतो का?

Planka आणि Wekan हे दोन्ही Trello चे JSON बोर्ड एक्सपोर्ट थेट स्वीकारतात. Vikunja हे Trello च्या OAuth फ्लोद्वारे इम्पोर्ट करते आणि त्यासाठी इंटरफेसमध्ये दिसण्यापूर्वी कॉन्फिगरेशनमध्ये migrator सक्षम करणे आवश्यक असते. Kanboard मध्ये अंगभूत इम्पोर्टर नाही. दोन मर्यादा लक्षात ठेवा: Planka युजर्स किंवा अटॅचमेंट्स इम्पोर्ट करत नाही आणि प्रति कार्ड फक्त एकच चेकलिस्ट हाताळते, तसेच Trello चे डीफॉल्ट JSON एक्सपोर्ट 1000 क्रियांनंतर थांबते आणि ते ट्रंकेट (truncated) झाल्याची कोणतीही चेतावणी देत नाही.

Focalboard हा 2026 मध्ये अजूनही एक चांगला पर्याय आहे का?

नाही. शेवटची स्टँडअलोन रिलीज, v8.0.0, जून 2024 मधील आहे, जी 5 ऑगस्ट 2026 रोजी या तुलनेच्या तपासणीपूर्वी 783 दिवस जुनी होती आणि README मध्ये नमूद आहे की रिपॉझिटरी सध्या मेंटेन केली जात नाही. Mattermost ने बोर्ड डेव्हलपमेंट फक्त एका वेगळ्या रिपॉझिटरीमध्ये प्लगइन म्हणून सुरू ठेवली आहे, त्यामुळे तुम्ही जो सर्व्हर self-host कराल तो भाग बंद झाला आहे. त्याऐवजी Planka किंवा Vikunja निवडा.

Planka अजूनही open source आहे का?

OSI व्याख्येनुसार नाही. Planka पूर्वी MIT लायसन्स अंतर्गत होते, 2023 मध्ये ते AGPL-3.0 वर गेले आणि 2.0 आवृत्तीपासून ते PLANKA Community License अंतर्गत वितरित केले जाते. वैयक्तिक, अंतर्गत, ना-नफा आणि शैक्षणिक वापरासाठी self-hosting मोफत आहे. प्रवेशाची पुनर्विक्री करण्यासाठी किंवा तृतीय पक्षांसाठी सेवा म्हणून चालवण्यासाठी व्यावसायिक लायसन्स आवश्यक आहे, तसेच कॅलेंडर व्ह्यू, गेस्ट रोल्स आणि रिकरिंग कार्ड्स हे Pro टियरमध्ये आहेत. जर OSI-मान्य लायसन्स ही तुमची मुख्य अट असेल, तर Vikunja हे AGPL-3.0 आणि Kanboard हे MIT लायसन्स अंतर्गत उपलब्ध आहेत.

मला PostgreSQL ची गरज आहे की SQLite पुरेसे आहे?

Vikunja, Kanboard आणि Focalboard डीफॉल्टनुसार SQLite वापरतात, जे एका सर्व्हरवर काही लोकांच्या वापरासाठी पुरेसे आहे. Planka साठी PostgreSQL आवश्यक आहे आणि त्यात SQLite चा पर्याय नाही. जेव्हा एकाच वेळी अनेक लोक डेटा लिहित असतील तेव्हा PostgreSQL वर स्थलांतर करा, कारण SQLite रायट्सना (writes) क्रमाने (serialise) लावते आणि व्यस्त इन्स्टन्स database is locked एरर देऊ शकतो. तसेच SQLite फाईल नेटवर्क शेअरवर ठेवू नका: Kanboard चे डॉक्युमेंटेशन याच कारणास्तव NFS वर SQLite वापरण्याविरुद्ध चेतावणी देते.