Suggestion: Provide configurable maintenance responses for Recreate deployments with mounted Volumes to avoid raw 502 errors during transitions
```
Our service already provides an HTTP health check endpoint, and it recovers normally after the new instance finishes starting up. However, between the time the old instance stops and the new instance passes the health check, users only see a raw 502 page generated by the platform.
In our actual deployments, this period usually lasts for several tens of seconds. For web applications, a raw 502 can easily lead users to believe that the service has suffered an unexpected failure, rather than undergoing a normal version update.
#### Desired Capabilities
We hope Zeabur can provide a configurable fallback/maintenance response during deployment for services using the Recreate strategy.
Suggested priorities:
1. When the old instance has stopped and the new instance has not yet passed the health check, Zeabur Ingress should return a configurable maintenance response instead of a raw 502.
2. Default to using the more semantically accurate `503 Service Unavailable`.
3. Support configuring `Retry-After` and `Cache-Control: no-store` response headers.
4. Support simple maintenance text, JSON, or static HTML.
5. Automatically resume normal routing after the new instance passes the health check, without requiring manual DNS or domain switching.
6. If the new deployment fails, the maintenance response can persist until a successful rollback or the next deployment recovery.
7. Support both `zeabur.app` domains and custom domains.
#### Suggested Minimum Implementation
If a full custom HTML implementation is too costly for now, we suggest starting with:
- A toggle for "Return maintenance response during Recreate deployment";
- Fixed HTTP 503 return;
- Configurable plain text or JSON;
- Automatically included `Retry-After`;
- Dashboard display indicating the service is currently undergoing a Recreate transition.
Example:
```http
HTTP/1.1 503 Service Unavailable
Retry-After: 15
Cache-Control: no-store
Content-Type: application/json
{
"status": "deploying",
"message": "Service is updating, please try again later"
}
```
This suggestion does not change the single-write constraint of Volumes, nor does it require true zero-downtime deployment. It simply aims for Zeabur to provide an accurate, controllable status to end-users when the platform already knows that the "service is performing a Recreate deployment," rather than exposing a generic `502 Bad Gateway`.
#### Actual Benefits
- Users can distinguish between normal updates and service failures;
- Front-end applications can automatically retry based on 503 and `Retry-After`;
- Reduces user refreshes, support tickets, and repetitive actions;
- Applications using SQLite, file storage, or other persistent Volumes will benefit;
- Users do not need to deploy additional Caddy, NGINX, or external load balancers just to cover the few-second deployment window.