Scaleway DocumentationComputeContainersAPI/CLI
Uploading with the framework

Jump toUpdate content

Uploading your container using the framework

The Scaleway functions plugin for Serverless Framework allows users to deploy their functions and containers to Scaleway Containers with a simple serverless deploy.

Serverless Framework handles everything from creating namespaces to container deployment by calling APIs endpoint under the hood.


Creating a project folder

  1. Create the following directory: ~/my-srvless-projects. Then, change into it.

    mkdir ~/my-srvless-projects
    cd ~/my-srvless-projects
  2. Create a simple docker template by running:

    serverless create --template-url --path myService

    You can find other Scaleway templates on our Github.

Editing the serverless.yml file


Do not edit the and plugins parameters, as these allow you to use the Scaleway provider.

The serverless.yml file determines the configuration of a namespace that contains one or more containers with the same runtime. In the following example, we use one container and a python3 runtime.

service: scaleway-function
configValidationMode: off
name: scaleway
runtime: python3, node10, node14, golang
# Global Environment variables - used in every containers in the namespace
test: test
# the path to the credentials file needs to be absolute
scwToken: <scw-token>
scwProject: <scw-project-id>

- serverless-scaleway-functions

- '!node_modules/**'
- '!.gitignore'
- '!.git/**'

directory: my-container-directory
minScale: 0
maxScale: 20
memoryLimit: 128
# Local environment variables - used only in given container
example: example
- schedule:
rate: '1 * * * *'
myInput: myValue
mySecondInput: 1

The different parameters available are:

  • service: your namespace name
  • provider.env: the environment variables attached to your namespace are injected into all your namespace containers
  • scwToken: the Scaleway token you got in prerequisites
  • scwProject: the Scaleway Project ID
  • package.patterns: usually, this parameter does not need to be configured. It allows you to include or exclude directories from the deployment
  • custom:
    • containers: Configuration of your containers. It is a yml dictionary, with the key being the containers’ name
    • directory (Required): directory which contains your Dockerfile and scripts
    • env (Optional): environment variables specifics for the current container
    • minScale (Optional): number of running container instances continuously (default: 0)
    • maxScale (Optional): maximum number of instances this container can scale to (default: 20)
    • memoryLimit: the RAM allocated to the container instances.
    • events (Optional): List of events that trigger your containers (e.g, trigger a container based on a schedule with CRONJobs).

Configuring your Container

List your containers under the custom.containers parameter in your serverless.yml manifest. Specify the relative path of the application directory (containing the Dockerfile, and all files related to the application to deploy) of each container:

directory: my-container-directory
# Environment only available in this container
MY_VARIABLE: "my-value"

The directory that contains your Dockerfile and scripts is called my-container-directory. See other files that should be included below:

├── my-container-directory
│ ├── Dockerfile
│ ├── requirements.txt
│ ├──
│ └── (...)
├── node_modules
│ ├── serverless-scaleway-functions
│ └── (...)
├── package-lock.json
├── package.json
└── serverless.yml

Scaleway’s platform will automatically inject a PORT environment variable on which your server should be listening for incoming traffic. By default, this PORT is 8080 and it can not be changed for now.

Configuring events

With events, you may link your containers to specific triggers. For the moment, the feature is limited to CRON Schedule (time-based).


We do not include HTTP triggers in our event types, as an HTTP endpoint is created for every container. Triggers are just another way to trigger your Containers, but you will always be able to execute your code via HTTP.

Below is a list of supported triggers for Scaleway Serverless, and the configuration parameters required to deploy them:

  • schedule: Triggers your container based on CRON schedules
  • rate: the CRON Schedule (UNIX Format) on which your containers will be executed
  • input: key-value mapping to define arguments that will be passed to your container’s event object during execution.

To link a Trigger to your container, you can define an events key in your container:

directory: my-directory
# Events key
- schedule:
rate: '1 * * * *'
key: value
key2: value2

You can find other examples of trigger configurations on the Scaleway Serverless Github page

Accessing Logs

The serverless logs command allows you to watch the logs of a specific container. Add the --function option and the container’s name to the serverless logs command to fetch the logs of a specific container.

serverless logs --function <container_name>

Deleting a project

To remove a project run the following command:

serverless remove

This removes all your containers, as well as your Scaleway Containers’ namespace.


Your Scaleway Container Registry namespace is not automatically removed. You must delete it manually either via the Scaleway console, or Scaleway’s Container Registry API.