Containers limitations
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 |
| Image size compressed | Max size | 250 MiB | Container |
| Image size uncompressed | Max size | 1 GiB | Container |
| Temporary disk size | Max size | 1024 MiB | Container |
| Invocation rate | Max number | 1000 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 | 100 | Container + namespace |
| Environment variables | Max size | 1000 chars | Environment variable |
| Secret environment variables | Max number | 100 | 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 |
| Timeout*** | Max | 15 minutes | Request |
| 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 for longer tasks.
These limits are enforced as Organization quotas.
During the execution of the container, if the limits are exceeded, a restart occurs.
Configuration Restrictions
In order to ensure the proper functioning of the product, we restrict the use of certain ports and environment variables
- Blocked 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.
- Unavailable custom ports
Do not make your containers listen on these ports which are used by our service.
- 8008
- 8012
- 8013
- 8022
- 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)
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
Scaleway Containers only supports amd64 architecture for
images.
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 acheive this there are multiple solutions:
- You can use the following Docker command:
docker buildx build --platform linux/amd64 ., or - You can use an Instance with
amd64architecture 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.