Deployment retention
When old deployments expire, what an expired deployment still serves, and how to bring one back.
Old deployments do not stay fully browsable forever. Once a deployment can no longer reasonably be visited, Gigadrive Network expires it: its Functions, logs, and build details remain, but its static assets are removed.
When a deployment expires
| Deployment | Expires after |
|---|---|
| Failed | 30 days |
| Ready, but inactive | 60 days without a single request |
| Ready and receiving traffic | Never |
A Failed deployment never served requests, so retention only removes its uploaded assets; its status stays Failed rather than moving to Expired.
A Ready deployment counts as inactive only when all of the following hold:
- It is not the deployment behind your production URL or any branch URL.
- It is not one of the five most recent Ready deployments of its environment. Those stay available for clients that loaded an older version of your app and still request its files.
- It served no request at all for 60 days.
What an expired deployment looks like
When a Ready deployment expires, it moves to the Expired status. You can see it in the Console and in the API, next to Ready and Failed.
An expired deployment is not deleted:
- Its Functions keep serving requests on its
<name>-<id>.gigadrive.appURL as long as a warm environment is still running for them. Once a Function needs to start fresh, the platform refuses by design: the request gets a terminal 410 page telling you to redeploy, instead of the invocation it would otherwise get. - Its static assets return 404. Pages that depend on scripts, styles, or images will render incomplete.
- Its build details, logs, and metadata stay visible in the Console.
Redeploying brings everything back
An expired deployment can be redeployed at any time. Redeploying rebuilds the same commit as a new deployment with a full set of assets, exactly like a rollback.
Production and branch URLs are never affected: retention explicitly skips any deployment those URLs point to, so the moving URLs described in Rollbacks always serve a complete deployment.