השוואת מערכות Wiki בניהול עצמי: BookStack, Wiki.js

איזו מערכת wiki בניהול עצמי כדאי להריץ

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

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

כל המידע להלן מבוסס על התיעוד הרשמי של הפרויקטים ועל קובצי התצורה שפורסמו על ידם. זוהי השוואת יכולות, לא מדד ביצועים (benchmark). מספרי הגרסאות והדרישות מצוינים עם תאריך, שכן שלוש המערכות מתעדכנות בתדירות גבוהה.

המבנה הוא הבחירה האמיתית

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

Wiki.js משתמש בעץ נתיבים, בדומה לתיקיות על דיסק. דף ב-ops/backup/restic נמצא בכל מקום שבו תניחו אותו, ואתם בוחרים את העומק. שום דבר לא מונע משני אנשים לתייק את אותו נושא תחת שני ענפים שונים, לכן מופע של Wiki.js זקוק לאדם אחד שאחראי על העץ.

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

BookStack: ההתקנה המינימלית

BookStack הוא יישום PHP המבוסס על MySQL. נכון ליולי 2026, הדרישות המתועדות הן PHP 8.2 ומעלה, וכן MySQL 8.0 או MariaDB 10.6 ומעלה, בתוספת Composer 2.2 ומעלה אם ההתקנה מתבצעת מקוד המקור. סדרת הגרסאות הנוכחית היא 26.05.

הפרויקט מפרסם סקריפט התקנה אחד לכל גרסת Ubuntu. הסקריפט עבור 24.04 מתקין עבורכם את Apache, MySQL 8.0 ו־PHP 8.3.

wget https://codeberg.org/bookstack/devops/raw/branch/main/scripts/installation-ubuntu-24.04.sh
chmod a+x installation-ubuntu-24.04.sh
sudo ./installation-ubuntu-24.04.sh

קראו את האזהרה המופיעה על הסקריפט לפני הרצתו. התיעוד מציין כי הוא "מיועד למערכת הפעלה נקייה בלבד, הוא יתקין Apache, MySQL 8.0 ו־PHP 8.3 ועלול לדרוס כל הגדרת שרת אינטרנט קיימת על המכונה". בשרת שכבר מגיב בפורט 80, הסקריפט יתפוס את הפורט וישכתב את תצורת Apache. השתמשו במקום זאת במכולות, או התקינו את BookStack ידנית על גבי מחסנית LAMP קיימת ב-Ubuntu 24.04.

נתיב המכולות משתמש ב-image של LinuxServer.io, שהיא האפשרות אליה מפנה התיעוד של BookStack. BookStack זקוק למפתח הצפנת session ולא יציג דפים בלעדיו, לכן צרו אותו תחילה.

docker run -it --rm --entrypoint /bin/bash lscr.io/linuxserver/bookstack:latest appkey

העתיקו את הערך המודפס לתוך APP_KEY, ולאחר מכן כתבו את השירות:

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack:latest
    container_name: bookstack
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - APP_URL=https://wiki.example.com
      - APP_KEY=paste_the_generated_key_here
      - DB_HOST=bookstack_db
      - DB_PORT=3306
      - DB_USERNAME=bookstack
      - DB_PASSWORD=change_me
      - DB_DATABASE=bookstackapp
    volumes:
      - ./config:/config
    ports:
      - 6875:80
    restart: unless-stopped

APP_URL חייב להתאים לכתובת שהקוראים מקלידים בפועל, כולל ה-scheme וכל פורט. הגדירו אותו ל-http://localhost, אחרת האתר יוגש מעל HTTPS, אך קישורים והפניות שנוצרו יצביעו על host שגוי, מה שהקוראים יראו כדף התחברות שחוזר על עצמו בלולאה. אם קובצי compose חדשים לכם, התחילו עם יסודות Docker Compose ב-VPS לפני שתמשיכו.

העלו את השירות ובדקו שהיישום מגיב, לא רק שהמכולה רצה:

docker compose up -d
docker compose ps
curl -sI http://127.0.0.1:6875/login

200 OK משמעותו שיישום ה-PHP עלה והגיע למסד הנתונים. 500 כמעט תמיד אומר ש-APP_KEY ריק או שפרטי הגישה למסד הנתונים אינם תואמים, ו-docker compose logs bookstack מדפיס איזו משתי האפשרויות היא הנכונה.

Wiki.js: עץ אחד, עורכים מרובים

Wiki.js הוא יישום Node.js. הגדרת ה-Docker המתועדת מצמדת אותו ל-PostgreSQL, אם כי התוכנה מקבלת גם את MySQL, MariaDB, MSSQL ו-SQLite. זהו קובץ ה-compose מתוך דף ה-Docker של הפרויקט עצמו:

services:
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: wiki
      POSTGRES_PASSWORD: wikijsrocks
      POSTGRES_USER: wikijs
    logging:
      driver: none
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
  wiki:
    image: ghcr.io/requarks/wiki:2
    depends_on:
      - db
    init: true
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: wikijsrocks
      DB_NAME: wiki
    restart: unless-stopped
    ports:
      - "80:3000"
volumes:
  db-data:

שנו את POSTGRES_PASSWORD ואת DB_PASS יחד לפני ההרצה, כיוון שהם מהווים הרשאה אחת וערך הדוגמה גלוי לכולם. התגית מקובעת ל-ghcr.io/requarks/wiki:2 בכוונה תחילה. התיעוד ממליץ להימנע מ-latest, שכן קפיצת גרסה ראשית משנה את מבנה מסד הנתונים תחת מופע פעיל.

גרסה 2 היא השורה להרצה. נכון ליולי 2026, גרסת ה-2 החדשה ביותר היא 2.5.314, ממאי 2026. גרסה 3 קיימת, והתיעוד שלה מציין: "אתר זה מיועד לגרסת הבטא הלא יציבה של Wiki.js 3.0. אין להתקין זאת בסביבת ייצור". התייחסו לתגית :3 כאל תצוגה מקדימה.

בטעינה הראשונה, Wiki.js מנחה אתכם בתהליך הגדרה בדפדפן שיוצר את חשבון מנהל המערכת. עד לסיום התהליך, כל מי שיגיע לפורט יקבל את אשף ההגדרה, לכן הציבו את השירות מאחורי ה-reverse proxy וה-TLS (אבטחת שכבת תעבורה) שלכם לפני פתיחת ה-firewall. ויקי בשם מתחם עצמאי יושב באופן טבעי מאחורי Traefik לפני מספר יישומי Docker כאשר השרת מארח יותר משירות זה בלבד.

בחירת העורך היא הסיבה שאנשים בוחרים ב-Wiki.js. מופע אחד יכול להכיל דפי Markdown, דפי עורך ויזואלי, דפי HTML גולמי ודפי AsciiDoc זה לצד זה. זה מסייע כאשר מייבאים תוכן ישן בפורמט שמעדיפים לא להמיר. זו גם דרך להגיע לארבעה סגנונות עיצוב שונים בוויקי אחד, לכן החליטו על עורך ברירת המחדל ביום הראשון ותעדו את ההחלטה הזו.

סקירה כללית: העורך הטוב ביותר, דרישות המערכת הכבדות

Outline הוא מה שאנשים בדרך כלל מתכוונים אליו כשהם מחפשים כלי לניהול הערות שמרגיש כמו מוצר מסחרי. זהו יישום Node.js, והגרסה העדכנית נכון ליולי 2026 היא 1.9.2. קובץ ה-environment לדוגמה שלו מפרט את הדרישות: PostgreSQL דרך DATABASE_URL, Redis דרך REDIS_URL, שני מפתחות סודיים אקראיים, וכתובת URL נגישה לציבור.

openssl rand -hex 32
openssl rand -hex 32

הריצו את הפקודה פעמיים ושמרו את שני הערכים. הראשון יהיה SECRET_KEY, והשני UTILS_SECRET. ליבת קובץ ה-environment נראית כך:

NODE_ENV=production
URL=https://docs.example.com
PORT=3000
SECRET_KEY=<first openssl value>
UTILS_SECRET=<second openssl value>
DATABASE_URL=postgres://outline:change_me@postgres:5432/outline
PGSSLMODE=disable
REDIS_URL=redis://redis:6379
FILE_STORAGE=local
FILE_STORAGE_LOCAL_ROOT_DIR=/var/lib/outline/data

הערך PGSSLMODE=disable נכון רק כאשר מסד הנתונים נמצא על אותו שרת או באותה רשת Docker. השמיטו אותו עבור מסד נתונים אליו ניגשים דרך הרשת, אחרת החיבור יעבור בטקסט גלוי. קבצים מצורפים כבר לא מחייבים שימוש ב-object storage: הערך FILE_STORAGE=local כותב קבצים שהועלו לספרייה שמעל, שחייבת להיות volume שהמכולה יכולה לכתוב אליו ושכלול בגיבויים שלכם. הגדירו את FILE_STORAGE=s3 עם הערכים של AWS_* במקום זאת, אם אתם מעדיפים שהקבצים יישמרו ב-bucket תואם S3.

כעת, החלק שמפתיע אנשים. ל-Outline אין מנגנון מובנה של שם משתמש וסיסמה. קובץ התצורה לדוגמה שלו מציין כי נדרשים פרטי התחברות של צד שלישי: "נדרש לפחות אחד מאלו עבור התקנה תקינה, אחרת לא יהיו אפשרויות התחברות". הספקים המתועדים כוללים את Google, Slack, Microsoft Entra, Discord, וכל שרת OpenID Connect (OIDC) גנרי דרך OIDC_CLIENT_ID, OIDC_CLIENT_SECRET, OIDC_AUTH_URI, OIDC_TOKEN_URI ו-OIDC_USERINFO_URI.

לכן, העלות האמיתית של Outline היא Outline בתוספת PostgreSQL, Redis וספק זהות (identity provider). אם הצוות שלכם כבר משתמש ב-Google Workspace או ב-Microsoft Entra, החלק האחרון יגזול מכם עשר דקות עבודה ו-Outline יהפוך לאטרקטיבי מאוד. אם לא, תצטרכו לארח בעצמכם גם שירות כמו Keycloak או Authentik, מה שמהווה שירות נוסף לתחזוקה ולגיבוי. תכננו את צריכת הזיכרון בהתאם: ההנחיות של Outline מדברות על כ-512 MB לכל תהליך web, שנקבע על ידי WEB_CONCURRENCY, בנוסף למשאבים של מסד הנתונים ושל Redis.

כיצד כל מערכת מנהלת הרשאות קריאה

ל-BookStack יש חשבונות דואר אלקטרוני וסיסמה מקומיים כברירת מחדל, והיא תומכת ב-LDAP, ב-SAML2 וב-OIDC כחלופות. ההרשאות נקבעות לפי תפקיד וניתנות לדריסה ברמת מדף, ספר, פרק או דף בודד. מכיוון שההיררכיה קבועה, ההרשאות עוברות בירושה במורד המבנה בצורה צפויה.

גם ל-Wiki.js יש חשבונות מקומיים, והיא מוסיפה רשימה ארוכה של אסטרטגיות שניתן להפעיל באזור הניהול. חוקי הדפים שלה מעניקים או חוסמים גישה לפי תבנית נתיב. זו יכולת עוצמתית שקל לטעות בה, כיוון שחוק שנכתב עבור ops/* יחול באופן אוטומטי על כל דף שתשייך לנתיב זה בעתיד.

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

כיצד פועל החיפוש בכל מערכת

החיפוש הוא המקום שבו ויקי מוכיחה את ערכה או הופכת לאוסף של קבצים נשכחים.

BookStack מבצעת חיפוש במסד הנתונים ומעניקה לקוראים שפת שאילתות שניתן ללמוד בדקה. ציטוט ביטוי, כמו ב-"london meeting", מחייב התאמה מדויקת של המחרוזת. סוגריים מרובעים משמשים לחיפוש תגיות: [location=london] מבצע התאמה לפי שם תגית, ערך או שניהם, עם אפשרויות השוואה הכוללות את !=, >= ו-like. סוגריים מסולסלים מסננים לפי מטא-דאטה, כמו ב-{created_after:2016-12-30}. ניתן לשלול כל מונח חיפוש מדויק, תגית או מסנן על ידי הוספת הקידומת -. BookStack מגבילה את מספר המונחים מכל סוג ששאילתה אחת יכולה להכיל, כך ששאילתה ארוכה מדי תיחתך במקום שתורץ.

Wiki.js מתייחסת לחיפוש כאל מודול הניתן להחלפה. המנועים המתועדים הם מנוע בסיסי מבוסס מסד נתונים, מנוע PostgreSQL, Elasticsearch, Algolia, AWS CloudSearch ו-Azure Search. המנוע הבסיסי מספק מענה טוב עבור כמה מאות דפים. אם אתם מריצים PostgreSQL, עברו למנוע ה-PostgreSQL באזור הניהול, כיוון שהוא משתמש באינדקס הטקסט המלא של מסד הנתונים עצמו במקום בהתאמה פשוטה. שמרו את Elasticsearch עבור ויקי גדול מספיק כדי להצדיק הרצה ותחזוקה של שירות חיפוש נוסף.

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

מה מתאים לך

בחרו ב-BookStack אם אתם רוצים שהוויקי ירוץ עוד היום ואתם מעדיפים להתווכח על התוכן מאשר על המבנה. יש לו את מספר הרכיבים הקטן ביותר: יישום PHP אחד ומסד נתונים MySQL אחד. הוא מתאים לתיעוד פנימי (runbooks) ולתיעוד לקוחות, והוא מתאים לצוותים שבהם רוב הכותבים אינם מהנדסים. הוא גם הקל ביותר לגיבוי מבין השלושה, כיוון שכל המצב שלו מורכב מ-dump אחד של מסד הנתונים בתוספת תיקיית ההעלאות.

בחרו ב-Wiki.js אם אתם זקוקים לעורך ספציפי או לאסטרטגיית אימות מסוימת שהאחרים אינם מציעים, או אם אתם מייבאים גוף גדול של קובצי Markdown או AsciiDoc קיימים ורוצים לשמר את מבנה הנתיבים. קחו בחשבון שאתם מריצים stack כבד יותר, וקבעו (pin) את תג הגרסה הראשית.

בחרו ב-Outline אם איכות הכתיבה היא בראש סדר העדיפויות, אם הוויקי מיועד לצוות ולא לציבור הרחב, ואם כבר יש לכם ספק זהות (identity provider). הוא מתגמל הגדרה כזו עם עורך שאנשים באמת נהנים להשתמש בו. אל תבחרו בו כיישום הראשון שלכם לאירוח עצמי.

אם אף אחד מהשלושה אינו מתאים, חוסר ההתאמה נובע בדרך כלל מסוג התוכן. חשבוניות וחוזים סרוקים שייכים ל-מערכת לניהול מסמכים כגון Paperless-ngx ולא לוויקי, ודחיפתם לתוך וויקי היא הסיבה לכך שוויקי רבים ננטשים בסופו של דבר. חוסר התאמה נפוץ אחר הוא הרצון בסביבת עבודה (workspace) במקום בוויקי, הכוללת מסמכים, טבלאות ולוח מחיק על קנבס אחד, ושם סביבת עבודה בניהול עצמי מסוג AFFiNE מתאימה יותר מכל אחד מהשלושה לעיל. למבט רחב יותר על מה עוד ראוי למקום בשרת שלכם, ראו את רשימת האירוח העצמי המומלצת לשנת 2026.

תכנון משאבים וגיבויים

כל השלושה מתאימים לשרת VPS קטן, אך רף המשאבים הריאלי משתנה בהתאם לרכיבים שמאחורי כל יישום. BookStack מורכב מתהליך יישום אחד ומ־MySQL. Wiki.js מורכב מתהליך Node ומ־PostgreSQL. Outline מורכב מתהליך Node, מסד נתונים PostgreSQL ו־Redis, ולרוב דורש גם ספק זהות (identity provider) לצידו, ולכן הוא היישום שדורש הקצאת זיכרון נוספת.

גבו את מסד הנתונים ואת תיקיית הקבצים שהועלו יחד, ובצעו שחזור של שניהם לתוך מופע זמני לפחות פעם אחת לפני שתסתמכו על הגיבוי. גיבוי של ויקי שאיש לא ביצע לו שחזור הוא בגדר ניחוש בלבד. עבור BookStack, המשמעות היא mysqldump בצירוף הנפח של /config. עבור Wiki.js ו־Outline, המשמעות היא pg_dump בצירוף נפח הנתונים, ועבור Outline יש לגבות גם את כל מה שנמצא בתוך FILE_STORAGE_LOCAL_ROOT_DIR.

FAQ

איזו מערכת ויקי בניהול עצמי היא הקלה ביותר להתקנה?

BookStack. מדובר ביישום PHP יחיד עם מסד נתונים MySQL, והפרויקט מפיץ סקריפט התקנה עבור Ubuntu 24.04 שמגדיר Apache, MySQL 8.0 ו-PHP 8.3 בהרצה אחת. תמונת ה-container דורשת רק APP_KEY ופרטי גישה למסד הנתונים. Wiki.js מוסיפה סביבת הרצה של Node ושרת PostgreSQL, ו-Outline מוסיפה על כך גם Redis וספק זהות חיצוני.

האם ניתן להשתמש ב-Outline ללא Google או ספק SSO אחר?

לא. ל-Outline אין אפשרות התחברות מקומית עם שם משתמש וסיסמה. קובץ התצורה לדוגמה שלה מציין כי נדרש לפחות ספק התחברות חיצוני אחד, אחרת לא יהיו אפשרויות התחברות כלל. ניתן להשתמש ב-Google, Slack, Microsoft Entra, Discord, או בכל שרת OpenID Connect גנרי כגון Keycloak או Authentik בניהול עצמי. הרצת ספק כזה היא חלק מהעלות של הרצת Outline.

האם כדאי להתקין את Wiki.js 3 או את Wiki.js 2?

גרסה 2. נכון ליולי 2026, גרסת ה-release החדשה ביותר של גרסה 2 היא 2.5.314, ממאי 2026, והתיעוד של גרסה 3 מציין במפורש שמדובר בגרסת בטא לא יציבה שאין להתקין בסביבת production. קבעו את גרסת ה-image שלכם ל-ghcr.io/requarks/wiki:2 במקום ל-latest, כיוון ששינוי גרסה מרכזית משנה את ה-schema של מסד הנתונים תחת מופע פעיל.

איזו מערכת מציעה את החיפוש הטוב ביותר?

לכל אחת מהן יתרונות שונים. BookStack מעניקה לקוראים שפת שאילתות עם ביטויים מדויקים, מסנני תגיות כגון [location=london] ומסנני מטא-דאטה כגון {created_after:2016-12-30}, וניתן לשלול כל אחד מהמונחים הללו באמצעות - בתחילת הביטוי. Outline אינה דורשת תצורה ומחפשת בתוך הטקסט של קבצים שהועלו. Wiki.js היא הניתנת לכיוונון הרב ביותר, כיוון שאתם בוחרים את מנוע החיפוש, ומנוע ה-PostgreSQL שווה מעבר ברגע שהוויקי שלכם גדל מעבר לכמה מאות דפים.

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

באופן חלקי, ועליכם לצפות לעבודה ידנית. כל השלוש מייצאות ומייבאות Markdown, כך שטקסט הדפים בדרך כלל נשמר. המבנה אינו נשמר בצורה נקייה: לספרים ופרקים ב-BookStack אין שווה ערך במסמכים המקוננים של Outline, והנתיבים של Wiki.js אינם ממופים להיררכיה הקבועה של BookStack. קבצים מצורפים, הרשאות והיסטוריית דפים הם החלקים בעלי הסבירות הגבוהה ביותר לאובדן, לכן ייצאו דוגמה ובדקו אותה לפני שתתחייבו להגירה.