مقارنة بدائل Trello المستضافة ذاتياً

أي بديل مستضاف ذاتياً لـTrello ينبغي أن تختار؟

ثلاثة بدائل مستضافة ذاتياً لـTrello تستحق وقتك: اختر Planka إذا كنت تريد لوحة Trello نفسها وملف الاستيراد الخاص بها، وVikunja عندما يحتاج الفريق إلى تسجيل دخول موحّد وإمكانات تتجاوز اللوحة، وKanboard عندما تكون موارد VPS (الخادم الخاص الافتراضي) محدودة. لا تبدأ مشروعاً جديداً على Focalboard. فلم يُصدر خادمه المستقل إصداراً منذ 783 يوماً، ويطلب ملف README الخاص به الآن من أحد المشرفين تولّي صيانته.

يُعد Wekan خامس الأدوات البالغ عددها 5 هنا. وهو يعمل، لكنه يستهلك من الذاكرة أضعاف ما تستهلكه الأدوات الأخرى مجتمعة. تم التحقق من كل إصدار وترخيص وتاريخ أدناه في 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
  }
]

هذه أرقام الخمول المعتادة لتثبيت جديد لا يستخدمه أحد، وهي القيمة التي يعرضها docker stats بعد دقيقة من بدء المكدس. استخدمها لتقدير مواصفات الخطة، ثم قِس استهلاكك الفعلي. الأهم هو النمط العام، لا قيمة الميغابايت الدقيقة.

يحتاج Kanboard إلى 70 MB كحد أدنى لأنه يعمل بـPHP مع SQLite. لا توجد عملية تطبيق طويلة التشغيل تحتفظ بلوحاتك في الذاكرة، لذلك تكاد الحاوية لا تستهلك شيئاً بين الطلبات. يعمل Vikunja كملف Go ثنائي واحد ويحتاج إلى 110 MB، وقاعدة بياناته الافتراضية هي SQLite، لذلك تشكّل حاوية واحدة المكدس بأكمله. يحتاج Planka إلى 280 MB لأنه يتكون دائماً من حاويتين: خادم Node وPostgreSQL. لا يوفّر Planka خيار SQLite، لذلك لا يمكن الاستغناء عن قاعدة البيانات.

يحتاج Wekan إلى 750 MB لأنه تطبيق Meteor. يحتفظ Meteor بطبقة للاستعلامات الحية في ذاكرة Node، ويدفع كل تغيير في اللوحة إلى كل متصفح مفتوح عبر WebSocket. لذلك يزداد استهلاك الذاكرة مع عدد المستخدمين المتصلين بدلاً من بقائه ثابتاً. على VPS بسعة 1 GB، يبدأ Wekan ثم يتوقف عند فتح عدة مستخدمين لوحة كبيرة لأول مرة. تتمثل العلامة في اختفاء الحاوية ثم عودتها مع رمز الخروج 137، وهو ما يعرضه docker compose ps كحلقة إعادة تشغيل. أكّد ذلك على المضيف باستخدام dmesg -T | grep -i "out of memory"، لأن قاتل نفاد الذاكرة في النواة لا يرسل أي معلومات إلى التطبيق.

تحدد تبعية قاعدة البيانات نصف أعمال النسخ الاحتياطي، لذلك نلخصها في سطر واحد لكل أداة. يتطلب Planka PostgreSQL. يستخدم Vikunja SQLite افتراضياً، ويدعم أيضاً PostgreSQL وMySQL أو MariaDB. يستخدم Kanboard SQLite افتراضياً، ويدعم أيضاً MySQL وMariaDB وPostgreSQL، وتوصي وثائقه باستخدام PostgreSQL وتحذّر من SQLite على NFS (نظام ملفات شبكي). يستخدم Focalboard SQLite افتراضياً. يدعم Wekan بروتوكول MongoDB السلكي، ويأتي ملف Compose الافتراضي الخاص به الآن مع FerretDB v1 الذي يستخدم SQLite مضمّنة بدلاً من خادم MongoDB فعلي، مع توفير ملف Compose منفصل لـMongoDB 7 إذا أردت استخدامه.

ما المشاريع التي لا تزال قيد الصيانة؟

[
  {
    "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 الخاصة بالإصدار المستقل أن المستودع غير مُصان حالياً. هذه هي حالة «لا» الواضحة الوحيدة في هذه المقارنة. أما المشاريع الأخرى، فلكل منها مفاضلات.

تُعد مدة 109 يوماً لدى Planka جيدة لمشروع يُصدر بضعة إصدارات سنوياً. يعود الإصدار 2.1.1 إلى أبريل 2026. أصدر Kanboard الإصدار v1.2.53 قبل 12 يوماً من الفحص، كما صدر الإصداران السابقان له في مارس وأبريل 2026.

أصدر كل من Vikunja وWekan إصداراً خلال يوم من الفحص، لكن ينبغي تفسير هاتين المعلومتين بشكل مختلف. وضع Vikunja الوسم v2.5.0 لإصدار فرعي عادي. أما Wekan فوضع الوسوم v10.65 وv10.66 وv10.67 في اليوم نفسه، وهذا هو نمطه المعتاد. لا تعني الإصدارات المتكررة أن الهدف مستقر. عند استخدام Wekan، فأنت تختار متابعة رقم إصدار سريع التغير؛ لذلك ثبّت الوسم، واقرأ ملاحظات الإصدار قبل كل تحديث.

هل تحصل على أكثر من لوحة؟

تتوقف معظم مقالات المقارنة عند عبارة «يبدو مثل Trello». لكن هذا المحور يحسم الاختيار أكثر من حجم RAM، لأن اللوحة ليست مناسبة جيداً لأي شيء له موعد نهائي.

• Planka أداة للوحات فقط، ولا تقدم شيئاً آخر: المشاريع، واللوحات، والقوائم، والبطاقات، والتسميات، وقوائم التحقق، والتعليقات، والمرفقات. تُعدّ مشاهد التقويم والخريطة من ميزات Pro اعتباراً من August 2026.
• يوفّر Vikunja أربعة مشاهد لمجموعة المهام نفسها: List وKanban وTable وGantt. توجد المهمة مرة واحدة، ويمكنك تبديل المشهد بدلاً من تكرارها.
• يوفّر Kanboard لوحات مع حدود للعمل قيد التنفيذ، ومهام فرعية، ومرفقات، وتعليقات، وإجراءات تلقائية، ولغة استعلام صغيرة للتصفية. تقول صفحته الرئيسية نفسها: «عدد الميزات محدود طوعاً»، وهذا وصف دقيق.
• يوفّر Wekan لوحات مع مسارات سباحة، بالإضافة إلى قوائم التحقق، والحقول المخصصة، وواجهة REST (نقل الحالة التمثيلي)، وwebhooks.
• كان Focalboard يوفّر مشاهد اللوحة والجدول والتقويم للبطاقات نفسها. أُدرج هنا لاستكمال المقارنة.

إذا كان ما تريده فعلياً هو wiki مع بعض تتبع المهام المرفق به، فهذه المقارنة لا تناسبك. يغطي BookStack وWiki.js وOutline هذا النوع، بينما تغطي بدائل Notion المستضافة ذاتياً مساحة العمل المتكاملة.

الوصول متعدد المستخدمين وتسجيل الدخول الموحد

يدعم Planka بروتوكول OpenID Connect في إصدار Community المجاني. يتضمن ملف Compose الرسمي الإعدادات مع وضعها في التعليقات، ومنها OIDC_ISSUER وOIDC_CLIENT_ID وOIDC_CLIENT_SECRET، لذلك عليك إزالة التعليق عنها بدلاً من الترقية. تُعد أدوار الضيوف للأشخاص خارج مؤسستك ميزة متاحة في إصدار Pro.

يدعم Vikunja بروتوكول OpenID Connect مع عدة موفّرين في الوقت نفسه. عيّن VIKUNJA_AUTH_OPENID_ENABLED=true، ثم أضف كتلة واحدة من متغيرات VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_* لكل موفّر. كما يوفّر الفرق والمشاركة لكل مشروع، وهذا هو ما تحتاج إليه مؤسسة تضم عشرين شخصاً فعلياً.

يدعم Wekan بروتوكول LDAP (بروتوكول الوصول إلى الدليل الخفيف)، وOAuth2، وOIDC، وSAML. يتضمن Kanboard دعماً مدمجاً لـLDAP ومكوّن OAuth2 عاماً لبقية الحالات، إضافة إلى الأدوار والمجموعات الخاصة بكل مشروع. لا يوفّر خادم Focalboard المستقل أي تسجيل دخول موحد، وهذا سبب ثانٍ لاستبعاده.

يمكن ربط أي من هذه الخيارات بـموفّر هوية Authentik تديره بنفسك، ويكون ذلك عادةً حلاً أفضل من منح عشرين شخصاً كلمة مرور منفصلة لكل تطبيق.

هل يمكنك استيراد لوحات Trello؟

يقدّم Planka أبسط مسار. صدّر اللوحة من Trello بتنسيق JSON، وأنشئ لوحة في Planka، ثم انقر على Import واختر Trello. اقرأ القيود أولاً، لأنها فعلية: لا يُستورد المستخدمون والمرفقات، ولا تنتقل إلا قائمة تحقق واحدة لكل بطاقة، كما يتوقف تصدير JSON الافتراضي من Trello عند 1,000 إجراء من دون تحذير يفيد بأنه اقتطع بقية البيانات. افحص الملف بنفسك قبل الوثوق بالنتيجة.

يستورد Vikunja البيانات عبر تدفق OAuth الخاص بـTrello، من Settings ثم "Import from other services". يجب تفعيل كل أداة ترحيل في ملف الإعدادات قبل ظهور أيقونتها، ويجب أن تكون VIKUNJA_SERVICE_PUBLICURL صحيحة، لأن إعادة توجيه OAuth تحدث في متصفحك وليس من الخادم. يستورد Vikunja أيضاً من Todoist وMicrosoft To Do وTickTick وWekan.

يقبل Wekan لصق JSON الخاص بلوحة Trello في نموذج الاستيراد. لا يوفّر Kanboard أداة مضمّنة لاستيراد Trello، ولذلك يكون تجنّبه الخيار الرئيسي إذا كانت لديك سنوات من سجل Trello تريد نقلها.

ما تجربة الاستخدام على الأجهزة المحمولة؟

Vikunja هو الوحيد من بين المنتجات الخمسة الذي يوفّر تطبيقات محمولة رسمية. تصدر إصدارات Android وiOS مع كل إصدار جديد، ويصف مستودع التطبيق نفسه بأنه في المرحلة alpha، لذلك استخدمه كمكمّل لواجهة الويب، لا كطريقة الاستخدام الرئيسية. لا يوفّر مشروع Planka تطبيقاً رسمياً، مع أن واجهة الويب فيه متجاوبة، وتتوفر عملاء من جهات خارجية. يعمل Wekan وKanboard عبر الويب فقط، كما أن واجهة Kanboard مصممة بوضوح لشاشة سطح المكتب.

مسألة الترخيص، ولماذا يختلف Planka

لم يعد Planka مفتوح المصدر، وهذه حقيقة تستبعدها معظم المقارنات. بدأ المشروع بترخيص MIT، ثم انتقل إلى AGPL-3.0 في 2023، ومن سلسلة 2.0 أصبح يُوزَّع بموجب PLANKA Community License، وهو ترخيص fair-code تملكه PLANKA Software GmbH. يعرض GitHub ترخيصه على أنه "Other" لأن هذا الترخيص غير معتمد من OSI. يمكنك استضافته ذاتياً لأفراد مؤسستك مجاناً، وهذا مسموح به صراحةً للاستخدام الشخصي والداخلي وغير الربحي والتعليمي. أما إعادة بيع الوصول إليه، أو تشغيله كخدمة لشركات أخرى، فتتطلب ترخيصاً تجارياً.

هذا ترتيب عادل لشخصين. أما الشركة، فعليها قراءة هذا الشرط قبل إدخال عمل عشرين شخصاً فيه. أما المشاريع الأربعة الأخرى فهي مفتوحة المصدر وفق التراخيص المعتادة: Vikunja مرخّص بموجب AGPL-3.0، وWekan وKanboard بموجب MIT، بينما يستخدم Focalboard مزيجاً من Apache 2.0 وAGPL-3.0.

ملفات Compose المثبّتة للاختيارين

ثبّت وسم الصورة. تعني latest أن docker compose pull التالية قد تنقلك إلى إصدار رئيسي مختلف، وأن الإصدارات الرئيسية تشغّل عمليات ترحيل لقاعدة البيانات لا يمكنك عكسها بسهولة. الملفان أدناه هما ملفا upstream مع تثبيت الوسم على إصدار فعلي.

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

أنشئ دليل البيانات بالمالك الصحيح أولاً، لأن الحاوية تعمل باستخدام 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

تُظهر الحزمة السليمة أن الخدمة بحالة running، وأن نقطة نهاية المعلومات تُرجع JSON يحتوي على حقل version. يعني رفض الاتصال هنا أن الحاوية توقفت. يوضح docker compose logs vikunja السبب، ويُعد خطأ الصلاحيات في ملف قاعدة البيانات السبب الشائع.

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 يقبل أي اتصال من دون كلمة مرور. وهذا آمن فقط لأن منفذ قاعدة البيانات لا يُنشر على المضيف، ولذلك فإن الحاوية الأخرى على شبكة Compose نفسها هي الشيء الوحيد القادر على الوصول إليه. لا تضف إدخال ports: إلى خدمة postgres.

يجب ألا تكون أي من الحزمتين متاحة مباشرة عبر الإنترنت. كلتاهما تربطان على 127.0.0.1، لذلك ضع Reverse Proxy أمامهما وأنهِ TLS (أمن طبقة النقل) هناك. تُعد طريقة وضع Traefik أمام عدة تطبيقات Compose الطريقة المعتادة لتنفيذ ذلك عند استضافة أكثر من خدمة، بينما يشرح دليل أساسيات Docker Compose الأجزاء التي تتجاوزها هذه الصفحة من هذه الملفات.

لوحتك عبارة عن قاعدة بيانات، لذا أنشئ لها نسخاً احتياطية

قد تتعطل أداة اللوحات بصمت. لا يلاحظ أحد فقدان النسخة الاحتياطية إلا بعد اختفاء وحدة تخزين، وقد يُفتح ملف 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 الذي تحميه ليست نسخة احتياطية. يشرح النسخ الاحتياطي باستخدام restic من VPS هذا الجزء.

توصيتان

شخصان على VPS بسعة 2 GB: شغّلا Planka. فهو الأقرب إلى Trello من حيث الشكل والسلوك، واستيراد Trello عبارة عن ملف تسحبه وتفلتُه، كما أن استهلاك الذاكرة في وضع الخمول البالغ 280 MB يترك معظم سعة 2 GB متاحةً للـreverse proxy ولأي خدمات أخرى تستضيفها. يغطي ترخيص Community فريقاً داخلياً من شخصين من دون تكلفة. وإذا كنت تفضّل عدم الاعتماد على ترخيص يتيح الشيفرة المصدرية، فإن Vikunja باستخدام SQLite، باستهلاك 110 MB، هو الخيار مفتوح المصدر على الخادم نفسه.

عشرون شخصاً في مؤسسة: شغّل Vikunja باستخدام PostgreSQL. عند هذا الحجم تحتاج إلى OpenID Connect بدلاً من عشرين كلمة مرور محلية، وتحتاج إلى الفرق والمشاركة على مستوى كل مشروع، كما أن جزءاً كبيراً من العمل لن يناسب لوحة، لذلك تصبح عروض List وTable وGantt أكثر من مجرد ميزة إضافية. يعني AGPL-3.0 أيضاً عدم الحاجة إلى مناقشة الترخيص مع زيادة عدد المستخدمين. استخدم PostgreSQL بدلاً من SQLite، وضعه خلف reverse proxy، واحتفظ بالتفريغ اليومي في مكان آخر غير هذا الخادم.

إذا كانت سعة الخادم أقل من 1 GB من RAM، فلا ينطبق أي من الخيارين. استخدم Kanboard باستهلاك 70 MB، وتقبّل إعادة إدخال بطاقات Trello يدوياً، واستفد من الذاكرة التي وفّرتها في شيء آخر من القائمة المختصرة للاستضافة الذاتية لعام 2026. يجب أن يرد دليل التثبيت التفصيلي للأداة التي تختارها في دليل مستقل. تقتصر هذه الصفحة على الاختيار.

FAQ

ما البديل المستضاف ذاتياً لـ Trello الذي يستخدم أقل قدر من RAM؟

يستخدم Kanboard نحو 70 MB أثناء الخمول، لأنه يعمل بـPHP مع SQLite ولا يحتفظ بشيء في الذاكرة بين الطلبات. يليه Vikunja بنحو 110 MB باعتباره ملف Go ثنائياً واحداً. أما Wekan فهو الأكثر استهلاكاً، بنحو 750 MB، لأن Meteor يحتفظ بطبقة استعلامات حية في ذاكرة Node لكل متصفح متصل. قِس الاستهلاك لديك باستخدام docker stats بعد خمول الحزمة، لأن هذه أرقام شائعة وليست ضماناً.

هل يمكنني استيراد لوحات Trello إلى أداة مستضافة ذاتياً؟

يستقبل كل من Planka وWekan تصدير لوحة Trello بصيغة JSON مباشرة. يستورد Vikunja البيانات عبر مسار OAuth الخاص بـTrello، ويجب تفعيل أداة الترحيل في الإعدادات قبل أن تظهر في الواجهة. لا يوفّر Kanboard أداة استيراد مدمجة. ضع حدّين في الحسبان: لا يستورد Planka المستخدمين أو المرفقات، ولا يتعامل إلا مع قائمة تحقق واحدة لكل بطاقة؛ كما يتوقف تصدير Trello الافتراضي بصيغة JSON عند 1,000 إجراء من دون تنبيهك إلى أنه اقتطع بقية البيانات.

هل لا يزال Focalboard خياراً جيداً في 2026؟

لا. يعود آخر إصدار مستقل، v8.0.0، إلى June 2024، أي قبل 783 يوماً من تاريخ التحقق من هذه المقارنة في 5 August 2026، ويذكر ملف README أن المستودع لا تتم صيانته حالياً. واصلت Mattermost تطوير اللوحات باعتبارها إضافة فقط في مستودع منفصل، لذلك فإن الجزء الذي ستستضيفه ذاتياً هو الذي توقف تطويره. اختر Planka أو Vikunja بدلاً منه.

هل لا يزال Planka مفتوح المصدر؟

ليس وفق تعريف OSI. كان Planka مرخّصاً بموجب MIT، ثم انتقل إلى AGPL-3.0 في 2023، ويُصدر بموجب PLANKA Community License بدءاً من الإصدار 2.0. الاستضافة الذاتية مجانية للاستخدام الشخصي والداخلي وغير الربحي والتعليمي. يتطلب إعادة بيع الوصول أو تشغيله كخدمة لأطراف ثالثة ترخيصاً تجارياً، كما أن عرض التقويم وأدوار الضيوف والبطاقات المتكررة متاحة ضمن فئة Pro. إذا كان الترخيص المعتمد من OSI شرطاً إلزامياً، فإن Vikunja يستخدم AGPL-3.0 وKanboard يستخدم MIT.

هل أحتاج إلى PostgreSQL، أم تكفي SQLite؟

يستخدم Vikunja وKanboard وFocalboard SQLite افتراضياً، وهي مناسبة لعدد قليل من الأشخاص على خادم واحد. يتطلب Planka PostgreSQL ولا يوفّر خيار SQLite. انتقل إلى PostgreSQL عندما يكتب عدة أشخاص في الوقت نفسه، لأن SQLite تسلسل عمليات الكتابة، ويبدأ مثيل مشغول بإرجاع database is locked. لا تضع ملف SQLite على مشاركة شبكية أيضاً؛ إذ تحذّر وثائق Kanboard من استخدام SQLite على NFS لهذا السبب تحديداً.