All Products
Search

This Product

    Serverless App Engine:Canary release for an application

    Document Center

    Serverless App Engine:Canary release for an application

    Last Updated:Jul 17, 2026

    Configure a canary release to gradually roll out a new application version, and roll back if issues arise.

    Prerequisites

    The application has more than one instance.

    Background information

    A canary release allows you to deploy a new version of your application alongside the existing version. This strategy lets you test the new version's performance with a small subset of traffic, helping you identify and fix issues early while maintaining overall system stability.

    During a canary release, the canary batch cannot exceed 50% of the total instance count to ensure stability. The remaining instances are deployed in subsequent batches. After the first batch is released, you can manually decide whether to proceed with the next batch, allowing you to gather feedback and monitor performance before a full rollout.

    A canary release uses one of two main approaches:

    • Traffic splitting: Route a percentage of traffic to the new version. For example, send 20% of traffic to the new version and 80% to the old version.

    • Content-based routing: Route traffic based on request attributes, such as headers or user IDs. For example, direct requests from specific users to the new version.

    Compared to a phased release, a canary release offers more granular control over traffic. For more information about phased releases, see Perform a phased release for an application.

    Example scenario

    An application has 10 instances running Version 1 (Ver.1). You need to upgrade all instances to Version 2 (Ver.2). In this scenario, you first perform a canary release on 2 instances, and then deploy the remaining 8 instances in 3 batches. The following diagram illustrates this process.

    image

    Procedure

    Warning

    After you redeploy an application, the application is restarted. To prevent unpredictable errors such as business interruptions, we recommend that you deploy applications during off-peak hours.

    1. On the SAE Application List page, select a region and namespace at the top, and click the ID of the target application to open the application details page.

    2. On the target application's Basic Information page, click Deploy Application.

    3. Configure deployment parameters.

      Note

      The deployment method of an application is based on the deployment method that you selected for the application for the first time. Configure the parameters based on the selected method.

      • Deployment with WAR Packages: Upload another WAR package or enter the path of a newly deployed WAR package, and configure the runtime environment and other settings.

      • Deployment with JAR Packages: Upload another JAR package or enter the path of a newly deployed JAR package, and configure the runtime environment and other settings.

      • Deployment with ZIP Packages: Upload another ZIP package or enter the path of a newly deployed ZIP package, and configure the runtime environment and other settings.

      • Image: In the Configure Image section, click Modify Image. In the Modify Image panel, select another image repository or image version.

    4. In the Release Policy Settings section, configure the canary release.

      Parameter

      Description

      Release Policy

      Select Canary Release (Phased).

      Instances for Canary Release

      Specify the number of instances to include in the initial canary batch.

      Remaining Batches After Canary Release

      After the canary release, the remaining instances are deployed across the specified number of batches.

      Peak Volume

      Corresponds to the Kubernetes MaxSurge parameter: the maximum number of instances that can be created beyond the desired count during an update.

      Important

      This feature is in invitational preview. To request access, contact our team in the DingTalk group (ID: 32874633).

      Note

      • If Minimum Available Instances is set to 100% (meaning MaxUnavailable is 0), Peak Volume cannot be 0.

      • If you use a percentage, the value is rounded up. For example, if you have 5 instances and set this to 25%, the Peak Volume value is 2.

      Minimum Available Instances

      The minimum number of instances that must remain available during a rolling update.

      Note

      • We recommend setting Minimum Available Instances to 1 or higher to ensure business continuity. If set to 0, the application will be interrupted during the upgrade.

      • If you use a percentage, the value is rounded up. For example, if you have 5 instances and set this to 25%, the number of Minimum Available Instances is 2.

      Enable Layer 7 traffic canary release rule (Kubernetes Ingress)

      Takes effect only after you create a canary release rule for Layer 7 traffic (Kubernetes Ingress).

      Enable Canary Release Rule of Microservices (Spring Cloud and Dubbo Applications)

      Takes effect only after you create a canary release rule for microservices traffic.

    5. After you complete the configuration, click OK.

    6. Verify the deployment in one of the following ways:

      • Method 1: On the application's Change Records page, view the change details and release status. If all batches complete successfully, the application update is complete.

      • Method 2: On the Instances tab of the application's Basic Information page, check the instance status. If the Status is Running, the application is deployed successfully.

    Application rollback

    When you upgrade an application by using a canary release or phased release, the application's status remains Executing until all instances are upgraded.

    If the first batch of instances stops responding due to an unexpected issue during the upgrade, go to the Change Details page and click Roll Back Now. This reverts the upgraded instances to the previous version and restores their original configurations.

    If an exception occurs during the change process, such as an unavailable deployment package or a failed health check, the upgrade will fail. SAE automatically stops the process and initiates an application rollback.

    An application upgrade in SAE times out after approximately 30 minutes. If this happens, SAE reports a timeout exception and pauses the change process. You must then go to the Change Details page to manually abort the release and roll back the application.

    Abort a release

    To stop a release that is in progress, click Stop Deployment on the Change Details page.

    Important

    Aborting a release may result in multiple versions of your application running simultaneously:

    • Instances that are already deployed: Will continue to run in their current state and will not be rolled back.

    • Instances being deployed: These instances will finish deploying and then run on the new version from this release.

    • Instances that are not yet deployed (including all instances in subsequent batches): Will remain in their current state, and the release process is halted for them.

    • New instances from auto scaling: Will use the new version for scale-out events.

    After aborting, we recommend that you either redeploy the application or roll back to a previous version as soon as possible to ensure all instances are running the same version.

    More information

    After deploying an application in SAE, you can perform the following operations.

    Actions

    Related documentation

    Manage the application lifecycle, such as updating, scaling, starting, stopping, or deleting the application.

    Manage the lifecycle of an application

    Optimize application performance by configuring auto scaling, binding a Server Load Balancer (SLB) instance, or creating scheduled start and stop rules.

    Monitor application status by managing logs, viewing monitoring data, checking events, and reviewing change records.