Skip to navigationSkip to main contentSkip to footerScaleway DocsAsk our AI
Ask our AI

Functions sandbox

In the context of Scaleway Serverless Functions, a Sandbox environment 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, but fully supports Linux system call interface.

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.

Sandbox v2

Sandbox v2 is a modern isolation environment that relies on gVisor. This option offers faster cold starts, but only implements a selection of Linux syscalls. Refer to the official gVisor documentation 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 v1Sandbox 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
Still need help?

Create a support ticket
No Results