Instance isolation overview

Choose a mode

Note: Enabling either isolation mode locks concurrency per instance to 1. For session isolation, configure session affinity first.

AI agents and multi-tenant isolation

AI agents that maintain conversation state across multiple turns need a persistent instance that belongs exclusively to one user session. Session isolation maps a session lifecycle to an instance lifecycle, so GPU-loaded models and in-memory context remain available across turns without being shared with other tenants.

Multi-tenant SaaS applications with similar requirements benefit from the same pattern: each tenant's session is isolated, preventing data leaks caused by instance reuse.

Security isolation

When processing sensitive data — encryption keys, private user data, or confidential pipeline artifacts — request isolation ensures the environment is fully reset between executions. Memory, temporary files, and any other runtime state from the previous request do not persist.

Common workloads: CI/CD pipeline builds, text-to-image generation, and any task that loads credentials into memory.

Resource release and cleanup

Functions that hold exclusive external resources (database connections, GPU devices) can rely on request or session isolation to guarantee those resources are released when the instance is recycled. This removes the need for explicit cleanup logic and reduces the risk of resource leaks.

This pattern also applies when your code uses global variables that depend on external resources. Without isolation, those variables persist across requests and can cause unexpected cross-request side effects.

Short-lived tasks with low concurrency

If a function completes in milliseconds and receives very few concurrent requests, the overhead of reusing an instance may exceed the benefit. Request isolation is a reasonable choice — for example, a one-time trigger that cleans up temporary files.

Note: For high-throughput or latency-sensitive workloads, request isolation increases cold start frequency. Evaluate the trade-off before enabling it.

Session persistence

Function Compute was originally designed for short-lived, request-triggered executions. Session isolation requires instances to remain alive between requests — a design tension the platform resolves through light hibernation (formerly called idle).

After a request ends, an elastic instance automatically transitions to light hibernation instead of being released. During light hibernation:

• vCPU usage is not billed.

• Memory billing continues unchanged.

• GPU resources are billed at 1/8 to 1/5 of the standard rate, depending on the card type.

The instance stays in light hibernation until one of two timeouts is reached: the Session idle timeout or the Session Time to Live (TTL). When either threshold is met, the session lifecycle ends and the instance is released — down to the configured minimum instance count.

If the minimum instance count is 1 or higher, the instance wakes from light hibernation when a new request or background task arrives, performs a hot start, and becomes an active elastic instance. When the request or background task ends, it transitions back to light hibernation and waits for the next timeout.

This entire transition — active → light hibernation → released — is transparent to the application. The only visible effect is billing.

Isolation guarantee

Function Compute enforces isolation by controlling concurrency:

• Request isolation: concurrency per instance is set to 1. A new instance is allocated for each incoming request.

• Session isolation: session concurrency per instance is set to 1. A session's requests are routed to the same instance, and no other session shares it.

Lifecycle mapping

A request or session lifecycle maps one-to-one to an instance lifecycle:

• The instance is allocated when the request or session starts.

• The instance is released immediately when the request ends (request isolation), or when the Session TTL or Session idle timeout is reached (session isolation).