---
title: Containers sandbox
description: Learn more about the sandboxing environments of Scaleway Serverless Containers.
tags: containers sandbox sandboxing gvisor isolation mechanism serverless v1 v2 clock drift skew
dates:
  validation: 2025-11-18
  posted: 2025-05-07
---

In the context of Scaleway Serverless Containers, a [Sandbox environment](/serverless-containers/concepts/#sandbox) is a critical security mechanism that isolates each container from others, ensuring that they operate in a secure and controlled space. Containers run in dedicated execution environments that prevent unauthorized access and potential interference between different resources.

Scaleway Serverless Containers offers two sandbox environment options:

- Sandbox v1 (legacy)
- Sandbox v2 (recommended)

## Sandbox v1

Sandbox v1 is Serverless Containers' legacy sandboxing environment with slower [cold starts](/serverless-containers/concepts/#cold-start), but fully supports Linux system call interface.

<Message type="important">
Sandbox v1 is known to experience clock drift over time. A difference of approximately **two seconds** can be observed after 24 hours of uninterrupted execution. This issue especially affects long-running containers, whereas short-lived containers are much less impacted. Update to sandbox v2 to solve the issue.
</Message>

## Sandbox v2

Sandbox v2 is a modern isolation environment that relies on [gVisor](https://gvisor.dev/). This option offers faster [cold starts](/serverless-containers/concepts/#cold-start), but only implements a selection of Linux syscalls.

Refer to the [official gVisor documentation](https://gvisor.dev/docs/user_guide/compatibility/linux/amd64/) for a comprehensive list of supported syscalls.

## Sandbox special directories

In sandbox v1 and v2, some directories are mounted as `tmpfs` for temporary in-memory storage:

| Sandbox v1 |Sandbox v2 |
|---|---|
| /dev (max size: 65 536 KB) | /dev (no max size)|
| | /tmp (no max size) |

In Sandbox v1, the size is limited, and its impact on memory usage is negligible.

In Sandbox v2, directories such as `/tmp` and `/dev` are stored in memory. This means that any data written to `/tmp` consumes RAM directly. For example, writing a 100 MB file to `/tmp` will increase the container's memory usage by the same amount.

Since this usage counts toward the container's memory limit, excessive writes to `/tmp` can lead to out-of-memory (OOM) errors, potentially triggering a container restart.

To avoid this, we recommend being cautious when writing temporary files in `/tmp`, especially in long-running or high-throughput workloads.

Applications that rely heavily on temporary file storage should either:
- Use alternative storage paths within your container
- Increase the container's memory allocation to accommodate for temporary file usage

## Sandbox V2 subprocesses RAM usage

Sandbox v2 currently does not support copy-on-write when subprocesses are created, which means that the memory usage of a container is proportional to the number of forked subprocesses. If your application relies on multiple subprocesses that instantiate numerous objects (such as large module imports in Python), we recommend using Sandbox v1.