---
title: Containers limitations
description: Learn about the limitations of Scaleway Serverless Containers.
tags: containers limitations serverless
dates:
validation: 2025-09-17
posted: 2021-10-12
---
This section contains usage limits that apply when using Serverless Containers.
| Resources | Criteria | Limits | Scope |
|---------------------------------------------------|------------- |------------------ |-----------------------------|
| Namespaces | Max number | 100* | Project |
| Containers | Max number | 1000* | Organization |
| Total container memory\** | Max size | 600 GiB | Organization |
| Custom domains | Max number | 50 | Container |
| Recommended maximum uncompressed image size | Max size | 1 GB | Container |
| Temporary disk size | Max size | 24 000 MiB | Container |
| Invocation rate | Max number | 5000 per second | Container |
| Concurrency | Max | 80 | Container Instance |
| Max Scale (simultaneous Container instances) | Max | 50 | Container |
| CPU | Min/max | 70 to 6000 mvCPU | Container |
| Memory | Min/Max | 128 to 12228 MB | Container |
| Environment variables | Max number | 200 | Container + namespace |
| Environment variables | Max size | 65536 chars | Environment variable |
| Secret environment variables | Max number | 200 | Container + namespace |
| Secret environment variables | Max size | 65536 bytes | Secret environment variable |
| Time before scale to zero | Time | 15 minutes | Instance |
| Time before scale down | Time | 30 seconds | Instance |
| HTTP request duration (timeout)\*** | Min/max | 10 seconds to 60 minutes | Request |
| Private Networks attached | Max | 1 | Container |
| Logs | Logs | 30000 per minute | Project |
\* Lower limits may apply before account verification. Contact our Support team if you have any questions.
\** Total container memory is the sum of the memory allocated to all your containers at their maximum Scale.
\*** Use [Serverless Jobs](/serverless-jobs/) for tasks up to 24h.
These limits are enforced as [Organization quotas](/organizations-and-projects/additional-content/organization-quotas/#serverless-containers).
During the execution of the container, if the limits are exceeded, a restart occurs.
## Image size
We recommend keeping your image size **below 1 GB** to ensure faster deployment and better cold start performance.
### 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. Examples:
```dockerfile
# Build stage
FROM node:22-alpine AS builder
WORKDIR /app
# Copy package files
COPY package*.json ./
# Install dependencies
RUN npm ci --only=production
# Copy source code
COPY . .
# Runtime stage
FROM node:22-alpine
WORKDIR /app
# Copy built artifacts from builder
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app .
# Expose the port the app listens on
ENV PORT=8080
# Start the application
CMD ["node", "index.js"]
```
```dockerfile
# Build stage
FROM golang:1.23-alpine AS builder
WORKDIR /app
# Copy Go module files
COPY go.mod go.sum ./
# Download dependencies
RUN go mod download
# Copy source code
COPY . .
# Build the binary
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main .
# Runtime stage
FROM scratch
WORKDIR /app
# Copy the binary from builder
COPY --from=builder /app/main .
# Expose the port the app listens on
ENV PORT=8080
# Run the binary
CMD ["./main"]
```
```dockerfile
# Build stage
FROM python:3.13-slim AS builder
WORKDIR /app
# Install build dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
gcc \
&& rm -rf /var/lib/apt/lists/*
# Copy requirements and install dependencies
COPY requirements.txt .
RUN pip install --no-cache-dir --user -r requirements.txt
# Runtime stage
FROM python:3.13-slim
WORKDIR /app
# Copy installed packages from builder
COPY --from=builder /root/.local /root/.local
COPY . .
# Make sure scripts in .local are usable
ENV PATH=/root/.local/bin:$PATH
# Expose the port the app listens on
ENV PORT=8080
# Run the application
CMD ["python", "app.py"]
```
```dockerfile
# Build stage
FROM rust:1.94-alpine AS builder
WORKDIR /app
# Copy Cargo configuration
COPY Cargo.toml Cargo.lock ./
# Create a minimal src directory to cache dependencies
RUN mkdir src && \
echo "fn main() {}" > src/main.rs && \
cargo build --release && \
rm -rf src
# Copy the actual source code
COPY src ./src
# Build the application
RUN cargo build --release
# Runtime stage
FROM scratch
WORKDIR /app
# Copy the compiled binary from the builder stage
COPY --from=builder /app/target/release/my-app .
# Expose the port the app listens on
ENV PORT=8080
# Run the binary
CMD ["./my-app"]
```
## Configuration Restrictions
In order to ensure the proper functioning of the product, we restrict the use of certain ports and environment variables
### Blocked ports
Due to potential abuse (spam), no outbound traffic is allowed through the following ports, except from Scaleway Transactional Email SMTP servers.
* **25**
* **465**
### Unavailable custom ports
Do not have your containers listen on these ports, as they are used by our service.
* 8008
* 8012
* 8013
* 8022
* 8112
* 9090
* 9091
### Reserved environment variables
* `PORT`: Value of the port defined in the Container settings, which the container has to listen on. You can use this environment variable inside your Container for easier deployments.
* `SCW_*`: Reserved for product configuration (for example: token validation)
### 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.
### Protocols
Serverless Containers support HTTP/1.1 and HTTP/2 connections. HTTP/1.0 is not supported. Refer to the [dedicated troubleshooting page](/serverless-containers/troubleshooting/http1-errors/) for more information on how to solve HTTP/1.0 issues.
## Private Networks and Virtual Private Cloud (VPC)
Refer to the [dedicated documentation](/serverless-containers/reference-content/containers-private-networks/) on VPC and Serverless Containers integration for more information.
## Default values for CPU and memory limits
When container CPU and/or memory are not provided by the client, these default values are automatically used:
| Resources | Default value |
|-----------|----------------|
| CPU | 1000 mvCPU |
| Memory | 2048 MB |
## Architecture
Image target platform must be: `linux/amd64`.
Images with a different platform will generate an error when deploying the container.
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.
## Versioning and rollback
Scaleway Containers do not currently support versioning or automatic rollback mechanisms.
However, in the event of a failed deployment, the previously deployed version of the container will continue to handle
incoming requests for up to 24 hours. After this period, the container in error will be deleted, and requests will no
longer be served until a successful deployment is made. This ensures temporary service continuity, but it is important
to monitor and resolve deployment issues promptly, as the fallback is not intended to provide long-term version control
or rollback capabilities.
Below is an example than illustrates this behavior:
* Time +0H: The first container is deployed and works correctly.
* Time +1H: The container is redeployed, but the deployment fails, and the container ends up in an error state.
* Time +2H: Despite the failed deployment, the first container is still handling incoming requests.
* Time +25H: The 24-hour window expires, and both the first working container and the failed container are removed,
leading to service disruption until a new successful deployment is made.
## Containers sandbox
Refer to the [dedicated documentation](/serverless-containers/reference-content/containers-sandbox/) for more information on the limitations of sandbox environments for Serverless Containers.