Vision

Advanced

Deployments

How updates reach your live app, what the history shows, and what happens when a deploy fails.

Once a project is published, deployments keep the live app current. You rarely have to think about them — but when you want to look under the hood, everything is in Project settings → Publish.

What triggers a deploy

  • Publish to main — the normal path: publishing work from a session auto-updates the live app.
  • GitHub push — pushes to the repo deploy too, so changes from outside Vision aren’t left behind.
  • Manual deploy — press the button yourself; history records who.
  • Moved to a healthy server — Vision automatically re-homes your app if its server degrades. You’ll see these in history; no action needed.

Following a deploy

Each attempt moves through Queued → Deploying → Deployed, and the newest successful build is marked Active — that’s what’s live right now. Live logs are one click away while a deploy runs, and stay attached to the attempt afterwards.

Deploy history

Publish to main

took 1m 12s · 8m ago

Active

Manual deploy by Karen

took 58s · 2h ago

Deployed

GitHub push

took 44s · 5h ago

View logs Didn't go live

Moved to a healthy server

took 1m 3s · 2d ago

Deployed

"Didn't go live" means exactly that — the previous build kept serving while this one was held back.

Deploy history: what triggered each attempt, how it went, and which build is serving right now.

When a deploy fails

A failed update shows as “Didn’t go live” — and that’s exactly what it means: the bad build is held back and your previous version keeps serving users. The card in chat is honest about severity: a held-back update says “ask Vision in chat to fix it — your app still runs the previous version”, while a genuine outage says so plainly, and problems on Vision’s side are labeled as such (“we’ve been alerted”). Either way there’s a Retry deploy link, the raw error sits behind “Show technical details”, and the fastest fix is pasting the error into chat and letting the agent handle it.

Deployment history

The history lists every attempt: what triggered it, who (for manual deploys), when, how long it took, the areas it touched, and its outcome. Together with the version markers in Rollbacks, you can always answer “what is live, and how did it get there?”

What the live app runs

Per service, the Publish tab shows the exact command your live app runs. Services with a production command run an optimized build; ones marked dev command run their development server live — that works, but it’s slower, so the tab nudges you to set a production command in the Apps tab. Ask the agent to set one up if you’re unsure.