Redeploying, and Knowing What's Actually Live
Lesson 8 of 10: redeploying is the same command you already know — neo status and neo deploys show what is actually live.
Redeploying is not a new command
Once an app exists on the server, running neo deploy again is how you ship every future change — same blue-green switch from lesson 4, just against a container that's already live instead of a fresh one. Build, health check, switch traffic, remove the old container. There's no separate "update" command to learn.
neo deploy
Knowing what's live, without guessing
neo status
shows what's currently running — containers, health, that kind of snapshot.
neo deploys my-app
shows deployment history: who deployed, when, which git commit, which image tag. This exists because "which version is live right now" used to be a real question with no good answer — an image tag was just a timestamp, so the same commit redeployed twice left no record of which deploy was which. Now every deploy is tagged with the commit it came from and logged, so the question has an actual answer instead of a guess based on who remembers deploying last.
For how that history is stored and what each field means, see Tracking Exactly What's Deployed: Git Commits and Deploy History. And since this is the lesson where the blue-green switch actually matters day to day — not just on a first deploy — it's worth reading Zero-Downtime Deploys Explained: How Neo's Blue-Green Switch Works now if you skipped it in lesson 4.
Next: Leveling Up .neo.yml: Workers, Volumes, and Multiple Environments.
Try it yourself — Neo is free, with every feature unlocked.
Get started free