התקנת Dify על שרת VPS באמצעות Docker Compose

מהו Dify ומה אתם מתקינים

Dify היא פלטפורמה להרצה עצמית המיועדת לבניית יישומים על גבי מודלי שפה גדולים. המערכת מספקת ממשק אינטרנטי לעיצוב יישומי צ'אט, סוכנים וצינורות שליפת מידע (retrieval pipelines), ממשק API להפעלתם מתוך הקוד שלכם, ומרכז אחד לניהול הנחיות (prompts), מאגרי נתונים ומפתחות מודלים. זהו כלי שצוותים קטנים מקימים כדי שכולם יוכלו לבנות על בסיס פרטי ומשותף, במקום לפזר מפתחות API בין סקריפטים שונים.

הפעלת המערכת בעצמך פירושה להפעיל כמה רכיבים נפרדים. Dify מופץ כמערכת של מכולות Docker: שרת API, worker ברקע, ממשק web, מסד נתונים Postgres, מטמון Redis ומסד נתונים וקטורי, שכולם מחוברים זה לזה באמצעות Docker Compose. זו מערכת מורכבת יותר מקובץ בינארי יחיד, אך Compose מטפל בחיבור בין הרכיבים, ו־VPS עם כמה ג׳יגה־בייטים פנויים של RAM יפעיל אותה ללא קושי. אם אותו VPS מיועד להפעיל גם שירותים אחרים, יש להקצות לו משאבים על סמך מדידות בפועל ולא על סמך נתונים שיווקיים, משום ש־דרישות ה־RAM המעשיות של PhotoPrism ושל Immich גבוהות במידה ניכרת מדרישות המינימום המפורסמות שלהם, ושרת תמונות החולק את אותו שרת יגרום תחילה למחסור במשאבים עבור מסד הנתונים ומאגר הנתונים הווקטורי של Dify. גם עומס על המעבד גורם לבעיה דומה: ספריית Jellyfin שעוצבה מחדש כחנויות וידאו משנות ה־90 כמעט שאינה צורכת משאבים בזמן שעוברים רק על עטיפות ותמונות, אך ברגע שמתחיל transcoding, תורי המשימות של ה־worker של Dify ממתינים מאחוריו. היתרון הוא שמספר המכולות של Dify נשאר קבוע, ללא קשר למספר היישומים שתבנו עליו. מבנה העלויות הזה מתון יותר מזה של OpenBot, שבו לכל עמית AI יש מכולה ודפדפן משלו, וכל עובד חדש מעלה שוב את דרישת הזיכרון הבסיסית.

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

דרישות קדם

עליך להחזיק בשרת VPS המריץ את Ubuntu 24.04 עם Docker ותוסף Docker Compose מותקנים, וכן משתמש בעל הרשאות sudo או חברות בקבוצת docker. אם Docker חדש לך, יסודות Docker Compose ב-VPS מכסה את ההתקנה ואת הפקודות הבסיסיות שעליהן מדריך זה מתבסס. כדאי להחזיק בשם מתחם המופנה לשרת, שכן תרצה להשתמש ב-TLS לפני Dify במקום בכתובת IP חשופה.

שלב 1: השגת Dify וקובצי ה-Compose שלו

Dify שומרת את הגדרות ה-Docker שלה במאגר הראשי. בצעו clone למאגר ועברו לתיקיית ה-docker:

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

הקובץ .env מכיל את כל התצורה. קראו אותו לפני שתתחילו בכל פעולה. הערכים החשובים ביותר בתחילה הם אלו המגדירים סיסמאות וסודות: SECRET_KEY, סיסמת ה-Postgres וסיסמת ה-Redis. קובץ הדוגמה מגיע עם ערכי ברירת מחדל, והשארתם כפי שהם היא הדרך הנפוצה ביותר שבה התקנת Dify בניהול עצמי נפרצת. צרו מפתח סודי אמיתי:

openssl rand -base64 42

הדביקו אותו בתוך SECRET_KEY, והגדירו ערך חזק וייחודי עבור כל שדה סיסמה בקובץ.

שלב 2: הפעלת המערכת

העלו את ה-stack:

docker compose up -d

docker-compose up -d

ההרצה הראשונה מושכת מספר images ומאתחלת את מסד הנתונים, לכן המתינו דקה. ודאו שה-containers תקינים:

docker compose ps

docker-compose ps

כל שירות אמור להציג running. Dify מגיש את ממשק האינטרנט שלו דרך container של nginx המצורף אליו, כברירת מחדל בפורט 80. בביקור הראשון שלכם ב-http://YOUR_SERVER/install עליכם ליצור את חשבון ה-admin. בצעו זאת מיד, לפני שגורם אחר יוכל לגשת לפורט, כיוון שעד ליצירת החשבון, כל מי שיטען את הדף יוכל להשתלט עליו ולהפוך לבעלי ה-instance שלכם.

שלב 3: אל תחשפו את השירות ללא הגנה. הציבו TLS ו-firewall בחזית

כאן רוב ההתקנות המהירות נעצרות, וכאן מתחילים רוב אירועי האבטחה. ה-nginx של Dify מאזין בפורט 80, בטקסט גלוי, על כל ממשקי הרשת. אינכם רוצים שפרטי ההתחברות למנהל המערכת ומפתחות המודלים שלכם יעברו ב-HTTP גלוי, ואינכם רוצים שהשירותים הפנימיים יהיו נגישים מבחוץ.

אבטחו את השרת באמצעות firewall במדיניות default-deny המאפשר רק תעבורת SSH ותעבורת אינטרנט:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

זכרו ש-firewall המכסה רק IPv4 עלול להשאיר את אותם פורטים פתוחים ב-IPv6, מה שיוצר את פרצת ה-IPv6 שתופסת מארחים עצמיים רבים. ודאו ששני ה-stacks מסוננים.

ל־TLS, הדרך הנקייה ביותר היא לקשור את פורט ה־web של Dify ל־loopback ולהפעיל לפניו reverse proxy עם תעודת Let’s Encrypt, כך שהדבר היחיד החשוף לאינטרנט הציבורי יהיה ה־proxy שמדבר ב־HTTPS. באמצעות .env של Dify אפשר לשנות את הפורט החשוף; הגדירו אותו כך שייקשר אל 127.0.0.1, והפנו את ה־proxy אליו. עקרונות הקשחת ה־agent שמתוארים ב־הפעלה בטוחה של agent מבוסס AI ב־VPS חלים גם כאן: השאירו את רכיבי המערכת על loopback, חשפו רק את מה שחייב להיות ציבורי, ותנו לכניסה מרכזית ומוקשחת אחת לטפל ב־TLS. כאשר הממשק של כלי מסוים מיועד רק לכם ואינו זקוק כלל לתעודה, דלגו על ה־proxy והתחברו אליו באמצעות SSH tunnel, כפי ש־אירוח עצמי של סורק האבטחה open-kritt משאיר את לוח הבקרה שלו קשור ל־loopback ומעביר אותו למחשב הנייד שלכם, במקום לפרסם אותו. אם צוות שלם זקוק ל־Dify אך אין צורך לאפשר גישה מהאינטרנט הציבורי, רשת overlay מרחיבה את הרעיון מעבר למחשב נייד אחד: פרסום רשת המשנה הפרטית של השרת ל־tailnet שלכם מאפשר לכל מכשיר מאושר להגיע ל־builder בכתובת פרטית, בעוד שה־firewall נשאר סגור לכל דבר מלבד SSH. אם אתם מנהלים את השרת באמצעות coding agent ולא באופן ידני, קבעו מראש כמה פעולות מותר לו לבצע ללא השגחה לפני שתמסרו לו את ההרשאות, משום ש־מצב ההרשאות שבו אתם משאירים את Claude Code קובע אם הוא יעצור כדי לבקש אישור לפני שינוי .env או הפעלה מחדש של ה־stack. אם בסופו של דבר סשן אחד יציג בזמן אמת את לוגי המכולות וסשן אחר יערוך את תצורת ה־proxy, שני הסשנים האלה יכולים להעביר טקסט זה לזה באותו שרת, וזה יעיל יותר מהעתקת פלט בין מסופים בכל פעם שאתם מפעילים מחדש את ה־stack.

שלב 4: שמירה על גרסה מעודכנת

Dify מתפתח במהירות, ועדכונים כוללים תיקוני אבטחה. עדכון מתבצע באמצעות משיכת הגרסה החדשה והפעלה מחדש מתוך הספרייה docker:

git pull
docker compose pull
docker compose up -d

קראו את הערות השחרור לפני שדרוג גרסה משמעותי, כיוון ש-Dify משנה לעיתים את ה-schema של .env בין גרסאות, ומשתנה חדש שלא הוגדר עלול למנוע מהמכולה לעלות.

שלב 5: גיבוי של מה שלא ניתן לשחזור

ישנם שני רכיבים בשרת Dify שלא ניתן לשחזר: מסד הנתונים Postgres, המכיל את היישומים, המשתמשים וההגדרות שלך, והנפח (volume) שבו מאוחסנים מסמכים שהועלו ואינדקס הווקטורים. שניהם נמצאים תחת נפחי Docker בספרייה docker. בצעו להם snapshot לפי לוח זמנים, והעתיקו את הגיבויים מחוץ לשרת. ניתן להנפיק מחדש מפתח API של מודל; את היישום שבנית במשך שבוע לא ניתן לשחזר. אותו היגיון חל על כל סוכן (agent) שמצבו חייב לשרוד מעבר למכונה שבה הוא רץ: שמירה על KiroCrew כקונטיינר שרץ תמיד מסתכמת בביצוע snapshot לזיכרון וללוחות הזמנים שאחרת היו נעלמים באתחול הבא.

כאשר ברצונך שהסוכנים שתבנה כאן יחרגו מעבר למערכי הנתונים שלך ויחפשו ברשת החיה, הפנייתם למופע SearXNG מאוחסן עצמית שומרת את זרם השאילתות על חומרה שבשליטתך, אם כי כדאי לקרוא על שטח הפנים של הזרקת פקודות (prompt injection) שנפתח לפני שתפעיל זאת. עבור סוכן אוטונומי יותר שמריץ קוד, עיין ב-אירוח עצמי של Agent Zero, והמדריך בניית סוכן AI משלך על גבי VPS מכסה את היסודות שמתחת לכל אלו.

FAQ

מהן דרישות המערכת לאירוח עצמי של Dify?

Dify רץ כחבילת Docker Compose הכוללת כחצי תריסר מכולות, לכן יש לתכנן שרת VPS עם לפחות 2 GB של זיכרון RAM פנוי, רצוי 4 GB, בצירוף זוג ליבות CPU ושטח דיסק מספיק עבור המסמכים שיועלו ואינדקס הווקטורים. העומס על הזיכרון נובע ממסד הנתונים ומאחסון הווקטורים, ולא מ־Dify עצמו.

האם בטוח לחשוף את Dify ישירות בפורט 80?

לא. שרת ה-web המצורף ל-Dify מאזין ב-HTTP גלוי, והוא עומד בחזית מול ממשק הניהול ומפתחות ה-API של המודלים שלכם. הציבו reverse proxy עם תעודת Let's Encrypt לפניו, קשרו את הפורט של Dify ל-loopback, ואפשרו רק ל-proxy ב-HTTPS לפנות לאינטרנט. שלבו זאת עם firewall במדיניות default-deny המכסה גם IPv4 וגם IPv6.

כיצד מעדכנים התקנה עצמית של Dify?

מתוך הספרייה docker, הריצו את git pull, ולאחר מכן את docker compose pull ו-docker compose up -d כדי למשוך תמונות חדשות ולהפעיל מחדש. קראו תחילה את הערות השחרור (release notes), כיוון ש-Dify מוסיפה לעיתים משתני .env חדשים בין גרסאות, ומשתנה חסר עלול למנוע ממכולה לעלות.

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

גשו ל-/install וצרו את חשבון ה-admin באופן מיידי. עד שחשבון זה קיים, כל מי שיכול להגיע לדף יכול להשתלט עליו. הגדירו אותו ברגע שהמכולות תקינות, ולפני שאתם פותחים את ה-firewall לעולם.