Upsun starts a temporary container running a cloned version of your app. The cloned app begins handling all live traffic during this time. Your services (for example Redis) will serve the cloned app as well as the original app.
### 2. Upgrade the original
While traffic is being served by the clone, the original application gets upgraded with your new code, configuration, or environment changes.
### 3. Switch back and cleanup
Once the original is fully upgraded and healthy, traffic switches back to the original application. The temporary clone is then removed.
When deployment is complete, the clone of your app is shut down and removed. All traffic and services are now solely applied to the original app alone.
This ensures that your application is available throughout the entire deployment process—users never experience downtime.
## Important considerations
### Applications only
This feature applies to **applications**, not services. Services like databases, Redis, or other data storage systems stay intact and uninterrupted throughout the deployment. To upgrade services, you need to restart the application.
### Temporary resource increase
During the zero-downtime deployment, both the original and cloned applications run simultaneously for a brief period. This means:
* You'll temporarily use more resources while both versions are active
* Additional costs during this time are proportional to your application's resource usage and deployment duration
* The impact is minimal for typical deployments, especially for smaller applications
### Connection handling
Long-lived connections like WebSockets or Server-Sent Events (SSE) are dropped during any deployment. We recommend implementing reconnection logic in your applications.
To ensure your application only starts receiving traffic when it's steady and ready, we recommend using the `post_start` hook. This helps prevent 502 errors that can occur if traffic is routed to your application before it's fully initialized. For more information, see the [application startup documentation](https://docs.upsun.com/learn/overview/build-deploy.html#application-is-slow-to-start).
## How to try it
Zero-downtime deployments are available on **Upsun Flex**.
### Recommended: Enable manual deployments
The recommended way to use zero-downtime deployments is to enable **manual deployments** on your environment. This gives you full control over when and how deployments happen.
Once enabled, you can trigger deployments via the CLI:
```bash theme={null}
upsun environment:deploy --strategy rolling
```
Or via the Console: navigate to your environment settings and trigger a deployment from the deployment modal. Select **Zero Downtime** as your deployment strategy.
### Alternative: Using CLI push
If you don't want to enable manual deployments, you can use the latest CLI to deploy directly with zero-downtime strategy:
```bash theme={null}
upsun push --deploy-strategy=rolling
```
## Use cases
Zero-downtime deployments are ideal for:
* **Code pushes**: Deploy new features or bug fixes without service interruption
* **Configuration changes**: Update environment variables or application settings
* **High-traffic applications**: Keep critical services available during updates
**Not recommended for:**
* Database schema migrations (except when fully backward and forward compatible)
* Stateful service updates
## Need help?
If you encounter any issues or have questions about zero-downtime deployments, please raise a support ticket.
## Learn more
For more details on zero-downtime deployments, including troubleshooting and best practices, check out our [documentation](https://docs.upsun.com/learn/overview/build-deploy.html#zero-downtime-deployments).
Deploy with confidence!