Serverless Functions and Serverless Containers share the same architecture (based on Knative). When you deploy a Function, Scaleway simply injects your code into a pre-built container image.
Migrating to Serverless Containers just means you take control of that container image creation yourself.
Before you start
To complete the actions presented below, you must have:
Understanding the differences
Scaleway Serverless Functions allow you to quickly deploy snippets of code without worrying about anything but the business logic.
- Best for: Webhooks, lightweight APIs, and glue code.
- Key benefit: "Zero config" deployment—just paste your code and go.
However, as your application grows, you face limitations regarding dependency management (e.g., needing system-level libraries like ffmpeg or specific C extensions), or complex build pipelines.
This is where Serverless Containers can be more adapted.
Moving to Containers means:
- You take control of the "wrapping": Instead of Scaleway wrapping your code, you write a Dockerfile.
- You gain flexibility: You can install any system library, use any language version, and control the exact OS environment.
- Better portability: A containerized app can run on Scaleway, your local machine, or any other cloud provider without changing the code.
When to migrate to Serverless Containers?
While Functions are excellent for "zero-config" deployments, Serverless Containers are the recommended choice when your project requirements expand.
Consider migrating if:
-
You need custom system dependencies: Functions run in a managed environment. If your code requires specific system libraries (e.g.,
ffmpeg,ImageMagick, custom C-bindings) that are not present in the standard runtime, containers allow you to install them via the Dockerfile. -
You need full portability: A Docker container is the industry standard for shipping code. By containerizing your application, you ensure it can run anywhere: on your local machine, on various Scaleway products, on Kubernetes clusters, or any other cloud provider, without changing a single line of code.
-
You need a specific language version: Serverless Functions support a specific list of runtimes (e.g., Node 22, Python 3.13). If you need an older version, a beta version, or a completely different language (like Java, Ruby, or .NET), Serverless Containers are the solution.
-
You have a complex build pipeline: If your application requires a compilation step, complex asset building, or private package managers, defining these steps in a
Dockerfilegives you granular control over the build process.
Containerize your Serverless Function
The main step in migrating is creating a Dockerfile that replicates the runtime environment your function was using.
Below are standard Dockerfile templates for the main Serverless Functions runtimes. You can add this file to the root of your project (where your handler or index file is located).
Build and push the image
Once your Dockerfile is ready, you need to build the image and push it to your Scaleway Container Registry.
- Log in to your registry:
docker login rg.fr-par.scw.cloud/your-namespace -u nologin --password-stdin <<< "$SCW_SECRET_KEY" - Build the image:
docker build -t my-migrated-function:latest . - Tag and push the image:
docker tag my-migrated-function:latest rg.fr-par.scw.cloud/your-namespace/my-migrated-function:latest docker push
Refer to the dedicated documentation for more information on how to build and push images to the Scaleway Container Registry.
Deploy to Serverless Containers
- Navigate to Serverless Containers in the Scaleway console.
- Click Deploy container.
- Select Scaleway Container Registry and choose the image you just pushed (
my-migrated-function). - Set the Port to
8080(or match thePORTenvironment variable in your Dockerfile). - Set the same resources (vCPU/RAM) and scaling parameters (min/max scale) as your original function.
- Click Deploy.
Your code is now running as a Serverless Container, giving you the freedom to modify the OS, install binaries, and manage complex dependencies exactly as you need.
Additional content
For advanced usage, such as larger projects with dependencies, automation, and more, check out our GitHub repository for more examples.