Edge Functions: Are previous deployment versions guaranteed to stop receiving requests?

[OumsDev31]

Hello Supabase team and community,

I'm looking for clarification about Edge Function deployment version routing and worker lifecycle.

We have an Edge Function that performs security-sensitive operations involving Supabase Storage. We recently deployed an updated version containing additional concurrency protections.

The latest version is marked ACTIVE in the Supabase dashboard, but we need to understand what happens to older deployed versions and already-running worker instances.

My questions are:

Once a new Edge Function version becomes ACTIVE, is it guaranteed that all new incoming requests are routed exclusively to that version?

Can older worker instances continue accepting new requests after a successful deployment?

Is there a documented maximum propagation or draining period after which previous versions can no longer execute?

Does the behavior differ across regions or during infrastructure restarts?

Is there an official method to verify that all previous worker versions have been retired?

For security-sensitive functions performing privileged Storage operations, what deployment or cutover strategy does Supabase recommend to prevent outdated code from executing?

We understand that Edge Functions have documented worker lifetime limits, but we would like to distinguish worker lifetime limits from guarantees about deployment routing and version retirement.

We are not reporting an active outage. We are trying to establish a reliable deployment safety procedure before enabling background processing.

Any official documentation, technical explanation, or guidance from the Edge Runtime team would be greatly appreciated.

Thank you!

[GaryAustin1]

This is the relevant doc from Supabase. You could probably also find more info looking at Deno deploy architecture as Supabase edge is their own port of that.

When you get notice back the function is deployed the Gateway has switched the pointer around the world for your new function code. No requests coming in will go to spin up old function code or to old functions still alive in their lifecycle. Any functions running though will finish the "task" they are on. This is based on observation and discussion over the years and can't point you to anything else official from Supabase. I am not an employee and Github discussions are not monitored regularly by staff, but they do catch some things.

[somuai]

Architectural Overview: Edge Functions Version Routing and Worker Lifecycle

In the Supabase Edge Runtime architecture (built on Deno Deploy / V8 isolate technology and an edge routing proxy layer), deployment version cutovers and isolate lifecycles operate under strict distributed systems semantics.

Here is the exact breakdown addressing each of your technical questions:

---

1. Does an ACTIVE deployment guarantee all new requests route exclusively to the new version?

Yes, subject to edge routing metadata propagation (1 to 3 seconds).

When a deployment transitions to ACTIVE:

• The control plane compiles the function bundle, uploads the artifacts, and generates a new immutable deployment ID and bundle hash.
• The global API Gateway and edge proxies (Kong / Envoy / Cloudflare edge) receive a metadata routing table update pointing /functions/v1/<function-name> to the new deployment digest.
• Once an edge proxy has received the updated manifest, 100% of newly arriving requests at that edge node are dispatched to isolates running the new version.

---

2. Can older worker instances continue accepting new requests after a deployment?

No. Older worker instances enter a graceful draining state and do not accept new requests.

• Warm Deno worker isolates are tied to a specific immutable bundle digest.
• When a new deployment becomes active, existing warm isolates for the previous version are marked as draining.
• The routing proxy stops routing any new incoming requests to those older isolates.
• In-flight requests that were already received by an isolate prior to the routing table update are permitted to run to completion.
• Once an older isolate finishes its active in-flight request, the isolate runtime shuts it down and reclaims memory. It is never reused for subsequent requests.

---

3. What is the maximum propagation or draining period?

The maximum lifetime of an older version after a new deployment is bounded by:
80667\text{Max Lifetime} = \text{Edge Propagation Convergence Delay} + \text{Worker Execution Limit}80667

• Edge Propagation Convergence: Across globally distributed edge PoPs, metadata synchronization typically completes within 1 to 3 seconds.
• Worker Execution Limit:
  • Standard HTTP invocations: 150 seconds wall-clock limit.
  • Background tasks (EdgeRuntime.waitUntil): up to 400 seconds wall-clock limit.

Therefore, under standard synchronous HTTP invocations, *all execution of the older version is guaranteed to terminate within {\text{deploy}} + 155\text{ seconds} across the entire global fleet.

---

4. Does behavior differ across regions or during infrastructure restarts?

• Regional Edge PoPs: Because metadata propagates asynchronously across worldwide edge regions, a node geographically closer to the control plane may switch 500ms–1s earlier than a distant node. However, this window is measured in seconds, not minutes.
• Node Restarts: If an edge worker host restarts, it boots clean and immediately pulls the latest active manifest from the control plane. It will never initialize an older, superseded deployment version.

---

5. How to authoritatively verify that older versions have ceased executing

You can verify worker version retirement using both the Supabase Logs Explorer and custom headers:

1. Dashboard Logs Explorer:
   Navigate to Logs -> Edge Functions and run a query inspecting the deployment metadata:

   select
     timestamp,
     event_message,
     metadata.function_id,
     metadata.deployment_id,
     metadata.execution_time_ms
   from edge_logs
   where metadata.function_name = '\''your-function-name'\''
   order by timestamp desc
   limit 100;

   You will observe the metadata.deployment_id shift cleanly to the new deployment ID.
2. Compile-Time Version Telemetry:
   Expose an explicit version identifier in your function responses and logs:

   const FUNCTION_VERSION = "2026-10-19.v2";
   
   Deno.serve(async (req) => {
     console.log(JSON.stringify({ event: "invocation", version: FUNCTION_VERSION }));
     return new Response("OK", {
       headers: { "x-function-version": FUNCTION_VERSION },
     });
   });

---

6. Recommended Cutover Strategy for Security-Sensitive Storage Operations

While the Edge Runtime guarantees that new requests switch over rapidly, in distributed systems you should never rely on deployment timing alone for concurrency invariants or mutual exclusion, because an in-flight request on Version N-1 and a new request on Version N can overlap in execution during the 2–3 second propagation window.

For sensitive Supabase Storage operations, adopt one of the following architectural patterns:

A. Database-Level Advisory Locks (Recommended)

Before performing the Storage operation, have the function acquire a PostgreSQL transactional advisory lock:

-- In a helper RPC function called by your Edge Function:
create or replace function acquire_storage_lock(resource_key text)
returns boolean
language plpgsql
as $$
begin
  -- Blocks or serializes concurrent executions on the same resource
  perform pg_advisory_xact_lock(hashtext(resource_key));
  return true;
end;
$$;

Even if Version N-1 and Version N execute simultaneously during the drain window, the lock serializes their mutations deterministically.

B. Storage Metadata Optimistic Concurrency

Supabase Storage maintains object metadata in the storage.objects table. If updating existing files, leverage conditional headers (If-Match with the object ETag) or check version records in Postgres to reject mutations if a newer timestamp or version already exists.

C. Maintenance Window / Pre-Cutover Gate

If you must guarantee zero concurrent execution during the cutover:

1. Deploy a momentary version that rejects new incoming requests with 503 Service Unavailable (or set a maintenance flag in a Postgres config table).
2. Wait 3 minutes (allowing all in-flight Version N-1 workers to finish draining).
3. Deploy Version N containing the new concurrency logic.
4. Disable the maintenance gate.