RightSide Docs
For coding agents

Do not stop at “deploy started.”

Treat RightSide as a bounded completion tool. Inspect first, deploy through CLI or MCP, repair actionable failures, and stop only on verified live state or a real authority boundary.

Recommended agent instruction

Install and set up RightSide on this machine. Verify that Node.js is 22.13 or newer and that this is Linux x64, WSL2 x64, or Apple silicon macOS. Run `curl -fsSL https://get.rightside.host/install | sh`, let me complete browser authorization, and never ask me to paste a token, device code, cookie, or secret into chat. Then run `rightside doctor --json`. If it passes, inspect this project and deploy it with RightSide. Do not claim success until RightSide returns an HTTPS URL and you verify that URL responds correctly.

This prompt is intentionally complete: it checks prerequisites, keeps browser authorization with the person, installs the CLI and MCP integration, verifies diagnostics, and requires live URL proof.

Execution loop

  1. Run rightside doctor --json.
  2. Inspect the project start command, health behavior, port binding, Dockerfile, and ignored files.
  3. Use rightside deploy when completion must include RightSide’s external HTTPS probe. If using MCP deploy_project, treat its response as control-plane state only.
  4. On failure, classify the failed stage before editing source.
  5. Use get_logs or rightside logs only as needed. Logs are redacted, but should still be treated as operational data.
  6. Retry only after a concrete fix. Avoid blind deploy loops.
  7. After MCP deployment, fetch the returned HTTPS URL directly and require an expected HTTP response. project_status and rightside status do not prove public reachability.
  8. Return the URL and state exactly what was verified.

Use exact proof states

StateMeaning
INSPECTEDThe agent read the relevant source and deployment contract.
IMPLEMENTEDSource was changed and deterministic local checks passed.
DEPLOYEDRightSide activated the release and the exact HTTPS endpoint was verified.
BLOCKEDA real access, product, or operator-authority boundary prevents completion.

Safe defaults

  • Database-free deployment unless the user explicitly asks for persistence.
  • Hosted-app authentication is enabled on CLI/MCP project creation. Use public path rules or explicit auth:false/--no-auth when required.
  • No arbitrary remote shell. Use bounded RightSide operations.
  • No secrets in model context, source, command arguments, logs, or MCP registration.
  • No unsupported platform claims. Check current limits.

Machine-readable discovery