מדריך מלא לפריסת אפליקציה מ-Claude Code: חיבור דרך MCP או plugin פתוח, יצירה או העברה של פרויקט קיים, ואחסון עם דאטהבייס, הרשאות, דומיין ו-TLS אוטומטי.
בונים שעובדים ב-Claude Code ורוצים שהפרויקט שבנו יעלה לאוויר, עם אחסון, נתונים והרשאות מסודרים.
- מסלול פריסה עובד מ-Claude Code לכתובת חיה בסשן אחד
- תמונה ברורה של מה הפלטפורמה מארחת עבורך: עמודים, מסד נתונים, הרשאות ודומיינים
- מבחן כן לשאלה מתי אחסון סטטי דווקא מתאים יותר
כדי לפרוס אפליקציה מ-Claude Code צריך לחבר את Claude ל-runtime שיודע לארח אותה. אצלנו יש שתי כניסות: להוסיף את https://finestructure.ai/api/mcp כ-custom connector בהגדרות של claude.ai ולאשר את מסך ה-OAuth, או להתקין את ה-plugin הפתוח עם /plugin marketplace add finestructure-ai/claude-plugin ואחריו /plugin install finestructure@finestructure. משם Claude או מייצר אפליקציה שלמה עם create_app, או מעביר את הפרויקט הקיים שלכם לתוך ה-runtime קובץ אחרי קובץ, והתוצאה רצה כדפי React מאוחסנים עם דאטהבייס מנוהל, הרשאות, דומיין מותאם וחזרה לגרסה שמורה. יש free tier בלי כרטיס אשראי: יצירת אפליקציה צורכת קרדיטים, ועריכות קבצים, פרסום ודומיינים הם בחינם.
Claude Code יודע לכתוב אפליקציה שלמה, ולא יודע להריץ אותה. בסוף השיחה נשארת תיקייה על הדיסק: קומפוננטות React, מודל נתונים שהתגבש תוך כדי דיבור, ומסך התחברות שמניח בשקט שאיפשהו יש שרת. הפריסה היא הרגע שבו התיקייה הזאת מפסיקה להיות מקומית ומקבלת כתובת, דאטהבייס מאחוריה, ומסך כניסה שגם אנשים שהם לא אתם מצליחים לעבור.
התשובה הרגילה לשלב הזה היא צנרת. להעלות ל-repository, לחבר ספק CI, להקים דאטהבייס במקום אחר, להוסיף שירות הרשאות, לכוון DNS ולחכות לתעודות. כל חלק בפני עצמו נשמע הגיוני, והסכום שלהם הוא אחר צהריים שלם שנעלם בין חמישה טאבים. התשובה השנייה היא לתת ל-Claude Code גישה ישירה ל-runtime שכבר מכיל את כל החלקים האלה, וכך הפריסה הופכת לקריאת כלי אחת בתוך אותה שיחה במקום לרשימת מטלות.
הניסוח הכן: הפלטפורמה שלנו היא לא כפתור deploy שמורכב על הסטאק שכבר יש לכם. היא runtime, והאפליקציה עוברת לגור בתוכה. זאת עסקה אמיתית לשני הכיוונים: מקבלים אחסון, דאטהבייס, הרשאות וטיפול בדומיינים בלי להרכיב אותם, ומוותרים על שליטה בשכבת השרת.
יש שתי דרכים, והן מגיעות בדיוק לאותו מקום: אותו חשבון ואותן אפליקציות. אם רוב העבודה שלכם מתרחשת ב-claude.ai, ה-connector הוא ההתקנה הקצרה יותר. אם אתם חיים בטרמינל ורוצים שפקודות הפריסה ישבו ליד הקוד שאתם עורכים, קחו את ה-plugin.
דרך ראשונה: MCP connector: נכנסים להגדרות ב-claude.ai, בוחרים Add custom connector, מדביקים את הכתובת https://finestructure.ai/api/mcp ומאשרים את מסך ה-OAuth. זה קליק אחד. אין API key להעתיק ואין משתנה סביבה שנשאר לנצח בקובץ הגדרות. מהרגע הזה Claude רואה בערך 70 כלים: יצירת אפליקציה, כתיבת קבצים, entities, פרסום, דומיינים ואנליטיקס.
דרך שנייה: plugin פתוח ל-Claude Code: מריצים /plugin marketplace add finestructure-ai/claude-plugin, ואחר כך /plugin install finestructure@finestructure. הפקודות /deploy, /fs-status ו-/fs-domain נכנסות ל-session. הקוד של ה-plugin פתוח, אז אפשר לקרוא בדיוק מה הוא שולח לפני שמתקינים אותו, במקום להאמין לתיאור.
לגבי הופעה בדירקטוריות: ההגשות שלנו לדירקטוריות עדיין בבדיקה. עד שהיא תסתיים לא נתאר את ה-connector או את ה-plugin כ-official, verified או listed. הסיבה להתקין אותם היא שהכתובת גלויה והקוד קריא, לא תג ליד השם.
יש שני מצבי פריסה, וההבדל ביניהם גדול ממה שהוא נראה במבט ראשון. אחד מתחיל ממשפט. השני מתחיל מ-repository שכבר רבתם איתו פעם או פעמיים.
create_app מקבל prompt ומייצר אפליקציה שלמה: דפים, סכימות entities, חיבור הרשאות וכתובת עובדת. זה המסלול המהיר כשהרעיון עדיין רך, והדרך הכי מהירה להבין אותו היא פשוט להסתכל עליו. יצירת אפליקציה היא החלק היחיד בתהליך שנמדד, כי היא צורכת קרדיטים. כל מה שעושים לאפליקציה אחר כך לא.
המצב השני מעביר פרויקט קיים. Claude קורא את הקבצים שלכם וכותב אותם מחדש לתוך ה-runtime של הפלטפורמה, קובץ אחרי קובץ: דפים הופכים לדפים של הפלטפורמה, מודל הנתונים הופך ל-entities, וקריאות ההרשאות נכתבות מחדש מול ההרשאות של הפלטפורמה. זאת העברה, לא העלאה עיוורת. כל קובץ שהניח שרת שבשליטתכם נכתב מחדש כדי לעבוד מול ה-runtime, וכאן בדיוק שווה שיהיה Claude Code בצד השני, כי הוא יכול לעבור על כל import ולתקן אותו במקום שבו הוא נמצא.
איך נראה session ראשון אמיתי: מבקשים מ-Claude ליצור את האפליקציה, פותחים את ה-preview, וממשיכים לערוך קבצים באותה שיחה עד שהדפים באמת נראים כמו מה שהתכוונתם. עריכות קבצים ופרסום לא צורכים קרדיטים, אז לולאת השיפור שאחרי היצירה היא בחינם ואפשר להרשות לעצמכם להיות בררנים. כשזה נראה טוב, מפרסמים, מחברים דומיין ונותנים ל-TLS להסתדר לבד.
אחסון סטטי הוא דבר טוב מאוד. אם התוצר שלכם הוא bundle של frontend ותו לא, הוא יוגש שם מהר יותר, בזול יותר, ועם אקוסיסטם גדול משלנו. זאת לא הודאה שנסחטה מאיתנו, זאת בדיוק הנקודה: ההשוואה נעשית מעניינת רק כשהאפליקציה צריכה state, משתמשים ודרך חזרה לאתמול.
מה האפליקציה צריכה | Fine Structure | יעד אחסון סטטי
אחסון | דפי React מאוחסנים שמוגשים מתוך ה-runtime של הפלטפורמה | המהירות הגולמית הכי טובה ל-frontend, והאקוסיסטם הרחב ביותר
דאטהבייס | entities מנוהלים, קיימים כבר לפני הפריסה הראשונה | מביאים משלכם, מקימים ומחברים בנפרד
הרשאות | מובנות, עם sessions ומשתמשים לכל אפליקציה | מביאים שירות הרשאות משלכם או ספק צד שלישי
דומיינים | דומיין מותאם עם TLS אוטומטי מהפלטפורמה | דומיין מותאם עם TLS אוטומטי, בדרך כלל תהליך בשל
חזרה אחורה | שחזור של גרסה שמורה של האפליקציה | פריסה מחדש של build קודם או ביטול ה-commit
סוכנים | סוכני AI שממשיכים לעבוד אחרי הפריסה, לפי לוח זמנים | לא חלק מהפלטפורמה, מריצים אותם במקום אחר
מתי אנחנו הבחירה הלא נכונה: שלושה מקרים שבהם עדיף לכם משהו אחר, ואנחנו נגיד את זה לפני שתבזבזו יום כדי לגלות. runtime שרת מותאם שחייב להיות שלכם, למשל בינארי ב-Go או worker בפייתון עם ספריות מערכת מסוימות. monorepo עם בקאנד משלו שאתם לא מתכוונים לכתוב מחדש. ואחסון סטטי בקנה מידה גדול, שבו CDN בלי דאטהבייס הוא בדיוק הצורה הנכונה למשימה.
הפריסה היא לא סוף העבודה. היא הנקודה שבה האפליקציה מתחילה לייצר עובדות במקום דעות. ארבעה דברים נפתחים שם, ואף אחד מהם לא דורש לצאת מהשיחה שאתם כבר נמצאים בתוכה.
הסוכנים הם החלק שמפתיע אנשים. סוכן כאן הוא לא ווידג'ט צ'אט שהודבק על הדף. הוא עובד שמחובר לאפליקציה, ממשיך לרוץ לפי לוח זמנים גם אחרי שסגרתם את המחשב, קורא את הנתונים של האפליקציה עצמה, ויודע להגיע אליכם: בעלים מאומת מקבל הודעה ב-WhatsApp או במייל. זה הופך את היחסים הרגילים עם אפליקציה פרוסה, כי האפליקציה יכולה לספר לכם שקרה משהו במקום לחכות שתיכנסו לבדוק.
כל מה שקורה אחרי היצירה נשאר בתוך אותה שיחה עם Claude. לשנות קובץ, לפרסם, לבדוק דומיין, לקרוא אנליטיקס, לכוון סוכן, לפרסם שוב. ה-free tier לא מבקש כרטיס אשראי, אז הדרך הכנה לבדוק את כל זה היא לכוון את Claude לאפליקציה אמיתית אחת וקטנה ולראות עד לאן הוא מגיע לפני שנתקלים במשהו שאנחנו לא יודעים לעשות.
לא לבד. Claude Code כותב ועורך קבצים, והוא צריך יעד שיודע לארח אותם. ברגע שמוסיפים את ה-MCP connector שלנו או מתקינים את ה-plugin, הפריסה הופכת לקריאת כלי ש-Claude מבצע ישירות: יצירת האפליקציה, כתיבת קבצים, פרסום וחיבור דומיין.
https://finestructure.ai/api/mcp. ב-claude.ai נכנסים להגדרות, בוחרים Add custom connector, מדביקים את הכתובת ומאשרים את מסך ה-OAuth. אין API key להעתיק ואין token לשמור אצלכם, ומהרגע הזה Claude רואה בערך 70 כלים.
מריצים /plugin marketplace add finestructure-ai/claude-plugin, ואחר כך /plugin install finestructure@finestructure. מקבלים את /deploy, /fs-status ו-/fs-domain. הקוד פתוח, וההגשות שלנו לדירקטוריות עדיין בבדיקה, ולכן אנחנו לא מתארים אותו כ-official או verified.
יש free tier והוא לא מבקש כרטיס אשראי. יצירת אפליקציה צורכת קרדיטים. עריכות קבצים, פרסום ודומיינים מותאמים לא צורכים, כך שלולאת השיפור שאחרי היצירה הראשונה לא עולה כלום.
כן. Claude מעביר את הפרויקט לתוך ה-runtime של הפלטפורמה קובץ אחרי קובץ: דפים הופכים לדפים של הפלטפורמה, מודל הנתונים הופך ל-entities, וקריאות ההרשאות נכתבות מחדש. זאת העברה ולא העלאה, אז חלק מהקבצים ישנו צורה בדרך.
כן. מוסיפים דומיין מותאם וה-TLS מונפק אוטומטית. אפשר לעשות את זה מהטרמינל עם /fs-domain, או פשוט לבקש מ-Claude דרך ה-MCP connector בלי לצאת מהשיחה.
משחזרים גרסה שמורה. השחזור מחזיר את האפליקציה למצב שמור קודם, וזה בדרך כלל מהיר יותר מלאבחן שינוי בפרודקשן. אחר כך יש לכם בסיס עובד להשוות מולו כדי להבין מה בעצם נשבר.
כשצריך runtime שרת מותאם שחייב להיות שלכם, למשל בינארי ב-Go או worker בפייתון עם ספריות מערכת מסוימות. כשיש monorepo עם בקאנד משלו שלא הולכים לכתוב מחדש. וכשרוצים אחסון סטטי בקנה מידה גדול, שבו CDN בלי דאטהבייס הוא התשובה הנכונה.