Claude CodeClaude Code

The agent that wrote your application can deploy it, read its logs, and roll it back, without you copying anything between two windows. One command wires it up. The guardrails are on the server, not in the prompt.

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

Connect in one commandחיבור בפקודה אחת

Create a key in the panel under API keys, then register the Shipyard MCP server with Claude Code:

יוצרים מפתח בפאנל תחת מפתחות API, ואז רושמים את שרת ה-MCP של Shipyard ב-Claude Code:

terminal
claude mcp add shipyard \
  -e SHIPYARD_API_KEY=sy_live_xxxxxxxxxxxxxxxxxxxx \
  -- npx -y @shipyard/mcp

That is the whole setup. Start Claude Code in your project directory and ask it to deploy. It will call project_link once to bind the directory, then deploy.

זו כל ההתקנה. מפעילים את Claude Code בתיקיית הפרויקט ומבקשים לפרוס. הוא יקרא פעם אחת ל-project_link כדי לקשר את התיקייה, ואז ל-deploy.

Where the key comes fromמאיפה מגיע המפתח

Resolution order, first match wins:

סדר ההיררכיה, ההתאמה הראשונה מנצחת:

  1. 1SHIPYARD_API_KEY in the environment. This is the path above, and the right one for CI and for per-agent scoping.SHIPYARD_API_KEY בסביבה. זה המסלול שלמעלה, והנכון ל-CI ולהגבלה לפי סוכן.
  2. 2~/.shipyard/credentials, written by shipyard login. Convenient on your own laptop.~/.shipyard/credentials, נכתב על ידי shipyard login. נוח על מחשב אישי.
  3. 3Nothing. The tools return a clear “not authenticated” error telling the agent to ask you to run shipyard login. It does not guess and it does not prompt for a password.כלום. הכלים מחזירים שגיאת ”לא מאומת“ ברורה שמנחה את הסוכן לבקש מכם להריץ shipyard login. הוא לא מנחש ולא מבקש סיסמה.

What the agent can doמה הסוכן יכול לעשות

whoamiWhich org and role this key belongs to.לאיזה ארגון ותפקיד שייך המפתח.
projects_listProjects the key can see.הפרויקטים שהמפתח רואה.
project_linkBind the current directory to a project.קישור התיקייה הנוכחית לפרויקט.
deployBuild and release. Production needs confirm: true.בנייה ושחרור. בייצור נדרש confirm: true.
deployment_statusWhere a deploy got to, including scan verdict.לאן הפריסה הגיעה, כולל פסיקת הסריקה.
logs_tailRecent log lines, filtered, bounded.שורות לוג אחרונות, מסוננות ותחומות.
env_listVariable names and metadata. Never values.שמות משתנים ומטא-דאטה. אף פעם לא ערכים.
env_setSet a variable. Secrets need confirm: true.הגדרת משתנה. סודות דורשים confirm: true.
rollbackPrevious release. Production needs confirm: true.חזרה לגרסה קודמת. בייצור נדרש confirm: true.
security_report_getThe scan report for a given deployment.דוח הסריקה של פריסה נתונה.
domains_listHostnames attached to a project, with TLS state.שמות מארח המחוברים לפרויקט, עם מצב TLS.

What the agent cannot doמה הסוכן לא יכול לעשות

Treat an API key like a deploy keyהתייחסו למפתח API כמו למפתח פריסה

sy_live_… is shown once, at creation. It is hashed on our side and cannot be recovered, only rotated. Do not paste it into a chat, a ticket, or a file your agent can read back and echo.

sy_live_… מוצג פעם אחת בלבד, ביצירה. הוא נשמר אצלנו כ-hash ואי אפשר לשחזר אותו, רק לסובב. אל תדביקו אותו בצ׳אט, בקריאת שירות, או בקובץ שהסוכן שלכם יכול לקרוא ולהחזיר.

Multiple users, multiple agentsריבוי משתמשים, ריבוי סוכנים

An organisation can hold as many keys as it has humans and agents. Keys are not shared and should not be: every deploy, log read and variable change is attributed to the key that made it, and an attributed audit trail is only useful if the attribution is real.

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

A pattern that worksדפוס שעובד

  1. 1One key per developer, created by that developer, scoped to the projects they actually work on.מפתח אחד לכל מפתח/ת, שנוצר על ידו, מוגבל לפרויקטים שהוא באמת עובד עליהם.
  2. 2One key per autonomous agent, scoped to staging only, with no env:write scope. Agents iterate freely there and nothing they do can reach a customer.מפתח אחד לכל סוכן אוטונומי, מוגבל ל-staging בלבד, בלי הרשאת env:write. הסוכנים מתנסים שם בחופשיות ושום דבר שהם עושים לא מגיע ללקוח.
  3. 3One key per CI pipeline, stored in the CI secret store, scoped to deploy and nothing else.מפתח אחד לכל צינור CI, נשמר במאגר הסודות של ה-CI, מוגבל לפריסה בלבד.
  4. 4Promotion to production stays with a human role, or with an agent key that a human explicitly granted deploy:prod.העלאה לייצור נשארת בידי תפקיד אנושי, או במפתח סוכן שאדם העניק לו במפורש deploy:prod.

Roles are owner, admin, developer and viewer. A key can never exceed the role of the member who created it, so a developer cannot mint an admin key by asking an agent nicely.

התפקידים הם owner, admin, developer ו-viewer. מפתח לעולם לא יכול לחרוג מהתפקיד של מי שיצר אותו, ולכן developer לא יכול לייצר מפתח admin על ידי בקשה מנומסת מסוכן.

Without MCPבלי MCP

If you would rather the agent just used the shell, that also works and needs no setup beyond an environment variable. Every CLI command supports --json, which prints a stable machine-readable object instead of the human table.

אם אתם מעדיפים שהסוכן פשוט ישתמש ב-shell, גם זה עובד ולא דורש שום הגדרה מעבר למשתנה סביבה. כל פקודת CLI תומכת ב---json, שמדפיסה אובייקט יציב וקריא-מכונה במקום הטבלה האנושית.

terminal
export SHIPYARD_API_KEY=sy_live_xxxxxxxxxxxxxxxxxxxx

shipyard deploy --json | jq -r '.deployment.url'
shipyard logs --since 5m --json | jq -r 'select(.level=="error") | .message'
Why MCP is still betterלמה MCP עדיין עדיף

The shell path gives an agent whatever your shell can do. The MCP path gives it eleven typed tools and nothing else, with the dangerous ones behind an explicit confirmation. Same work, much smaller blast radius.

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