תיעוד 101
סביבות באירוח עצמי
הריצו הפעלות ענן של Claude Code על תשתית בשליטתכם: הגדירו סביבה באירוח עצמי, פרסו מריצים (
runners), ונתבו הפעלות למחשוב שלכם.
הערה: סביבות באירוח עצמי נמצאות בבטא ציבורית בתוכניות Team ו-Enterprise, וכבויות כברירת מחדל. ראו זמינות ומגבלות עבור נתיב ההפעלה ומה שאינו נכלל.
סביבה באירוח עצמי מריצה הפעלות ענן של Claude Code על גבי תשתית שהארגון שלכם מפעיל. הפעלת ענן היא כל הפעלה שרצה במקום שאינו המחשב של המפתח: מפתחים מתחילים אותן מתוך claude.ai, מיישומי המובייל ושולחן העבודה, מהטרמינל באמצעות claude --cloud, ומתוך שגרות מתוזמנות, וכברירת מחדל הן רצות על התשתית של Anthropic. בסביבה באירוח עצמי, אותן הפעלות בדיוק רצות בתוך הרשת שלכם, וחוויית המפתח זהה לחלוטין למעט ההבדלים המפורטים בזמינות ומגבלות ובבעיות ידועות בדף הפריסה.
אם הצוות שלכם אינו משתמש בהפעלות ענן, אין כאן שום דבר להגדיר: הפעלות בטרמינל או בסביבת פיתוח (IDE) רצות תמיד על המחשב האישי של המפתח. אם ברצונכם להריץ את Claude Code על מכונה משלכם שפועלת תמיד ולהפעיל אותה ממכשירים אחרים, השתמשו ב-Remote Control, שזמין גם בתוכניות Pro ו-Max. כאשר אתם מוכנים להגדרה, עברו ישירות אל מדריך ההתחלה המהירה; כדי לבחון תחילה את מצב האבטחה, התחילו עם פריסה לסביבת ייצור. שאר הדף מסביר כיצד אירוח עצמי עובד ומתי כדאי לבחור בו.
#כיצד פועלות סביבות באירוח עצמי
אירוח עצמי מורכב משלושה חלקים:
- סביבה (
Environment): יעד בעל שם שאליו ניתן לשלוח הפעלות ענן. הארגון שלכם יוצר סביבות בהגדרות הניהול של claude.ai, וכל אחת מהן מאגדת קבוצה של מריצים (runners). - מריץ (
Runner): תוכנית הרצה על מארחים (hosts) בתוך הרשת שלכם. מריצים מבצעים את ההפעלות; הרעיון זהה למריץ CI באירוח עצמי. - הפעלה (
Session): משימת Claude Code אחת שמפתח התחיל.
כאשר מפתח מתחיל הפעלת ענן, ממשק המשתמש לתחילת הפעלה מציג בורר סביבות המפרט סביבות באירוח Anthropic לצד סביבות שהארגון שלכם יצר. אם המפתח בוחר בסביבה שלכם, מישור הבקרה (control plane) של Anthropic מציב את ההפעלה בתור של הסביבה שלכם, שבו מריץ תובע עליה בעלות, משכפל את מאגר הקוד שהמפתח בחר, ומתחיל תהליך Claude Code על המארח שלכם כדי להריץ אותה. המריץ מבצע אימות מול שרת ה-git שלכם באמצעות אישורים שאתם מגדירים; הגדרת git סוקרת את האפשרויות. הפעלות ניגשות לשירותים הפנימיים שלכם מתוך הרשת שלכם, ובאותו אופן גם לשרת ה-git שלכם כשהוא פנימי; התעבורה אל Anthropic, דגימת התור (queue polling), זרם האירועים של ההפעלה והסקת המודל (inference), היא תעבורת HTTPS יוצאת אל api.anthropic.com, יחד עם הרשימה הקצרה של מארחים נוספים שהפעלות יכולות לגשת אליהם המופיעה בדרישות רשת. חברת Anthropic לעולם אינה מתחברת לתוך הרשת שלכם.
שתי תיבות ה-Claude Code בתרשים הן תהליכי הפעלה: מריץ אחד המבצע שתי הפעלות בו זמנית, עד לקיבולת המוגדרת שלו. מריץ משרת בעלים אחד בכל עת וננעל לאותו בעלים כאשר הוא תובע את ההפעלה הראשונה שלו, כך שקוד שנמשך לעולם אינו מתערבב בין בעלים שונים; מחזור חיי המריץ מכסה כלל זה.
באפשרותכם להפעיל מריצים בעצמכם ולהשאיר אותם פועלים, או להריץ את מתאם התאמת קנה המידה האוטומטית (autoscaling orchestrator), תהליך שני שאתם מארחים, אשר מפעיל מריצים לפי דרישה כאשר הפעלות ממתינות בתור; כל מריץ מסיים את פעולתו ויוצא בעצמו כאשר עבודתו מסתיימת. כך או כך, אתם מגדירים את הסביבה פעם אחת, והיא מופיעה בבורר בכל משטח נתמך.
#זמינות ומגבלות
בדקו נקודות אלו לפני תכנון פריסה:
- תוכניות (Plans): בטא ציבורית עבור ארגונים בתוכניות Team ו-Enterprise. סביבות באירוח עצמי כבויות כברירת מחדל; בעלים (Owner) מפעיל את Allow self-hosted environments בדף הניהול Cloud environments, פעולה הדורשת ש-Claude Code on the web יהיה מופעל עבור הארגון.
- אי שמירת נתונים (Zero Data Retention): לא זמין עבור ארגונים שהפעילו את Zero Data Retention.
- הסקת מודל (Model inference): הפעלות משתמשות ב-API של Anthropic, ולא ניתן לנתב את ההסקה דרך Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry או דרך שער LLM (LLM gateway).
- משטחים (Surfaces): הפעלות שהותחלו מתוך Claude Code on the web, מיישומי המובייל ושולחן העבודה, מתוך שגרות מתוזמנות, ומהטרמינל באמצעות
claude --cloudאו שיגור באמצעות--environment, יכולות לרוץ בסביבות באירוח עצמי. הפעלות של Claude Tag יכולות לרוץ בהן גם כן, אך Claude אינו יכול להשתמש ב-Access bundles בהפעלות אלו עדיין. הפעלות של Claude Security ושל Code Review אינן מנותבות אליהן עדיין. תמיכה בשני משטחים אלו תתווסף בנפרד. - מאגרים (Repositories): הפעלות מושכות מאגרים מ-GitHub; ראו אפשרויות אימות מול GitHub.
- חיוב (Billing): הפעלות בסביבה באירוח עצמי צורכות משימוש ה-Claude Code של הארגון שלכם באותו אופן שבו צורכות הפעלות בסביבות באירוח Anthropic.
#מדוע לבחור באירוח עצמי
עבור רוב הצוותים, סביבות באירוח Anthropic מספקות מענה טוב יותר, מכיוון שאינן דורשות תשתית להפעלה או לתחזוקה. אירוח עצמי מיועד לצוותים שדרישות הרשת, כלי העבודה או התאימות לרגולציה שלהם מחייבות שמירה על ביצוע ההפעלות בתשתית בשליטתם. אם זה המצב אצלכם, תכננו את האחריות התפעולית הנגזרת מכך: אתם בונים ומתחזקים את תמונת המריץ (runner image), מפעילים את הצי (fleet), ושולטים ברשת שלו.
בתמורה, אירוח עצמי מעניק לכם גישת רשת, כלים מותאמים אישית ובקרת תאימות:
- גישת רשת: הפעלות רצות בתוך הרשת שלכם ויכולות לגשת לשירותים פנימיים, מסדי נתונים ורישומים (registries) מבלי לחשוף אותם לאינטרנט הציבורי.
- כלים מותאמים אישית: התקנה מראש של מהדרים (compilers), ערכות פיתוח (SDKs) וכלי CLI פנימיים בתמונת המריץ שלכם, כך שכל הפעלה מתחילה כשהיא מוכנה לבנייה.
- תאימות (Compliance): משיכות מאגרים ותוצרי בנייה (build artifacts) נשארים בתשתית שבשליטתכם. תוכן ההפעלה עדיין נשלח אל
api.anthropic.comלצורך הסקת מודל.
#סביבות, מריצים והפעלות
סביבות מנוהלות בדף Cloud environments בהגדרות הניהול של claude.ai; מריצים הם תהליכים שאתם מפעילים ומנהלים בתשתית שלכם.
#מושגי מפתח
מונחים אלו מופיעים לאורך כל הדפים העוסקים באירוח עצמי:
| מונח | מה זה |
|---|---|
Environment | קבוצה בעלת שם של המריצים שלכם, הנוצרת בהגדרות claude.ai. הפעלות מנותבות לסביבה, ולא למריץ בודד. |
Environment secret | פרט האימות המשותף היחיד שבו מריצים משתמשים כדי להזדהות ולהירשם מול הסביבה. מוצג פעם אחת בעת יצירת הסביבה, ומסומן כ-environment key בממשק הניהול. |
Runner | התהליך ארוך החיים שאתם פורסים. מריץ נרשם מול הסביבה, מקבל אסימון מריץ (runner token), ודוגם לקבלת הפעלות. |
Session | משימת Claude Code אחת, שהותחלה מתוך claude.ai, יישום המובייל, או משטח אחר של Anthropic כגון שגרה מתוזמנת או סוכן. כל הפעלה רצה כתהליך Claude Code בן (child process) שהמריץ מוליד. |
בשדות ה-API, בטענות האסימון (token claims) ובשמות המדדים (metric names), הסביבה מופיעה בשם pool, ומזהה הסביבה הוא pool_id. דף העיון וההפניות מציג את ההתאמה בין שני האיותים, כולל שמות הדגלים הישנים שהוצאו משימוש המכילים את המילה pool.
מריץ משרת בעלים אחד בכל עת. ההפעלה הראשונה שמריץ מקבל נועלת את המריץ לבעלים של אותה הפעלה, ולאחר מכן המריץ מריץ הפעלות רק עבור אותו בעלים, עד לקיבולת המוגדרת. זהות הבעלים תלויה באופן שבו ההפעלה התחילה:
- הפעלות שמשתמש מתחיל: הבעלים הוא חשבון המשתמש של אותו אדם.
- הפעלות ערוץ של Claude Tag: תוכנת Claude מריצה אותן ללא שיוך לחשבון משתמש, ולכן הבעלים הוא סוכן Claude Tag שהתחיל את ההפעלה. לכל הפעלת ערוץ שסוכן זה מתחיל יש את אותו הבעלים, ללא קשר למי ששלח את הודעת ה-Slack, ולכן מריץ שננעל אליו משרת הפעלות שאנשים שונים התחילו כאשר מריצים אותו עם ערך
--capacityמעל אחד או עם ערך חיובי של--drain-grace-sec. מריץ שננעל למשתמש לעולם אינו קולט הפעלות אלו, ומריץ שננעל לסוכן Claude Tag לעולם אינו קולט הפעלות של משתמש.
לפיכך, גודל הצי המינימלי הוא מספר הבעלים שאתם מצפים שיהיו פעילים בו זמנית, בספירה של משתמשים וסוכני Claude Tag.
#מחזור חיי הפעלה
כאשר מפתח מתחיל הפעלה ובוחר בסביבה שלכם, מישור הבקרה של Anthropic מציב את ההפעלה בתור של הסביבה. משם:
- מריץ בעל קיבולת פנויה תובע בעלות על ההפעלה ומחזיק בהסכם חכירה (lease) עליה.
- המריץ משכפל את המאגר לתוך ספריית העבודה שלו ומוליד תהליך Claude Code בן.
- תהליך הבן מזרים אירועים בחזרה על גבי HTTPS בזמן שהמריץ ממשיך לדגום; כל דגימה מרעננת את הסכם החכירה ומשמשת גם כדופק חיים (heartbeat).
- אם המריץ מפסיק לדגום למשך כ-60 שניות, השרת מחזיר את ההפעלה לתור עבור מריץ אחר.
המריץ מקציב לכל בקשת דגימה 10 שניות. כאשר תם הזמן הקצוב לבקשה, כשהיא אובדת, או כשהיא מקבלת תגובה שהמריץ אינו יכול לפענח, המריץ ממשיך לשרת את ההפעלות הפעילות שלו ומנסה שוב לאחר שנייה או שתיים במקום להמתין לדגימה המתוזמנת הבאה. לדוגמה, שרת פרוקסי מיירט שעונה לדגימה עם דף משלו מפיק תגובה שהמריץ אינו יכול לפענח. בכל פעם שבקשה נוספת נכשלת באחת הדרכים הללו, המריץ מכפיל את פער הזמן עד לניסיון הבא, עד ל-20 שניות, ומקצר את הפער בכל פעם שהסכם החכירה קרוב לפקיעה.
#מחזור חיי מריץ
ההפעלה הראשונה שמריץ קולט נועלת את המריץ לבעלים של אותה הפעלה, והמריץ מריץ עד --capacity הפעלות במקביל עבור אותו בעלים. כל עוד יש למריץ הפעלות פעילות והוא לא קיבל אות כיבוי או הגיע למועד הפרישה שלו, המריץ ממשיך לתבוע עבודה שממתינה בתור עבור הבעלים הנעול. מה שקורה לאחר סיומן תלוי בדגל --drain-grace-sec:
- בברירת המחדל של
0: המריץ יוצא ברגע שההפעלות הפעילות שלו מסתיימות, מבלי לדגום עבודה נוספת, כך שמתאם התהליכים (orchestrator) שבו פרסתם אותו, כגון Kubernetes, יוכל להפעיל אותו מחדש עם דיסק נקי, כשהוא מוכן לשרת כל בעלים. - בערך חיובי: המריץ ממשיך לדגום את התור של הבעלים הנעול למשך מספר שניות זה לפני שהוא יוצא.
מחזור חיים זה מבודד את הקוד שנמשך עבור כל בעלים, מבלי לדרוש מהמריץ למחוק את מצב הדיסק בין בעלים שונים.
האופן שבו התשתית שלכם עוצרת מריץ קובע האם אתם זקוקים לדגל --retire-at. פעולת עצירה (kill) ששולחת אות SIGTERM אינה דורשת שום דגל: המריץ מתרוקן כפי שמתואר בתזמון כיבוי, או ממשיך לשרת את ההפעלות שכבר בידיו כאשר אתם מגדירים את --defer-shutdown-max-min. אם התשתית שלכם משמידה מארחים בזמן שעון קיר ידוע מראש ללא אות, או עם תקופת חסד קצרה מכדי לאפשר התרוקנות, כגון מגבלת זמן קיום של ארגז חול (sandbox) או החזרת מופעי ספוט (spot-instance reclamation), העבירו את הדגל --retire-at <epoch-seconds> כשהוא מוגדר למספר דקות לפני מועד זה. במועד הפרישה:
- המריץ מפסיק לקבל עבודה חדשה.
- המריץ משחרר כל הפעלה פעילה דרך אותו נתיב שחרור שבו משתמש הדגל
--release-idle-session-min, כך שההפעלה תתחדש על גבי מריץ רענן כאשר המשתמש ישלח את ההודעה הבאה שלו. המועד שבו המריץ משחרר כל הפעלה תלוי במצבה:- המריץ משחרר הפעלה שנמצאת באמצע תור ברגע שאותו תור מסתיים.
- כאשר תור מסתיים ומשאיר משימות רקע פועלות, המריץ ממתין להן עד 60 שניות, ולאחר מכן משחרר את ההפעלה גם אם הן עדיין פועלות. אם המשימות הסתיימו אך תור ההמשך שקורא את תוצאותיהן טרם רץ, המריץ שומר על ההפעלה עד לסיום אותו תור, וממתין לא יותר מאשר הזמן המוגדר ב-
SELF_HOSTED_RUNNER_BG_RESULT_GRACE_MSלתחילת אותו תור.
- המריץ יוצא עם קוד 0 ברגע שכל ההפעלות שלו שוחררו.
תור שנמשך מעבר לפעולת העצירה עדיין יאבד; תזמון כיבוי עוסק בקביעת גודל מרווח הביטחון. ללא --retire-at, עצירת מארח ללא אות אינה ניתנת להבחנה מקריסה: מישור הבקרה מתעד עובד שאבד במקום שחרור נקי, וההפעלה חוזרת לתור עבור מריץ אחר.
#נתיבי רשת
המריץ וההפעלות שלו יוצרים מספר סוגים של חיבורים יוצאים, ואין צורך בשום קישוריות נכנסת מ-Anthropic:
- מישור בקרה (Control plane): המריץ דוגם את
api.anthropic.comלקבלת עבודה ושולח אירועי התקדמות הגדרה ואירועי כשל, הכל בתקשורת HTTPS יוצאת. הדגימה משמשת גם כדופק חיים של המריץ. - מחבר SCM (SCM connector): מנהרת ה-SCM connector האופציונלית של המתאם היא חיבור ה-WebSocket היחיד.
- Git: המריץ משכפל משרת ה-git שלכם ודוחף אליו באמצעות HTTPS או SSH, ומזדהה באמצעות אישורים שסביבת הפריסה שלכם מספקת; הגדרת git מפרטת את האפשרויות, כולל אישורים המונפקים לפי הפעלה ושימוש ב-Anthropic git proxy, המנתב את תעבורת ה-git דרך
api.anthropic.comבמקום זאת. - תהליך בן של הפעלה (Session child): תהליך ה-Claude Code הבן מחזיק את זרם האירועים של ההפעלה מול
api.anthropic.com, ומבצע קריאות יוצאות משלו לצורך הסקת מודל ועבור פקודות git המורצות במהלך ההפעלה. ראו דרישות רשת לרשימת תעבורת היציאה (egress) המלאה. התרשים לעיל מציג נתיבים אלה, למעט מחבר ה-SCM האופציונלי.
הסקת מודל משתמשת ב-API של Anthropic. מישור הבקרה מספק את נקודת הקצה של ה-API לכל הפעלה, וההפעלה מזדהה באמצעות אסימון OAuth שמונפק על ידי Anthropic ותחום להפעלה בודדת, ולכן לא ניתן לנתב הסקה דרך Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry או דרך שער LLM (LLM gateway) בסביבות באירוח עצמי.
שרתי פרוקסי ארגוניים לתעבורה יוצאת (egress proxies) נתמכים. המריץ ומתאם התאמת קנה המידה האוטומטית האופציונלי מכבדים את משתני הסביבה של פרוקסי ו-mTLS המתוארים בתצורת רשת, כגון HTTPS_PROXY ו-NO_PROXY; הגדירו אותם בסביבה של כל תהליך. המשתנים מכסים קריאות למישור הבקרה, את ה-WebSocket של מחבר ה-SCM במתאם, ואת השכפול המובנה עבור מאגרי HTTPS מרוחקים, וההפעלות יורשות אותם מהמריץ. הזרמת ההפעלה משתמשת באירועים שנשלחים מהשרת (server-sent events) על גבי HTTPS, ולכן פרוקסי בנתיב אינו רשאי לאגור תגובות (buffer responses).
אם הפרוקסי שלכם דורש בנוסף כותרת Proxy-Authorization, המריץ יכול להוסיף אותה לכל חיבור שהוא פותח אל הפרוקסי; ראו אימות מול פרוקסי יוצא.
#מה נשאר בתשתית שלכם
משיכות מאגרי קוד, תוצרי בנייה, סודות וכל הקבצים שהפעלה יוצרת או משנה נשארים במכונות שאתם מקצים. השיחה עצמה, כולל הנחיות (prompts), תגובות ותוצאות כלים, נשלחת אל api.anthropic.com לצורך הסקת מודל, וחברת Anthropic שומרת את תמליל ההפעלה כדי שתוכלו לחדש את ההפעלה ממשטח נתמך אחר.
סביבה באירוח עצמי מעבירה את ביצוע ההפעלות לתוך הרשת שלכם. מישור הבקרה נותר באירוח Anthropic: תיאום ההפעלות (orchestration), ניהול התורים וממשק claude.ai ממשיכים לפעול על התשתית של Anthropic.
#תחילת עבודה
דפי הסביבות באירוח עצמי מאורגנים לפי הפעולה שאתם מבצעים:
- מדריך התחלה מהירה: התקנת Claude Code, יצירת סביבה, הפעלת מריץ וניתוב ההפעלה הראשונה שלכם
- פריסה לסביבת ייצור: הקשחת אבטחה, תעבורת רשת יוצאת (egress), אישורי git, מתכוני Kubernetes ו-Compose, בעיות ידועות ופתרון תקלות
- התאמה אישית של הפעלות: סקריפטים עוטפים (wrapper scripts) עבור אישורים לפי הפעלה, ווי מחזור חיים (lifecycle hooks), מריצים לפי דרישה, שרתי MCP והרשאות
- בדיקה מקצה לקצה: בדיקת עשן (smoke test) ב-CI המאמתת את תמונת המריץ לפני קידומה
- מדריך עזר והפניות: כל דגל CLI, משתנה סביבה, מדד (metric) ונקודת קצה לבדיקת תקינות (health endpoint)
- אימות זהות ההפעלה: אימות אסימון ההפעלה מתוך השירותים שלכם לפני מתן גישה