Redeploy & rollback
Re-release a previous successful deployment instantly.
When a deployment goes wrong — a bad release, a regression you only noticed in production, a config you want to revert — you can roll your service back to any previous successful deployment in seconds, without rebuilding.
Redeploy the current version
A redeploy re-releases the version that is already live. It is useful when you want to:
- Restart all running instances of your service.
- Pick up the latest environment variables (changes apply on the next release).
- Recover from a service in a stuck state.
How
- Open your service.
- Click Redeploy at the top.
- Confirm.
Inhank Cloud restarts your service with a rolling release — zero downtime, same version.
This usually completes in 30 seconds or less.
Roll back to a previous version
A rollback re-releases an older successful deployment. The image was built once and stored, so we can release it instantly — no rebuild needed.
How
- Open your service.
- Go to the Deployments tab.
- Find the deployment you want to roll back to (must be in the
Liveor previously-released state). - Click the ⋯ menu on that row → Redeploy this version.
- Confirm.
Inhank Cloud releases the older version using the same rolling-update mechanism as a normal deployment. Your service is back on that version within ~30 seconds.
Rolling back does not rebuild the application image. It releases the image that was built originally for that deployment — usually live within seconds.
What rollback does and doesn't do
A rollback re-releases the application image from the chosen deployment. The rest of your service's configuration uses current values, not historical ones:
| Source on rollback | |
|---|---|
| Application image (your code) | The chosen deployment's image |
| Environment variables | Current values from the dashboard |
| Custom domains | Current list of verified domains |
| Plan & resource limits | Current plan |
This means: if you change an environment variable then roll back to last week's deployment, you'll be running last week's code with today's env vars.
For a true "everything from last week" rollback, restore the env vars manually before rolling back.
How far back can I roll back?
You can roll back to any deployment that succeeded in the last 30 days. Deployments older than that are pruned from the system; their build logs remain visible for reference, but the application image is no longer available to re-release.
Choosing the right action
| Situation | Use |
|---|---|
| The current version is broken | Rollback to the last known-good deployment |
| The current version is fine, but you want to restart it | Redeploy the current version |
| You changed env vars and want them to take effect now | Redeploy the current version |
| You want to ship the latest commit | Deploy (from the service overview) |
| A previous build failed for a transient reason | Retry that deployment |
Troubleshooting rollback
"Redeploy this version" is greyed out
This deployment is too old; its image has been pruned. Roll back to a more recent deployment, or rebuild the older commit by changing your branch's HEAD to that commit and clicking Deploy.
The service is still broken after rollback
The application image was rolled back, but something else changed in the meantime — usually an environment variable, a custom domain, or an external dependency. Check:
- Your Environment Variables tab — did you set or change a variable that the old version doesn't expect?
- Your Logs — what does the old version actually say when it starts up?
- Any external service it depends on (DB, third-party API) — is it healthy?
Rollback shows "Failed"
The old image was found, but the new instance failed its health check. Most common cause: a recent change to environment variables broke the old code. Open the Logs for the failed deployment to see why.
What's next
Diagnose specific failure modes.
Tail build and runtime logs to see what's happening.