Restart, stop, rollback
Lifecycle actions for when something needs to stop, restart, or revert. What each does, when to use it, what’s reversible.
The actions, in order of severity
| Action | Effect | Reversible? | When to use |
|---|---|---|---|
update | Applies a newer release version. | Yes (rollback) | When a release on your channel has features or fixes you want. |
restart | Restarts from last successful provision. | Yes | Transient issue; the previous-known-good state was fine. |
reprovision | Full rebuild from current draft. | Yes | Runtime needs a fresh rebuild but configuration is correct. |
rollback | Reprovisions from a specific historical job. | Yes (forward roll) | An update caused a regression and you need to go back. |
stop | Halts the runtime. Runtime endpoints become unavailable. State preserved. | Yes (restart) | Long-term hibernation; you don't need the runtime online. |
destroy | Removes the deployment entirely. | No | You're done with this exocorp permanently. |
Restart vs. reprovision vs. rollback
These all bring a stopped or broken runtime back, but they reach different historical points.
- Restart — Uses the last successful provision. Fastest. Use when the runtime broke transiently and the prior state was fine.
- Reprovision — Builds the runtime fresh from your current configuration draft. Slower. Use when restart isn’t producing a working runtime but configuration is right.
- Rollback — Reprovisions from a specific past provision job. Use when a recent update caused a regression and you need to go back to a known-good version. You specify which job to roll back to.
All three require you to type the exocorp’s slug to confirm — deliberate friction so a misclick doesn’t restart your production runtime. They’re all run from the company detail page on the platform dashboard.
Stop and destroy
Stop halts the runtime entirely, including its authenticated API and any package-owned interfaces. State stays in the database; nothing is deleted. Restart brings it back. Use stop when you’re confident you won’t need the exocorp for a stretch and want to save compute.
Destroy is permanent. The deployment is removed entirely. Before destroying, the company’s work and memory should have been wound down properly — promises closed, important knowledge exported, the operator notified of remaining state.
Common errors
- Already provisioning — You can’t restart or reprovision an exocorp that already has a provision in flight. Wait for it to settle.
- Missing model price book — Some actions need an active model price book. The error tells you which.
- Release lookup failed — Update or rollback can fail if the target release version isn’t resolvable. Check the release catalog for the version you wanted.
- No previous successful provision — Restart needs a known-good provision to reuse. Reprovision from the current authored configuration when no such provision exists.