---
title: Jobs limitations
description: Learn the limitations of Scaleway Serverless Jobs.
tags: jobs limitations serverless
dates:
  validation: 2025-10-23
  posted: 2021-03-28
---

This section contains usage limits that apply when using Serverless Jobs.

## Jobs resource limitations

|           Resource            |      Limit       |     Scope      |
| ----------------------------- | ---------------- | -------------- |
| Max number of job definitions | 1000             | Organization   |
| Max parallel jobs             | 400              | Organization   |
| Logs                          | 30000 per minute | Project        |
| Secret references             | 20               | Job definition |
| Max ephemeral storage         | 10 GB            | Job run        |
| Max CPU                       | 6 vCPU           | Job run        |
| Max memory                    | 16 GB            | Job run        |
| Timeout                       | 24h              | Job run        |
| Job runs history              | 60 days          | Job run        |



## Default values for CPU and memory limits

When the job vCPU and/or memory are not provided by the client, these default values are automatically used:

| Resources | Default value  |
|-----------|----------------|
| CPU       | 1120 mvCPU     |
| Memory    | 2048 MB        |

## Architecture

Image target platform must be: `linux/amd64`.

<Message type="note">
    Images with a different platform will generate an error when running the job.
</Message>

For example, if you build an image using an ARM CPU, such as Apple silicon M series, your image will be in the `arm64` architecture, and you will have an error message during deployment.

You must ensure that you build your image to target `amd64` architecture, to achieve this there are multiple solutions:
* You can use the following docker command: `docker build --platform linux/amd64 .`, or
* You can use an Instance with `amd64` architecture to run your builds.

## Environment variables restrictions

In order to ensure the proper functioning of the product, we restrict the use of certain environment variables:
* It is not possible to use an environment variable key that starts with `SCW_SLS`, regardless of case.
* It is not possible to use a secret reference if its name starts with `SCW_SLS`, regardless of case.

## Ports restrictions

In order to ensure the proper functioning of the product, we restrict the use of certain ports:
* **25**: Due to potential abuse (spam), no outbound traffic is allowed through this port, except from Scaleway Transactional Email SMTP servers.
* **465**: Due to potential abuse (spam), no outbound traffic is allowed through this port, except from Scaleway Transactional Email SMTP servers.

### Dedicated IP

**Not available:** Serverless products are designed to abstract away infrastructure management, to be easily scalable, and to be cost-efficient and simple. So dedicated IPs are not supported for this product.

## Private Network and Virtual Private Cloud (VPC) compatibility

See the [FAQ](/serverless-jobs/faq/#how-can-i-configure-access-to-a-private-network-or-virtual-private-cloud-vpc) for more information on Serverless Jobs compatibility with Private Networks and [Virtual Private Cloud (VPC)](/vpc/).

## Image size

We recommend keeping your image size **below 2 GB** to ensure faster deployment.

### Tips for keeping image size down

* Use lightweight distribution like *Alpine*
* Minimize layers and unnecessary dependencies
* Clean up temp files and cache (e.g., `rm -rf /var/lib/apt/lists/*` in Debian-based images)
* Use multi-stage builds to keep only runtime essentials. [Example](https://github.com/scaleway/serverless-examples/blob/a7a3b5fc3427ec0f1391aaa78957f91af266867c/containers/rust-hello-world/Dockerfile#L14)

## gVisor sandbox limitation

Jobs uses [gVisor](https://gvisor.dev/) as a sandboxing solution to isolate the underlying client containers mutualized on the same host. Directories such as `/tmp` and `/dev` are stored in memory. This means that any data written to `/tmp` consumes memory directly. For example, writing a 100 MB file to `/tmp` will increase the container memory usage by the same amount.

Since this usage counts toward the job 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.

Jobs that rely heavily on temporary in-memory storage should use one of the following solutions:
- Use alternative storage paths within the job file system.
- Increase the job memory limit if it is necessary to use the temporary in-memory storage on the client side.

## Jobs security limitations

The underlying container of a job runs as root by default but has:

- Privilege mode disabled;
- Privilege escalation disabled;
- All root capabilities dropped.