From 3cd302732b70e04b51b40a82e32e27e3613f8fc3 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Thu, 23 Jul 2026 10:22:22 -0400 Subject: [PATCH 1/3] Create rolling-releases --- serverless/endpoints/rolling-releases | 46 +++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 serverless/endpoints/rolling-releases diff --git a/serverless/endpoints/rolling-releases b/serverless/endpoints/rolling-releases new file mode 100644 index 00000000..cdbc3091 --- /dev/null +++ b/serverless/endpoints/rolling-releases @@ -0,0 +1,46 @@ +--- +title: "Rolling releases" +sidebarTitle: "Rolling releases" +description: "How Runpod deploys endpoint updates without taking your endpoint offline." +--- + +When you update an endpoint's Docker image or configuration, Runpod deploys the change as a rolling release. Workers are replaced progressively rather than all at once, so your endpoint continues to handle requests throughout the update. + +## When a rolling release happens + +A rolling release starts automatically whenever you save a change to an endpoint that has active workers. This includes: + +- Updating the Docker image (for example, pushing a new image version and saving the endpoint) +- Changing any endpoint configuration setting that requires workers to restart + +## How it works + +When a rolling release starts, Runpod distinguishes between idle workers and workers that are actively processing a job. + +**Idle workers** (not currently processing a job) on the old version are terminated immediately and replaced with new workers running the updated image. + +**Running workers** (actively processing a job) are allowed to finish their current job. Once the job completes, the worker is replaced with a new one on the updated image. + +During the rollout, your endpoint continues to accept and process requests. New requests are routed to workers on the updated image when available. + +## Best practices + +**Use versioned image tags, not `:latest`.** If you deploy with `:latest`, Runpod may serve the cached version on existing workers rather than your updated image. Workers only pick up a new image when they are replaced. Using an explicit version tag (for example, `v1.2.0` or a SHA digest) ensures a clean rollout. + +```sh +# Tag with a version +docker build -t yourusername/your-worker:v1.2.0 . +docker push yourusername/your-worker:v1.2.0 +``` + +Then update your endpoint to reference the new tag. This triggers a rolling release and guarantees all new workers use the correct image. + +**Expect a short overlap period.** During a rolling release, some workers run the old image and some run the new one. If your update changes request or response behavior in a breaking way, plan for this transition. For strict version consistency, scale your endpoint to zero workers before updating and then scale back up. + + +To scale an endpoint to zero workers before updating, set **Max workers** to 0, wait for all running jobs to complete and workers to terminate, then update the image and restore your max workers setting. + + +## Checking rollout status + +You can monitor which workers are running during a rollout from the **Workers** tab on your endpoint's detail page in the Runpod console. Workers on the previous image version will show as terminating as they finish their jobs and are replaced. From 63148f20ef8e8f425230dd5981eabb777b7180fc Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Thu, 23 Jul 2026 10:23:40 -0400 Subject: [PATCH 2/3] Update docs.json --- docs.json | 1 + 1 file changed, 1 insertion(+) diff --git a/docs.json b/docs.json index da60be34..cda9c2d5 100644 --- a/docs.json +++ b/docs.json @@ -134,6 +134,7 @@ "serverless/endpoints/send-requests", "serverless/endpoints/operation-reference", "serverless/endpoints/endpoint-configurations", + "serverless/endpoints/rolling-releases", "serverless/endpoints/model-caching", "serverless/development/optimization" ] From e24acc2d46237133faf7aff3f5927383aa1dcbd9 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Thu, 23 Jul 2026 10:27:42 -0400 Subject: [PATCH 3/3] Rename rolling-releases to rolling-releases.mdx --- serverless/endpoints/{rolling-releases => rolling-releases.mdx} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename serverless/endpoints/{rolling-releases => rolling-releases.mdx} (100%) diff --git a/serverless/endpoints/rolling-releases b/serverless/endpoints/rolling-releases.mdx similarity index 100% rename from serverless/endpoints/rolling-releases rename to serverless/endpoints/rolling-releases.mdx