بهترین جایگزین‌های Trello برای میزبانی شخصی (Self-hosted)

کدام جایگزین Trello برای میزبانی شخصی (self-hosted) مناسب است؟

سه جایگزین برای Trello جهت میزبانی شخصی ارزش بررسی دارند: Planka اگر به دنبال محیط دقیقاً مشابه Trello و قابلیت وارد کردن فایل‌های آن هستید، Vikunja زمانی که تیم شما به قابلیت single sign-on و امکاناتی فراتر از یک برد ساده نیاز دارد، و Kanboard زمانی که VPS (سرور مجازی) شما منابع محدودی دارد. پروژه جدیدی را روی Focalboard شروع نکنید. سرور مستقل آن در 783 روز گذشته هیچ نسخه جدیدی نداشته است و فایل README آن اکنون درخواست جذب نگهدارنده (maintainer) دارد.

Wekan پنجمین ابزار از 5 ابزار موجود در این لیست است. این ابزار کار می‌کند، اما چندین برابر سایر گزینه‌ها حافظه (RAM) مصرف می‌کند. تمام نسخه‌ها، مجوزها و تاریخ‌های زیر در تاریخ 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 یک دقیقه پس از بالا آمدن پشته (stack) گزارش می‌دهد. از این اعداد برای تخمین پلن استفاده کنید و سپس مقادیر واقعی محیط خود را اندازه‌گیری کنید. الگوی مصرف اهمیت بیشتری نسبت به عدد دقیق مگابایت دارد.

Kanboard با 70 مگابایت، کمترین مصرف را دارد زیرا مبتنی بر PHP و SQLite است. هیچ پردازش طولانی‌مدتی برای نگهداری بردها در حافظه وجود ندارد، بنابراین کانتینر بین درخواست‌ها تقریباً هیچ مصرفی ندارد. Vikunja یک فایل اجرایی Go واحد با 110 مگابایت است و چون SQLite دیتابیس پیش‌فرض آن است، یک کانتینر کل پشته را تشکیل می‌دهد. Planka به 280 مگابایت نیاز دارد زیرا همیشه شامل دو کانتینر است: یک سرور Node و دیتابیس PostgreSQL. برای Planka گزینه SQLite وجود ندارد، بنابراین دیتابیس آن قابل تغییر نیست.

Wekan با 750 مگابایت در این لیست قرار می‌گیرد زیرا یک برنامه Meteor است. Meteor یک لایه کوئری زنده را در حافظه Node نگه می‌دارد و هر تغییر در برد را از طریق WebSocket به تمام مرورگرهای باز ارسال می‌کند؛ بنابراین مصرف حافظه آن به‌جای ثابت ماندن، با افزایش تعداد کاربران متصل رشد می‌کند. روی یک VPS با 1 گیگابایت رم، Wekan بالا می‌آید اما اولین باری که چند نفر یک برد بزرگ را باز کنند، متوقف می‌شود. نشانه این وضعیت، کانتینری است که ناپدید شده و با کد خروج 137 بازمی‌گردد که docker compose ps آن را به صورت یک حلقه راه‌اندازی مجدد (restart loop) نشان می‌دهد. این مورد را روی هاست با dmesg -T | grep -i "out of memory" تأیید کنید، زیرا مکانیزم OOM Killer (قاتل حافظه) هسته سیستم‌عامل، هیچ پیامی به خود برنامه ارسال نمی‌کند.

وابستگی به دیتابیس، نیمی از کار پشتیبان‌گیری شما را تعیین می‌کند، بنابراین در اینجا هر کدام در یک خط آمده‌اند: Planka به PostgreSQL نیاز دارد. Vikunja به‌صورت پیش‌فرض از SQLite استفاده می‌کند و از PostgreSQL، MySQL و MariaDB نیز پشتیبانی می‌کند. Kanboard به‌صورت پیش‌فرض از SQLite استفاده می‌کند و از MySQL، MariaDB و PostgreSQL نیز پشتیبانی می‌کند؛ مستندات آن PostgreSQL را توصیه کرده و نسبت به استفاده از SQLite روی NFS (سیستم فایل شبکه) هشدار می‌دهد. Focalboard به‌صورت پیش‌فرض از SQLite استفاده می‌کند. Wekan از پروتکل MongoDB پشتیبانی می‌کند و فایل Compose پیش‌فرض آن اکنون همراه با FerretDB v1 و یک backend داخلی SQLite عرضه می‌شود (به‌جای یک سرور واقعی 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 توسعه قابلیت برد (board) را به یک افزونه در مخزنی جداگانه منتقل کرده و فایل README نسخه مستقل اعلام می‌کند که این مخزن در حال حاضر پشتیبانی نمی‌شود. این تنها پاسخ منفی قطعی در این مقایسه است. سایر موارد، موضوعاتی هستند که باید بر اساس اولویت‌ها سنجیده شوند.

وضعیت Planka با 109 روز برای پروژه‌ای که در سال چند نسخه منتشر می‌کند، مطلوب است. نسخه 2.1.1 در آوریل 2026 عرضه شده است. پروژه Kanboard نسخه v1.2.53 را 12 روز پیش از بررسی منتشر کرد و دو نسخه پیش از آن نیز در مارس و آوریل 2026 ارائه شده بودند.

پروژه‌های Vikunja و Wekan هر دو در فاصله یک روز از زمان بررسی، نسخه جدید منتشر کردند، اما باید به این دو مورد با دید متفاوتی نگاه کرد. Vikunja نسخه v2.5.0 را به عنوان یک انتشار جزئی (minor release) معمولی برچسب‌گذاری کرد. Wekan نسخه‌های v10.65، v10.66 و v10.67 را در یک روز منتشر کرد که این روند، روال عادی آن است. انتشار مکرر به معنای یک هدف پایدار نیست. با انتخاب Wekan، شما در حال انتخاب مسیری هستید که شماره نسخه آن به‌سرعت تغییر می‌کند؛ بنابراین حتماً tag را ثابت (pin) کنید و پیش از هر بار به‌روزرسانی، یادداشت‌های انتشار را مطالعه کنید.

آیا چیزی فراتر از یک برد دریافت می‌کنید؟

بیشتر مطالب مقایسه‌ای در حد «شبیه به Trello است» متوقف می‌شوند. این محور تصمیم‌گیری، اهمیت بیشتری نسبت به میزان RAM دارد، زیرا برد (board) برای هر کاری که مهلت زمانی (deadline) داشته باشد، ساختار مناسبی نیست.

• Planka فقط یک ابزار برد است و هیچ چیز دیگری نیست: پروژه، برد، لیست، کارت، برچسب، چک‌لیست، کامنت و فایل‌های پیوست. نماهای تقویم و نقشه تا اوت 2026 جزو ویژگی‌های نسخه Pro هستند.
• Vikunja چهار نما را برای یک مجموعه از وظایف ارائه می‌دهد: لیست، کانبان، جدول و گانت. یک وظیفه فقط یک بار وجود دارد و شما به‌جای کپی کردن آن، نما را تغییر می‌دهید.
• Kanboard بردهایی با محدودیت کار در جریان (WIP)، زیروظایف، پیوست‌ها، کامنت‌ها، عملیات خودکار و یک زبان پرس‌وجوی کوچک برای فیلتر کردن است. در صفحه اصلی آن ذکر شده که «تعداد ویژگی‌ها به‌صورت داوطلبانه محدود شده است» که توصیف منصفانه‌ای است.
• Wekan بردهایی با خطوط شناور (swimlanes) به همراه چک‌لیست، فیلدهای سفارشی، یک API از نوع REST و وب‌هوک‌ها است.
• Focalboard نماهای برد، جدول و تقویم را روی همان کارت‌ها ارائه می‌داد. این مورد صرفاً برای کامل بودن لیست در اینجا ذکر شده است.

اگر آنچه واقعاً نیاز دارید یک ویکی است که قابلیت ردیابی وظایف به آن متصل باشد، این مقایسه برای شما مناسب نیست. BookStack, Wiki.js and Outline این ساختار را پوشش می‌دهند و جایگزین‌های خودمیزبانی‌شده Notion فضای کاری همه‌کاره را بررسی می‌کنند.

دسترسی چندکاربره و ورود یکپارچه (SSO)

نرم‌افزار Planka در نسخه رایگان Community از OpenID Connect پشتیبانی می‌کند. فایل رسمی Compose تنظیمات مربوطه را به‌صورت کامنت‌شده در خود دارد که شامل OIDC_ISSUER، OIDC_CLIENT_ID و OIDC_CLIENT_SECRET می‌شود؛ بنابراین به‌جای ارتقا، کافی است کامنت این موارد را حذف کنید. نقش‌های مهمان برای افراد خارج از سازمان، از ویژگی‌های نسخه Pro است.

نرم‌افزار Vikunja از OpenID Connect با چندین ارائه‌دهنده به‌طور هم‌زمان پشتیبانی می‌کند. مقدار VIKUNJA_AUTH_OPENID_ENABLED=true را تنظیم کنید و سپس برای هر ارائه‌دهنده، یک بلوک از متغیرهای VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_* اضافه کنید. این نرم‌افزار همچنین دارای قابلیت تیم‌بندی و اشتراک‌گذاری در سطح پروژه است که دقیقاً همان چیزی است که یک سازمان 20 نفره به آن نیاز دارد.

نرم‌افزار Wekan از LDAP (پروتکل سبک دسترسی به دایرکتوری)، OAuth2، OIDC و SAML پشتیبانی می‌کند. نرم‌افزار Kanboard دارای قابلیت LDAP داخلی و یک پلاگین عمومی OAuth2 برای سایر موارد است، به‌علاوه نقش‌ها و گروه‌های تعریف‌شده برای هر پروژه. سرور مستقل Focalboard هیچ‌گونه قابلیت ورود یکپارچه (SSO) ندارد که این خود دومین دلیل برای کنار گذاشتن آن است.

هر یک از این ابزارها با یک ارائه‌دهنده هویت Authentik که خودتان میزبانی می‌کنید به‌خوبی کار می‌کنند؛ این راهکار معمولاً بسیار بهتر از آن است که به 20 نفر، برای هر برنامه یک رمز عبور جداگانه بدهید.

آیا امکان وارد کردن بردهای Trello وجود دارد؟

Planka ساده‌ترین مسیر را ارائه می‌دهد. برد را از Trello به صورت JSON خروجی بگیرید، در Planka یک برد جدید بسازید، روی Import کلیک کنید و Trello را انتخاب نمایید. ابتدا محدودیت‌ها را مطالعه کنید، زیرا این محدودیت‌ها واقعی هستند: کاربران و پیوست‌ها وارد نمی‌شوند، تنها یک چک‌لیست برای هر کارت منتقل می‌شود و خروجی JSON پیش‌فرض Trello در 1000 عملیات متوقف می‌شود بدون آنکه هشداری مبنی بر ناقص بودن داده‌ها بدهد. پیش از اعتماد به نتیجه، فایل را شخصاً بررسی کنید.

Vikunja از طریق جریان OAuth در Trello و از مسیر Settings و سپس "Import from other services" عملیات وارد کردن را انجام می‌دهد. هر ابزار مهاجرت باید پیش از ظاهر شدن آیکون آن در تنظیمات فعال شود و VIKUNJA_SERVICE_PUBLICURL باید صحیح باشد، زیرا تغییر مسیر (redirect) در OAuth در مرورگر شما رخ می‌دهد و نه از سمت سرور. Vikunja همچنین از Todoist، Microsoft To Do، TickTick و Wekan نیز پشتیبانی می‌کند.

Wekan فایل JSON برد Trello را که در فرم وارد کردن آن کپی (paste) کنید، می‌پذیرد. Kanboard هیچ ابزار داخلی برای وارد کردن از Trello ندارد؛ این اصلی‌ترین دلیل برای صرف‌نظر کردن از آن است، اگر قصد دارید تاریخچه چندین ساله خود در Trello را منتقل کنید.

تجربه کار با موبایل چگونه است؟

Vikunja تنها گزینه از میان این 5 مورد است که اپلیکیشن‌های رسمی موبایل دارد. نسخه‌های Android و iOS همراه با هر release منتشر می‌شوند. مخزن اپلیکیشن، وضعیت خود را alpha توصیف می‌کند؛ بنابراین به آن به چشم یک ابزار مکمل برای رابط وب نگاه کنید، نه روش اصلی دسترسی. Planka اپلیکیشن رسمی از سوی پروژه ندارد، هرچند رابط وب آن واکنش‌گرا (responsive) است و کلاینت‌های شخص‌ثالث نیز برای آن وجود دارند. Wekan و Kanboard فقط تحت وب هستند و رابط کاربری Kanboard مشخصاً برای نمایشگرهای دسکتاپ طراحی شده است.

پرسش مجوز و دلیل تفاوت Planka

Planka دیگر متن‌باز (open source) نیست و این واقعیتی است که اکثر مقایسه‌ها از آن غافل می‌شوند. این پروژه تحت مجوز MIT آغاز شد، در سال 2023 به AGPL-3.0 تغییر یافت و از سری 2.0 به بعد، تحت PLANKA Community License عرضه می‌شود؛ یک مجوز fair-code که متعلق به PLANKA Software GmbH است. گیت‌هاب مجوز آن را به عنوان "Other" گزارش می‌کند، زیرا این مجوز مورد تأیید OSI نیست. میزبانی شخصی آن برای اعضای تیم خودتان رایگان است و صراحتاً مجاز شمرده شده که شامل استفاده‌های شخصی، داخلی، غیرانتفاعی و آموزشی می‌شود. فروش دسترسی به آن یا اجرای آن به عنوان یک سرویس برای شرکت‌های دیگر، نیازمند دریافت مجوز تجاری است.

برای دو نفر، این یک معامله منصفانه است. برای یک شرکت، این شرطی است که باید پیش از آنکه کار بیست نفر به آن وابسته شود، مطالعه گردد. چهار گزینه دیگر، متن‌باز معمولی هستند: Vikunja تحت مجوز AGPL-3.0، Wekan و Kanboard تحت مجوز MIT، و Focalboard ترکیبی از Apache 2.0 و AGPL-3.0 است.

فایل‌های Compose ثابت‌شده برای دو انتخاب

تگ image را ثابت (Pin) کنید. latest به این معناست که docker compose pull بعدی می‌تواند شما را به یک نسخه اصلی (major version) جدید منتقل کند و نسخه‌های اصلی، مهاجرت‌های دیتابیس را اجرا می‌کنند که به‌سادگی قابل بازگشت نیستند. هر دو فایل زیر، نسخه‌های اصلی (upstream) هستند که تگ آن‌ها روی یک release واقعی ثابت شده است.

Vikunja روی SQLite، یک کانتینر:

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 است بنویسد:

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

یک stack سالم، سرویس را به صورت running نشان می‌دهد و endpoint اطلاعات، یک JSON شامل فیلد version برمی‌گرداند. خطای Connection refused در اینجا به این معناست که کانتینر خارج شده است. docker compose logs vikunja دلیل آن را مشخص می‌کند و خطای مجوز (permission error) روی فایل دیتابیس، دلیل رایجی است.

Planka روی PostgreSQL، دو کانتینر:

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 هر اتصالی را بدون رمز عبور می‌پذیرد. این کار تنها به این دلیل امن است که پورت دیتابیس هرگز روی host منتشر (publish) نمی‌شود، بنابراین تنها چیزی که می‌تواند به آن دسترسی داشته باشد، کانتینر دیگر در همان شبکه Compose است. هیچ ورودی ports: به سرویس postgres اضافه نکنید.

هیچ‌کدام از این stackها نباید مستقیماً با اینترنت در ارتباط باشند. هر دو به 127.0.0.1 متصل می‌شوند، بنابراین یک reverse proxy در مقابل آن‌ها قرار دهید و TLS (امنیت لایه انتقال) را در آنجا خاتمه دهید. استفاده از Traefik در مقابل چندین برنامه Compose روش معمول برای انجام این کار است، زمانی که بیش از یک سرویس را میزبانی می‌کنید، و راهنمای اصول Docker Compose بخش‌هایی از این فایل‌ها را که در این صفحه از آن‌ها عبور شده است، پوشش می‌دهد.

تختهٔ شما یک پایگاه داده است، پس از آن نسخهٔ پشتیبان تهیه کنید

ابزار تخته ممکن است بدون هیچ هشداری از کار بیفتد. تا زمانی که یک volume از بین نرود، کسی متوجه نبود نسخهٔ پشتیبان نمی‌شود؛ یک فایل 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 خروجی (dump) بگیرید و volume مربوط به فایل‌های آپلود شده را جداگانه کپی کنید، زیرا پیوست‌ها در پایگاه داده ذخیره نمی‌شوند:

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 نام واقعی volume را چاپ می‌کند که شامل نام پروژه Compose شما و به دنبال آن _data است. اگر نامی را وارد کنید که وجود ندارد، یک volume خالی ایجاد می‌شود و شما یک آرشیو معتبر اما خالی بدون دریافت هیچ خطایی خواهید داشت؛ بنابراین پس از اتمام کار، حجم فایل را بررسی کنید.

سپس آن را یک بار در یک stack آزمایشی روی همان سرور بازیابی کنید و کارتی را که به یاد دارید باز کنید. نسخه‌ای که هرگز بازیابی نکرده‌اید، فقط یک حدس است. آرشیوها را از سرور خارج کنید، زیرا نسخه‌ای که روی همان VPS ذخیره شده باشد، نسخهٔ پشتیبان محسوب نمی‌شود. پشتیبان‌گیری restic از یک VPS این بخش را پوشش می‌دهد.

دو پیشنهاد

برای دو نفر روی یک VPS با 2 گیگابایت رم: از Planka استفاده کنید. این ابزار از نظر ظاهر و رفتار، نزدیک‌ترین گزینه به Trello است، فایل import مربوط به Trello را به‌سادگی با کشیدن و رها کردن (drag and drop) وارد می‌کند و با مصرف 280 مگابایت رم در حالت بیکار، بخش عمده‌ای از 2 گیگابایت حافظه را برای reverse proxy و سایر سرویس‌های میزبانی‌شده آزاد می‌گذارد. Community License این ابزار، یک تیم داخلی دو نفره را به‌صورت رایگان پوشش می‌دهد. اگر ترجیح می‌دهید به لایسنس‌های source-available وابسته نباشید، Vikunja با دیتابیس SQLite و مصرف 110 مگابایت رم، گزینه متن‌باز (open-source) برای همان سرور است.

برای بیست نفر در یک سازمان: Vikunja را روی PostgreSQL اجرا کنید. در این مقیاس، شما به جای مدیریت بیست رمز عبور محلی، به OpenID Connect نیاز دارید؛ همچنین به قابلیت تعریف تیم‌ها و اشتراک‌گذاری در سطح پروژه نیاز خواهید داشت و چون بخش بزرگی از کارها در قالب یک برد (board) نمی‌گنجد، نماهای List، Table و Gantt دیگر یک قابلیت جانبی نیستند. لایسنس AGPL-3.0 نیز به این معناست که با افزایش تعداد کاربران، دغدغه‌ای بابت لایسنس نخواهید داشت. دیتابیس PostgreSQL را به جای SQLite به آن اختصاص دهید، آن را پشت یک reverse proxy قرار دهید و نسخه پشتیبان روزانه را در مکانی خارج از آن سرور نگهداری کنید.

اگر سرور شما کمتر از 1 گیگابایت رم دارد، هیچ‌کدام از پاسخ‌های بالا مناسب نیستند. از Kanboard با مصرف 70 مگابایت رم استفاده کنید، بپذیرید که باید کارت‌های Trello خود را دوباره تایپ کنید و حافظه صرفه‌جویی‌شده را صرف سایر ابزارهای موجود در فهرست کوتاه خود-میزبانی برای سال 2026 کنید. نصب دقیق هر ابزاری که انتخاب می‌کنید، در راهنمای اختصاصی همان ابزار توضیح داده شده است. این صفحه تنها به انتخاب ابزار می‌پردازد.

FAQ

کدام جایگزین Trello برای self-hosting کمترین میزان RAM را مصرف می‌کند؟

Kanboard، با مصرف تقریبی 70 مگابایت در حالت idle؛ زیرا این ابزار مبتنی بر PHP و SQLite است و بین درخواست‌ها هیچ داده‌ای را در حافظه نگه نمی‌دارد. Vikunja در رتبه بعدی با حدود 110 مگابایت به عنوان یک باینری Go قرار دارد. Wekan سنگین‌ترین گزینه با حدود 750 مگابایت است، زیرا Meteor یک لایه پرس‌وجوی زنده را در حافظه Node برای هر مرورگر متصل نگه می‌دارد. پس از اینکه stack در حالت idle قرار گرفت، میزان مصرف را با docker stats اندازه‌گیری کنید، چرا که این ارقام مقادیر معمول هستند و تضمینی برای آن‌ها وجود ندارد.

آیا می‌توانم بردهای Trello را به یک ابزار self-hosted وارد کنم؟

Planka و Wekan هر دو خروجی JSON بردهای Trello را مستقیماً می‌پذیرند. Vikunja از طریق جریان OAuth در Trello عملیات واردسازی (import) را انجام می‌دهد و برای نمایش در رابط کاربری، باید migrator در فایل پیکربندی فعال شود. Kanboard هیچ ابزار واردسازی داخلی ندارد. دو محدودیت را باید در نظر بگیرید: Planka کاربران یا پیوست‌ها را وارد نمی‌کند و فقط یک چک‌لیست برای هر کارت مدیریت می‌کند؛ همچنین خروجی JSON پیش‌فرض Trello در 1000 عملیات متوقف می‌شود بدون آنکه به شما هشدار دهد که داده‌ها ناقص (truncated) هستند.

آیا Focalboard هنوز در سال 2026 انتخاب مناسبی است؟

خیر. آخرین نسخه مستقل، v8.0.0، مربوط به ژوئن 2024 است که 783 روز پیش از بررسی این مقایسه در تاریخ 5 اوت 2026 بوده است و فایل 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 عملیات نوشتن را سریال‌سازی می‌کند و یک نمونه پرمشغله شروع به بازگرداندن database is locked می‌کند. همچنین فایل SQLite را روی network share قرار ندهید: مستندات Kanboard دقیقاً به همین دلیل نسبت به استفاده از SQLite روی NFS هشدار می‌دهد.