docs(serverless): add Versioning and rollback section

serverless/containers/reference-content/containers-limitations.mdx

@@ -86,3 +86,20 @@ For example, if you build an image using an ARM CPU, such as Apple Silicon M ser
 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 `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.

serverless/functions/reference-content/functions-limitations.mdx

@@ -55,3 +55,20 @@ To ensure the proper functioning of the product, we restrict the use of certain
   * **465**: Due to potential abuse (spam), no outbound traffic is allowed through this port, except from Scaleway Transactional Email SMTP servers.
 * Reserved environment variables:
   * `SCW_*`: Reserved for product configuration (for example: token validation).
+
+## Versioning and rollback
+
+Scaleway Functions do not currently support versioning or automatic rollback mechanisms.
+However, in the event of a failed deployment, the previously deployed version of the function will continue to handle
+incoming requests for up to 24 hours. After this period, the function 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 function is deployed and works correctly.
+* Time +1H: The function is redeployed, but the deployment fails, and the function ends up in an error state.
+* Time +2H: Despite the failed deployment, the first function is still handling incoming requests.
+* Time +25H: The 24-hour window expires, and both the first working function and the failed function are removed,
+leading to service disruption until a new successful deployment is made.