---

name: runtime-deployment description: "Start, self-host, debug, and deploy RocketRide runtime and engine." metadata: disco-role: operating disable-model-invocation: true license: MIT

Runtime Deployment

Use this sub-skill when a task is about starting a RocketRide engine, choosing Cloud versus self-hosting, checking runtime connectivity, explaining the native WebSocket/DAP protocol, or deploying the engine with a release archive, source build, Docker Compose, or Helm.

Use this for

• Starting a local or on-prem RocketRide engine on port 5565
• Choosing the right client URI for Cloud, a local binary, Docker, or Kubernetes
• Debugging /ping, /task/service, WebSocket upgrades, auth, and task events
• Explaining which SDK calls map to which DAP-style runtime commands
• Planning release-archive, source-build, Docker Compose, or Helm deployments
• Reasoning about observability events, trace levels, and runtime metrics
• Placing provider API keys, database credentials, and vector-store settings in the engine environment without hardcoding secrets in .pipe files

Do not use for

• Python or TypeScript SDK method details and code examples → ../sdk-clients/
• .pipe design, lane wiring, or pipeline recipes → ../pipeline-authoring/
• Node provider schemas and generated node docs → ../nodes-catalog/
• VS Code extension/runtime UX and visual app surfaces → ../ide-and-apps/
• MCP server, n8n, assistant-tool, or webhook integration details → ../mcp-and-integrations/

Route first

• Read self-hosting and protocol for release archives, source builds, Linux runtime dependencies, the engine command, Cloud/local URI rules, /ping, /task/service, DAP frames, SDK-to- command mapping, auth, and observability.
• Read Docker and Helm for Compose services, host versus container networking, Kubernetes values, secrets, external databases, GPU scheduling, HA, probes, and deployment validation.
• Read troubleshooting when a runtime does not listen, a client cannot connect, auth fails, observability is silent, Docker networking is wrong, Helm rendering/deployment fails, or provider credentials are missing.

Safety and execution guardrails

• Do not start long-running engines, Docker stacks, Kubernetes deployments, or source builds unless the user explicitly asks for that action and accepts the local side effects.
• Prefer static review and command planning when the user only asks what to run.
• Never test real provider credentials or Cloud tokens unless the user supplies them for that purpose.
• Treat source builds, Docker, Helm, GPU, database, and external-provider paths as optional deployment workflows, not required smoke checks for ordinary skill use.

Quick triage order

1. Identify target: Cloud, release archive, source-built runtime directory, Docker Compose, or Helm.
2. Check the expected endpoint:
   • Health: http://<host>:5565/ping
   • Task socket: ws://<host>:5565/task/service
   • Cloud base URI: https://api.rocketride.ai with token auth
3. Verify whether the problem is a listening/binding issue, URI/scheme issue, authentication issue, proxy/WebSocket-upgrade issue, or provider/runtime dependency issue.
4. Use runtime events only for live observation: RocketRide observability is a WebSocket event stream, not a durable metrics database.

Good output for deployment tasks

• Names the target mode and exact endpoint scheme
• Shows a health check and expected signal
• Separates local auth assumptions from Cloud/production auth requirements
• Keeps provider secrets in environment variables or Kubernetes Secrets
• Notes when a command is heavy or starts services
• Includes rollback/stop or dry-run guidance for Docker and Helm