---
title: Functions sandbox
description: Learn more about the sandboxing environments of Scaleway Serverless Functions.
tags: functions sandbox sandboxing gvisor isolation mechanism serverless v1 v2 clock drift skew
dates:
  validation: 2025-09-25
  posted: 2021-10-12
---

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

Scaleway Serverless Functions offers two sandbox environment options:

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

## Sandbox v1

Sandbox v1 is Serverless Functions' legacy sandboxing environment with slower [cold starts](/serverless-functions/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 functions, whereas short-lived functions 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-functions/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 function's memory usage by the same amount.

Since this usage counts toward the function's memory limit, excessive writes to `/tmp` can lead to out-of-memory (OOM) errors, potentially triggering a function 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 function
- Increase the function'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 function 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.