Mta 6017

pages/instances/reference-content/migrating-vms-vmware-scaleway.mdx

@@ -26,8 +26,7 @@ Identify the virtual machines (VMs) to migrate on your VMware platform:
 
 - Disk configuration (number, size, type)
   <Message type="tip">
-    If multiple disks are present, follow the same steps to create individual snapshots and then combine them into a single Scaleway image.
-    For more detailed instructions on creating an image from multiple volumes, refer to documentation on [how to create an image from a snapshot](/instances/how-to/create-image-from-snapshot/).
+    If multiple disks are present, repeat the same steps to create several snapshots and group them as a single Scaleway image.
   </Message>
 - Network configuration (number of NICs, type)
   <Message type="tip">
@@ -130,13 +129,6 @@ Upload the converted disk:
   ```bash
   scw instance image create snapshot-id=<snapshot-uuid> arch=x86_64
   ```
-  <Message type="note">
-    If your image consists of multiple snapshots, ensure you [specify them](/instances/how-to/create-image-from-snapshot/#creating-an-image-via-the-scaleway-cli) when creating the image:
-    ```bash
-    scw instance image create snapshot-id="$SCW_VOLUME_ID_1" additional-volumes.0.id="$SCW_VOLUME_ID_2" arch="x86_64"
-    ```
-    Refer to the [CLI documentation](https://cli.scaleway.com/instance/#create-an-instance-image) for further information.
-  </Message>
 
 3. Create the server from the image:
   ```bash

pages/serverless-containers/concepts.mdx

@@ -7,7 +7,7 @@ content:
   paragraph: Key concepts of Scaleway Serverless Containers.
 tags: containers cold-start concurrency container-registry environment-variables jwt vcpu serverless scale autoscaling
 dates:
-  validation: 2024-11-14
+  validation: 2025-05-26
 categories:
   - serverless
 ---
@@ -115,15 +115,15 @@ The Serverless infrastructure manages incoming request traffic. In scenarios lik
 
 ## Logging
 
-Serverless Containers offers a built-in logging system based on Cockpit to track the activity of your resources: see [monitoring Serverless Containers](/serverless-containers/how-to/monitor-container/).
+Serverless Containers offers a built-in logging system based on Cockpit to track the activity of your resources. Refer to [monitoring Serverless Containers](/serverless-containers/how-to/monitor-container/) for more information.
 
 ## Max scale
 
-This parameter sets the maximum number of container instances. You should adjust it based on your container's traffic spikes, keeping in mind that you may wish to limit the max scale to manage costs effectively.
+This parameter sets the maximum number of container instances. You should adjust it based on your container's traffic spikes, keeping in mind that you may wish to limit the maximum scale to manage costs effectively.
 
 ## Metrics
 
-Performance metrics for your Serverless resources are natively available: see [monitoring Serverless Containers](/serverless-containers/how-to/monitor-container/).
+Performance metrics for your Serverless resources are natively available. Refer to [monitoring Serverless Containers](/serverless-containers/how-to/monitor-container/) for more information.
 
 ## Min scale
 
@@ -165,7 +165,7 @@ Refer to the [dedicated FAQ](/serverless-containers/faq/#how-can-i-configure-acc
 A queue trigger is a mechanism that connects a container to a queue created with [Scaleway Queues](/queues/concepts/#scaleway-queues), and invokes the container automatically whenever a message is added to the queue.
 
 For each message that is sent to a queue, the trigger reads the message and invokes the associated container with the message as the input parameter.
-The container can then process the message and perform any required actions, such as updating a database or sending a notification.
+The container can then process the message, and perform any required actions, such as updating a database or sending a notification.
 
 ## Registry endpoint
 
@@ -181,11 +181,10 @@ Use cases:
 
 ## Rolling update
 
-When deploying a new version of a Serverless Container, a rolling update is applied by default. This means that the new version of the service is gradually rolled out to your users without downtime.
-Here is how it works:
+When deploying a new version of a Serverless Container, a rolling update is applied by default. The new version of the service is gradually rolled out to your users without downtime, as follows:
 
 * When a new version of your container is deployed, the platform automatically starts routing traffic to it incrementally, while still serving requests from the old version until the new one is fully deployed.
-* Once the new version is successfully running, we gradually shift all traffic to it, ensuring zero downtime.
+* Once the new version is successfully running, the platform gradually shifts all traffic to it, ensuring zero downtime.
 * The old version is decommissioned once the new version is fully serving traffic.
 
 This process ensures a seamless update experience, minimizing user disruption during deployments. If needed, you can also manage traffic splitting between versions during the update process, allowing you to test new versions with a subset of traffic before fully migrating to it.
@@ -200,7 +199,7 @@ Refer to the [dedicated documentation](/serverless-containers/reference-content/
 
 ## Scale to zero
 
-One of the advantages of Serverless Containers is that when your container is not triggered, it does not consume any resources, which enables great savings.
+When provisioned with a [minimum scale](#min-scale) of `0`, Serverless Containers scale down to zero active instances as long as they are not triggered. While idling, they do not consume any resources, which allows to reduce the cost of your infrastructure.
 
 ## Secrets
 

pages/serverless-containers/how-to/create-manage-delete-containers-namespace.mdx

@@ -26,7 +26,8 @@ This page shows you how to create and manage a Serverless Containers namespace.
 1. Click **Containers** in the **Serverless** section of the side menu. The list of your containers namespaces displays.
 2. Click **Create namespace**. If you have no existing Serverless Containers resources in your current Project, click **Deploy container**.
 3. Complete the following steps in the wizard:
-    - Enter a **name**, and optionally a **description** for your namespace. The name must only contain alphanumeric characters and dashes.
+    - Enter a **name** or use the automatically generated one. The name can only contain lowercase alphanumeric characters and dashes.
+    - Optionally, add a **description** and **tags**.
     - Choose a **region**, which is the geographical location in which your namespace will be deployed.
     - Enter any **environment variables** required for your namespace. Environment variables configured in a namespace will be available in all containers/apps within the same namespace. For each environment variable, click **+Add new variable** and enter the key / value pair.
     - Set secret environment variables (optional). **Secrets** are environment variables that are injected into your container and stored securely, but not displayed in the console after initial validation. Add a **key** and a **value**.

pages/serverless-containers/how-to/deploy-container.mdx

@@ -120,7 +120,9 @@ Private external container registries are currently not supported.
       - `ghcr.io/namespace/image` to deploy an image from [GitHub Container Registry](https://github.com/features/packages)
 3. Choose the [port](/serverless-containers/concepts/#port) your container is listening on. We recommend configuring your container to listen on the `$PORT` environment variable.
 
-4. Choose a **name** for your container and, optionally, a **description**. The name must only contain alphanumeric characters and dashes.
+4. Enter a **name** for your container, or use the automatically generated one.
+
+5. Optionally, add a **description** and **tags**.
 
 ### Container resources and scaling
 

pages/serverless-functions/how-to/create-a-function.mdx

@@ -43,9 +43,9 @@ This page shows you how to deploy a [function](/serverless-functions/concepts/#s
 
 3. If you used the code editor, enter the [handler](/serverless-functions/reference-content/functions-handlers/) of your function.
 
-4. Enter a **name** or use the automatically generated one. The name can only contain lowercase alphanumeric characters and dashes. You can click the icon at the right to generate a random name for your function.
+4. Enter a **name** or use the automatically generated one. The name can only contain lowercase alphanumeric characters and dashes.
 
-5. Enter an optional **description** for your function.
+5. Optionally, add a **description** and **tags**.
 
 ### Function resources and scaling
 

pages/serverless-functions/how-to/create-manage-delete-functions-namespace.mdx

@@ -30,7 +30,7 @@ This page shows you how to create, manage, and delete a Functions namespace usin
 
 3. Complete the following steps in the wizard:
     - Enter a **name** or use the automatically generated one. The name can only contain lowercase alphanumeric characters and dashes.
-    - Enter an optional **description**.
+    - Optionally, add a **description** and **tags**.
     - Choose a **region**, which is the geographical location in which your namespace will be deployed.
     - Click **+ Add advanced options** to define any **environment variables** you want to inject into your function. For each environment variable, click **+ Add variable** and enter the key/value pair.
     - Set optional secret environment variables. **Secrets** are environment variables which are injected into your function and stored securely, but not displayed in the console after initial validation. Add a **key** and a **value**.

pages/serverless-sql-databases/concepts.mdx

@@ -7,7 +7,7 @@ content:
   paragraph: Detailed explanation of concepts and architecture behind Scaleway's serverless SQL databases.
 tags: sql databases serverless
 dates:
-  validation: 2024-11-14
+  validation: 2025-05-26
 categories:
   - serverless
 ---