Key idea
Redeploy applies the settings you saved. Restart reruns exactly what's running. Stop takes the service offline and Start brings back what ran before. None of them deploys a new image.
Which one?
| Action | What runs afterwards | Traffic while it happens | Status on the way |
|---|---|---|---|
| Redeploy | Your latest saved settings | Old spherelets serve until new ones are healthy | Redeploying → Running |
| Restart | The settings already running | Spherelets replaced one at a time | Restarting → Running |
| Stop | Nothing | Stops | Stopping → Stopped |
| Start | The version running before the stop | Starts again | Starting → Running |
Every status is explained in lesson 5.1.3. Rollback, the fifth action, has its own lesson (5.7.4).
Redeploy: apply what you saved
Redeploy recreates the service's spherelets from its current settings: image, variables, secrets, port, health check and spherelet count. Everything you saved since the last deploy takes effect. If nothing has changed since then, there's nothing to roll out and the same spherelets keep running; for fresh ones, restart.
It rolls out like a new image. New spherelets start next to the old ones and only get traffic once they pass their health check (lesson 5.7.2). If they never do, the redeploy ends Failed and the old spherelets keep serving.
Use it after you save a setting without applying it: Save only when the console asks Apply changes?, or Later on the health check.
Restart: same thing, fresh process
Restart replaces each spherelet with a fresh copy of exactly what's running now. Use it for a stuck process: a hung connection, a memory leak, a cache in a bad state.
Restart does not pick up settings you've changed since the last deploy. For those, redeploy.
Stop: take it offline
A Running service goes to Stopping. Each spherelet gets up to 30 seconds to finish the requests it's handling, then the service is Stopped.
While it's stopped, its URL and custom domains stay assigned but nothing answers behind them. Its settings, variables, secrets and history are kept.
Stopping a service that's still coming up
If the service is still Deploying, Starting, Restarting and so on, Stop sends it straight to Stopped: there's nothing to drain, and anything half-started is removed.
During a first deploy, the console shows Cancel in place of Stop. It does the same thing and ends in Stopped. Stopping a service that's already stopped is refused.
Start: bring it back
Start brings back the version that ran before the stop, at the service's spherelet count (at least 1). It goes Starting, then Running.
Start doesn't apply settings you changed while stopped. Start and then redeploy, or just redeploy.
Check yourself
Where to find them
Open the service. Its page has Redeploy, Restart, Stop (or Start when stopped), and Cancel while something is in progress.
csph deployments redeploy <deployment-id>
csph deployments restart <deployment-id>
csph deployments stop <deployment-id>
csph deployments start <deployment-id>
Leave out the ID to pick from a list, or find it with csph deployments list (lesson 5.1.1). Each waits until the service is running or stopped; --no-wait returns straight away.