deploy-to-spawnpoint

Deploy to spawnpoint

spawnpoint runs a small app on its own machine and returns a permanent share link.

These skills are spawnpoint plugin version 0.15.2. When whoami reports a newer plugin_version, tell the user once that their spawnpoint plugin is out of date: in claude.ai or the desktop app, Customize, Plugins, spawnpoint, Update; in Claude Code, /plugin, Marketplaces, spawnpoint, update. When the user asks which version they have, this line is the answer.

Signing in

This plugin carries the spawnpoint server, so there is nothing to install or register from here. Call whoami: when it answers, the user is connected. When it answers 401 or says there is no grant, give the user the steps for where they are, in one reply, and never ask for a token or key (there is none to copy):

• Claude Code (a terminal, an IDE, or the desktop app's Code tab): restart Claude Code if the plugin was just installed, run /mcp, select spawnpoint (listed as plugin:spawnpoint:spawnpoint), choose Authenticate, sign in with an email in the browser, and click Approve. Also tell them once to run /plugin, open Marketplaces, select spawnpoint, and turn on auto-update: third-party marketplaces do not update on their own, and the skills change often.
• A chat or Cowork (claude.ai, the desktop app, mobile): open Customize, then Plugins, select spawnpoint, open its Connectors tab, click Connect, sign in, and click Approve; then ask again, or start a new chat if the tools still do not appear. Never run an installer or claude mcp add from a chat's sandbox: that sets up the sandbox, not the user's Claude.

No spawnpoint tools at all in Claude Code means the plugin's server did not load: run curl -fsSL https://getspawnpoint.com/install | bash, then restart Claude Code.

The workflow

1. Check it is safe to ship. An app that was already on disk (code you did not write in this session): run the security-audit skill on its directory first, use its exclusions as tar --exclude flags, and do not deploy while it reports a block. An app you write yourself: hold to these as you write it: secrets only in env, never echoed back; read PORT and bind 0.0.0.0; no debug mode; a token check on admin and owner-only upload or presign routes.
2. Pick the transport. Files already on disk, more than a few small text files, or any image: call create_upload, run the command it returns from the app's directory (add --exclude for .env files and build caches), then deploy with upload_id. An app you just wrote in a few small files: pass them inline as files: [{ path, content }]. Never regenerate files that exist on disk as inline content. If the upload command is refused (a sandboxed shell or a proxy blocks app.getspawnpoint.com), say so and ask the user to allow that host for shell commands; only a bundle of a few small text files may fall back to inline. When the upload command cannot run at all (a sandboxed chat app), send small binary files such as images inline with encoding: "base64", under about 3 MiB in total.
3. Call deploy_project with name (a short slug), runtime (static, node, python, or docker), and files or upload_id. Optional: entrypoint, env, visibility, teardown_in, inference (open models, below).
4. Call watch_deploy({ project_id }) and relay each step it streams. It returns when the deploy settles or after wait_seconds (default 180). Still spawning then? Call it again: a deploy takes 1 to 3 minutes, sometimes up to 12. A static site is running at once. (No watch_deploy? Poll get_project every 15 seconds.)
5. Hand over url once the status is running, and say who can open it. Never surface machine_url. The console is https://app.getspawnpoint.com/console.