חלופות ל-Trello בניהול עצמי: השוואת כלים מומלצים

באיזו חלופה ל-Trello בניהול עצמי כדאי לבחור?

שלוש חלופות ל-Trello בניהול עצמי ראויות לתשומת לבכם: Planka אם אתם מחפשים את לוח ה-Kanban המדויק של Trello ואת היכולת לייבא קבצים ממנו, Vikunja כאשר הצוות זקוק ל-single sign-on וליכולות מעבר ללוח משימות בסיסי, ו-Kanboard כאשר ה-VPS (שרת וירטואלי פרטי) שלכם בעל משאבים מוגבלים. אל תתחילו פרויקט חדש על גבי Focalboard. השרת העצמאי שלו לא זכה ל-release מזה 783 ימים, וה-README שלו כעת מבקש מתחזק חדש.

Wekan הוא החמישי מבין 5 הכלים המופיעים כאן. הוא עובד, אך צורך פי כמה יותר זיכרון מכל שאר הכלים. כל גרסה, רישיון ותאריך המפורטים להלן נבדקו ב-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 מציג דקה לאחר עליית ה-stack. השתמשו בהם לצורך תכנון המשאבים, ולאחר מכן בצעו מדידה עצמאית. המבנה הארכיטקטוני חשוב יותר מהמספר המדויק במגה-בייט.

Kanboard מהווה את רף המינימום עם 70 MB, כיוון שמדובר ב-PHP עם SQLite. אין תהליך יישום שרץ ברקע ומחזיק את הלוחות בזיכרון, לכן המכולה כמעט אינה צורכת משאבים בין בקשות. Vikunja הוא קובץ בינארי יחיד של Go עם 110 MB, ו-SQLite הוא מסד הנתונים המוגדר כברירת מחדל, כך שמכולה אחת מהווה את כל ה-stack. 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", כיוון שמנגנון ה-out-of-memory killer של ה-kernel אינו מדווח דבר ליישום.

התלות במסד נתונים קובעת מחצית מעבודת הגיבוי שלכם, להלן הפירוט בשורה אחת לכל כלי: 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 אמיתי, עם קובץ 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 של הגרסה העצמאית מציין שהמאגר אינו מתוחזק כרגע. זהו ה-"לא" החד-משמעי היחיד בהשוואה זו. כל השאר הם עניין של פשרות.

הנתון של Planka, העומד על 109 ימים, הוא תקין עבור פרויקט שמשחרר כמה גרסאות בשנה. גרסה 2.1.1 היא מאפריל 2026. Kanboard שחררה את v1.2.53 12 ימים לפני הבדיקה, ושתי הגרסאות שלפניה יצאו במרץ ובאפריל 2026.

Vikunja ו-Wekan שתיהן שחררו גרסאות בטווח של יום מהבדיקה, אך יש לפרש את שני הנתונים הללו בצורה שונה. Vikunja תייגה את v2.5.0 כגרסה משנית רגילה. Wekan תייגה את v10.65, v10.66 ו-v10.67 באותו היום, וזהו קצב העבודה הרגיל שלה. שחרור גרסאות תכוף אינו מעיד בהכרח על יעד יציב. עם Wekan אתם בוחרים לעקוב אחר מספר גרסה שמשתנה במהירות, לכן קבעו (pin) את התג וקראו את ההערות לפני כל שדרוג.

האם מקבלים יותר מלוח?

רוב הפוסטים המשווים עוצרים בטענה ש"זה נראה כמו Trello". ציר זה קובע יותר מאשר כמות ה-RAM, כיוון שלוח הוא מבנה לא מתאים לכל דבר שיש לו דדליין.

• Planka הוא כלי לוחות ותו לא: פרויקטים, לוחות, רשימות, כרטיסים, תוויות, צ'ק-ליסטים, הערות וקבצים מצורפים. תצוגות לוח שנה ומפה הן תכונות בתשלום (Pro) נכון לאוגוסט 2026.
• Vikunja מציע ארבע תצוגות על אותה קבוצת משימות: רשימה, Kanban, טבלה ו-Gantt. משימה קיימת פעם אחת, ואתם מחליפים תצוגה במקום לשכפל אותה.
• Kanboard מבוסס על לוחות עם הגבלות עבודה בתהליך (WIP), תתי-משימות, קבצים מצורפים, הערות, פעולות אוטומטיות ושפת שאילתות קטנה לסינון. דף הבית שלו מציין כי "מספר התכונות מוגבל מרצון", וזהו תיאור הוגן.
• Wekan מבוסס על לוחות עם נתיבי שחייה (swimlanes), בתוספת צ'ק-ליסטים, שדות מותאמים אישית, ממשק REST API ו-webhooks.
• Focalboard הציע תצוגות לוח, טבלה ולוח שנה על גבי אותם כרטיסים. הוא מופיע כאן למען השלמות.

אם מה שאתם מחפשים בפועל הוא Wiki עם יכולות מעקב אחר משימות, זו אינה ההשוואה המתאימה. BookStack, Wiki.js ו-Outline מכסים את המבנה הזה, ו-חלופות Notion לאירוח עצמי מכסות את סביבת העבודה הכל-באחד.

גישה מרובת משתמשים ו-Single Sign-On

Planka תומכת ב-OpenID Connect במהדורת ה-Community החינמית. קובץ ה-Compose הרשמי כולל את ההגדרות כשהן חסומות בהערות, ביניהן OIDC_ISSUER, OIDC_CLIENT_ID ו-OIDC_CLIENT_SECRET, כך שעליך רק להסיר את ההערה במקום לשדרג. תפקידי אורח (Guest roles) עבור אנשים מחוץ לארגון שלך הם תכונה של גרסת ה-Pro.

Vikunja תומכת ב-OpenID Connect עם כמה ספקי זהות בו-זמנית. הגדר את VIKUNJA_AUTH_OPENID_ENABLED=true, ולאחר מכן הוסף בלוק אחד של משתני VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_* עבור כל ספק. היא כוללת גם צוותים ושיתוף ברמת הפרויקט, שזה מה שארגון של עשרים איש באמת צריך.

Wekan תומכת ב-LDAP (פרוטוקול גישה לספריות קלות משקל), OAuth2, OIDC ו-SAML. ל-Kanboard יש תמיכה מובנית ב-LDAP ותוסף OAuth2 גנרי לכל השאר, בנוסף לתפקידים וקבוצות ברמת הפרויקט. לשרת העצמאי של Focalboard אין תמיכה ב-Single Sign-On כלל, וזו סיבה שנייה לוותר עליו.

כל אחת מאלו יכולה לעבוד יחד עם ספק זהות מסוג Authentik שאתה מריץ בעצמך, שזו בדרך כלל תשובה טובה יותר מאשר לתת לעשרים איש סיסמה נפרדת לכל יישום.

האם ניתן לייבא לוחות מ-Trello?

ל-Planka יש את המסלול הפשוט ביותר. ייצאו את הלוח מ-Trello כקובץ JSON, צרו לוח חדש ב-Planka, לחצו על Import ובחרו ב-Trello. קראו תחילה את המגבלות, שכן הן משמעותיות: משתמשים וקבצים מצורפים אינם מיובאים, רק רשימת תיוג (checklist) אחת לכל כרטיס עוברת, וייצוא ה-JSON המובנה של Trello נעצר לאחר 1,000 פעולות ללא התראה על כך שהמידע קוצץ. בדקו את הקובץ בעצמכם לפני שתסתמכו על התוצאה.

Vikunja מבצעת ייבוא דרך תהליך ה-OAuth של Trello, תחת Settings ולאחר מכן "Import from other services". יש להפעיל כל כלי הגירה בקובץ ה-config לפני שהאייקון שלו יופיע, ו-VIKUNJA_SERVICE_PUBLICURL חייב להיות תקין, כיוון שהפניית ה-OAuth מתבצעת בדפדפן שלכם ולא מהשרת. Vikunja תומכת גם בייבוא מ-Todoist, Microsoft To Do, TickTick ו-Wekan.

Wekan מקבלת קובץ JSON של לוח Trello שהודבק בטופס הייבוא שלה. ל-Kanboard אין כלי ייבוא מובנה ל-Trello, וזו הסיבה העיקרית לוותר עליה אם יש לכם היסטוריה של שנים ב-Trello שברצונכם להעביר.

איך נראית חוויית השימוש בנייד?

Vikunja היא היחידה מבין החמש שמציעה אפליקציות מובייל רשמיות. גרסאות ל-Android ול-iOS משוחררות לצד כל release, ומאגר האפליקציה מגדיר את עצמה כ-alpha, לכן יש להתייחס אליה כאל כלי משלים לממשק ה-web ולא כאל דרך הגישה העיקרית. ל-Planka אין אפליקציה רשמית מטעם הפרויקט, אם כי ממשק ה-web שלה רספונסיבי וקיימים לקוחות צד-שלישי. Wekan ו-Kanboard מבוססות web בלבד, והממשק של Kanboard בנוי בבירור עבור מסכי מחשב שולחני.

שאלת הרישוי, ומדוע Planka שונה

Planka אינה עוד תוכנה בקוד פתוח, וזו עובדה שרוב ההשוואות משמיטות. היא החלה תחת רישיון MIT, עברה ל-AGPL-3.0 בשנת 2023, ומגרסה 2.0 היא מופצת תחת PLANKA Community License, רישיון "קוד הוגן" (fair-code) המוחזק על ידי PLANKA Software GmbH. GitHub מדווחת על הרישיון שלה כ-"Other" מכיוון שרישיון זה אינו מאושר על ידי ה-OSI. אירוח עצמי (self-hosting) עבור המשתמשים שלכם הוא חינמי ומותר במפורש, והוא מכסה שימוש אישי, פנימי, ללא מטרות רווח וחינוכי. מכירה חוזרת של גישה אליה, או הפעלתה כשירות עבור חברות אחרות, דורשת רישיון מסחרי.

עבור שני אנשים מדובר בעסקה הוגנת. עבור חברה מדובר בתנאי שיש לקרוא לפני שמשקיעים בו את עבודתם של עשרים איש. ארבע האפשרויות האחרות הן קוד פתוח רגיל: Vikunja היא תחת AGPL-3.0, Wekan ו-Kanboard הן תחת MIT, ו-Focalboard היא שילוב של Apache 2.0 ו-AGPL-3.0.

קיבוע קובצי Compose עבור שתי הבחירות

קבעו את גרסת ה-image. שימוש ב-latest משמעו ש-docker compose pull הבא עלול להעביר אתכם בין גרסאות ראשיות, וגרסאות ראשיות מריצות מיגרציות של מסד הנתונים שלא ניתן לבטל בקלות. שני הקבצים להלן הם קובצי המקור עם תגית גרסה המקובעת ל-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

צרו תחילה את ספריית הנתונים עם הבעלים הנכון, כיוון שהמכולה רצה תחת 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, ונקודת הקצה של המידע מחזירה JSON המכיל שדה version. השגיאה Connection refused כאן משמעה שהמכולה קרסה. 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 מקבל כל חיבור ללא סיסמה. זה בטוח רק כיוון שפורט מסד הנתונים אינו מפורסם למארח (host), כך שהדבר היחיד שיכול להגיע אליו הוא המכולה השנייה באותה רשת Compose. אל תוסיפו ערך ports: לשירות ה-postgres.

אף אחד מה-stacks לא אמור לפנות ישירות לאינטרנט. שניהם מאזינים ל-127.0.0.1, לכן הציבו reverse proxy בחזית ובצעו שם TLS termination. 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, בצעו dump ל-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. העברת שם שאינו קיים תיצור נפח ריק ותספק לכם ארכיון תקין אך ריק ללא הודעת שגיאה, לכן בדקו את גודל הקובץ לאחר מכן.

לאחר מכן, שחזרו אותו פעם אחת לתוך סביבת בדיקה (scratch stack) על אותו שרת, ופתחו כרטיס שאתם זוכרים. גיבוי שמעולם לא שוחזר הוא בגדר ניחוש בלבד. שלחו את הארכיונים אל מחוץ לשרת, כיוון שעותק שנשמר על ה-VPS שאתם מגינים עליו אינו נחשב לגיבוי. המדריך גיבויי restic משרת VPS מכסה את החלק הזה.

שתי המלצות

עבור שני משתמשים על שרת VPS עם 2 GB RAM: הריצו את Planka. זהו הכלי הקרוב ביותר ל-Trello במראה ובהתנהגות, ייבוא הנתונים מ-Trello מתבצע באמצעות גרירת קובץ, וצריכת זיכרון של 280 MB במצב המתנה משאירה את רוב ה-2 GB פנויים עבור ה-reverse proxy וכל שירות אחר שתארחו. ה-Community License מכסה צוות פנימי של שני אנשים ללא עלות. אם אתם מעדיפים לא להסתמך על רישיון source-available, הבחירה בקוד פתוח לאותו שרת היא Vikunja על גבי SQLite, עם צריכת זיכרון של 110 MB.

עבור עשרים משתמשים בארגון: הריצו את Vikunja על גבי PostgreSQL. בסדר גודל כזה אתם זקוקים ל-OpenID Connect במקום לניהול עשרים סיסמאות מקומיות, אתם זקוקים לצוותים ושיתוף לפי פרויקטים, וחלק גדול מהעבודה לא יתאים לתצוגת לוח (board), כך שתצוגות List, Table ו-Gantt הופכות להכרחיות ולא רק לתוספת נחמדה. רישיון AGPL-3.0 מבטיח שאין צורך בדיונים משפטיים על רישוי ככל שמספר העובדים גדל. ספקו ל-Vikunja בסיס נתונים PostgreSQL במקום SQLite, הציבו אותה מאחורי reverse proxy, ושמרו גיבוי יומי במיקום חיצוני לשרת.

אם לשרת יש פחות מ-1 GB RAM, אף אחת מהתשובות הללו אינה רלוונטית. בחרו ב-Kanboard עם צריכת זיכרון של 70 MB, קבלו את העובדה שתצטרכו להקליד מחדש את כרטיסי ה-Trello שלכם, והשתמשו בזיכרון שחסכתם עבור משהו אחר מתוך רשימת האירוח העצמי המומלצת לשנת 2026. ההתקנה המפורטת עבור כל כלי שתבחרו מופיעה במדריך הייעודי שלו. דף זה נועד רק לצורך קבלת ההחלטה.

FAQ

איזו חלופה ל-Trello באירוח עצמי צורכת הכי פחות RAM?

Kanboard, עם כ-70 MB במצב המתנה, כיוון שהוא מבוסס PHP עם SQLite ואינו מחזיק דבר בזיכרון בין בקשות. Vikunja נמצאת במקום הבא עם כ-110 MB כקובץ binary יחיד של Go. Wekan היא הכבדה ביותר עם כ-750 MB, כיוון ש-Meteor מחזיקה שכבת שאילתות חיה בזיכרון ה-Node עבור כל דפדפן מחובר. מדדו את הצריכה שלכם באמצעות docker stats לאחר שה-stack במצב המתנה, שכן אלו נתונים טיפוסיים ולא התחייבות.

האם ניתן לייבא לוחות Trello לכלי באירוח עצמי?

Planka ו-Wekan תומכות בייבוא ישיר של קובצי JSON לייצוא לוחות מ-Trello. Vikunja מייבאת דרך תהליך ה-OAuth של Trello, ויש להפעיל את כלי ההגירה ב-config לפני שהוא יופיע בממשק. ל-Kanboard אין כלי ייבוא מובנה. שתי מגבלות שיש לקחת בחשבון: Planka אינה מייבאת משתמשים או קבצים מצורפים ומטפלת רק ברשימת תיוג אחת לכל כרטיס, וייצוא ה-JSON המוגדר כברירת מחדל ב-Trello נעצר ב-1,000 פעולות מבלי להזהיר שהמידע קוצץ.

האם Focalboard היא עדיין בחירה טובה בשנת 2026?

לא. הגרסה העצמאית האחרונה, v8.0.0, היא מיוני 2024, שהייתה 783 ימים לפני בדיקת השוואה זו ב-5 באוגוסט 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 על כונן רשת (network share): התיעוד של Kanboard מזהיר מפני שימוש ב-SQLite על NFS בדיוק מהסיבה הזו.