Operate
Running a deployed tool — logs, debugging, updates, suspend/resume, and teardown.
A published tool isn't shipped, it's living. Tenants deploy it, run it, hit edge cases, suspend it when they're not using it, and occasionally tear it down. This subsection covers the operational surface a tool author works with after publishing.
The operations are mostly tenant-driven through the dashboard — but as the tool author you're the one who interprets logs, ships fixes, and decides what happens when something goes wrong. None of this surface requires SSH or direct Railway access; everything flows through Vendo APIs.
What's on each page
Logs and debugging
The three log surfaces, where each comes from, and what they tell you.
Updating a tool
Shipping a new version to tenants — how Vendo upgrades a running deployment.
Suspend & resume
What suspended state means, when it happens, and how to recover.
Teardown
Destroying a deployment — what disappears, what survives, and what doesn't.
Read these in order on your first incident
When something breaks for a tenant: Logs and debugging first to identify the failure mode. Then Updating a tool if the fix needs a new release, or Suspend & resume if the deployment got stuck in a transitional state. Teardown is rarely the answer — it's destructive and not something to reach for while debugging.
Where to look outside docs
- The tenant's dashboard (
https://vendo.run) showscurrent_step,progress, and per-step log entries from the deploy worker for any running deployment. - The deployment's compute logs (Railway, Cloudflare) are surfaced via the dashboard's Logs tab — no separate Railway access needed.
- For platform-level issues (proxy 5xx, KV staleness, deploy worker faults) that look like tool bugs but aren't, contact Vendo support before re-cutting a release.