chore(gen): content review MTA-5892 (#4813)

SamyOubouaziz · web-flow · commit c1b227c76273 · 2025-04-09T11:27:14.000+02:00
* chore(gen): content review MTA-5892

* chore(gen): update

* chore(gen): update
diff --git a/pages/object-storage/how-to/access-objects-via-https.mdx b/pages/object-storage/how-to/access-objects-via-https.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: Securely access objects in Object Storage over HTTPS.
 tags: object storage object-storage download https
 dates:
-  validation: 2024-10-04
+  validation: 2025-04-08
   posted: 2023-09-05
 categories:
   - storage
@@ -18,7 +18,7 @@ Scaleway Object Storage allows you to access your objects via HTTPS.
 
 If an object is [private](/object-storage/how-to/manage-object-visibility/), you can create a temporary public link from the [Scaleway console](https://console.scaleway.com).
 
-If an object is public, you can retreive the link to access it from the [Scaleway console](https://console.scaleway.com).
+If an object is public, you can retrieve the link to access it from the [Scaleway console](https://console.scaleway.com).
 
 <Macro id="requirements" />
 
diff --git a/pages/serverless-containers/how-to/add-a-custom-domain-to-a-container.mdx b/pages/serverless-containers/how-to/add-a-custom-domain-to-a-container.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: Add a custom domain to Scaleway Serverless Containers.
 tags: custom-domain container serverless cname record
 dates:
-  validation: 2024-10-01
+  validation: 2025-04-08
   posted: 2022-02-21
 categories:
   - serverless
@@ -23,9 +23,7 @@ Each container comes with an automatically generated domain, on which it is avai
 - A running [Serverless Container](/serverless-containers/how-to/deploy-container/)
 - Registered a domain name with the provider of your choice and have access to the domain name's DNS zone file
 
-1. On your domain provider's platform (for example, [Scaleway's domains](/domains-and-dns/how-to/manage-dns-records/)), add a CNAME record pointing to your container default URL in the domain's DNS zone file.
-
-
+1. On your domain provider's platform (for example, [Scaleway domains](/domains-and-dns/how-to/manage-dns-records/)), add a CNAME record pointing to your container default URL in the domain's DNS zone file.
 
     <Message type="note">
       - All domains are supported.
@@ -37,13 +35,17 @@ Each container comes with an automatically generated domain, on which it is avai
           - If your DNS provider does not support CNAME flattening, you need to create an ALIAS on your root domain (named `@` or with an empty name) instead of a CNAME.
     </Message>
 2. Before continuing, make sure the DNS entry is available. If not, the custom domain will likely end up in `error` on step 6. You can check this by:
-    - running `dig`, `drill` or `nslookup` commands on your domain using common DNS resolvers `1.1.1.1` and `8.8.8.8`: `dig <your_custom_domain> @1.1.1.1`, `dig <your_custom_domain> @8.8.8.8`
-    - or using a DNS check tool of your choice (some are available online)
+    - running `dig`, `drill` or `nslookup` commands on your domain using common DNS resolvers `1.1.1.1` and `8.8.8.8`:
+    ```shell
+    dig <your_custom_domain> @1.1.1.1
+    dig <your_custom_domain> @8.8.8.8
+    ```
+    - using a DNS check tool of your choice (some are available online)
 3. Click the **Endpoints** tab on your containers' page.
 4. Click **+ Add endpoint**.
 5. Enter your custom domain name and validate the form.
     <Message type="note">
-      Before being `ready`, some checks are performed. See technical details below to know more about these checks.
+      Before being `ready`, some checks are performed. Refer to the [technical details](#technical-details-and-troubleshooting) below to know more about these checks.
     </Message>
 6.  Connect to your container through that custom domain once the custom domain status is `ready`.
 
@@ -58,7 +60,7 @@ Read this section if you want more details about how custom domains are handled
 When adding a custom domain, the following tasks will be performed on Scaleway's side:
 
 1. Configure the custom domain on our gateways, so that they can handle traffic for that custom domain.
-2. Ensure that the custom domain points to one of the Serverless Container existing endpoints: either the default one `....functions.fnc.<region>.scw.cloud`, or an existing custom domain.
+2. Ensure that the custom domain points to one of the Serverless Container existing endpoints: either the default one `....containers.fnc.<region>.scw.cloud`, or an existing custom domain.
 3. If step 2 is OK, generate a dedicated TLS certificate for that custom domain so it can answer to HTTPS requests.
 
     <Message type="note">
@@ -77,8 +79,8 @@ HTTP-01 challenge failure (and by extension, a custom domain in `error` status)
 
 | Issue | Description | How to fix or avoid this? |
 | ----- | ----------- | ----------- |
-| DNS record is not correctly configured. | If the DNS record (mostly CNAME) is misconfigured on your DNS provider side, and the custom domain to the Serverless Container default endpoint, we will not be able to configure the custom domain. | Ensure that on your DNS provider, a CNAME record links your custom domain to the Serverless Container. To test, you can run the following command: `dig <your_custom_domain>` (or `nslookup`), and make sure that the value returned is a `CNAME` record to `<your_function>.functions.fnc.<region>.scw.cloud`. |
-| DNS record is not available yet. | This can be the case if the custom domain is created immediately after the CNAME is configured on your DNS provider side. | As a rule of thumb, wait a few minutes after creating the CNAME on your DNS provider, or at least wait until the DNS record is available on main resolvers (`1.1.1.1`, `8.8.8.8`). |
+| DNS record is not correctly configured. | If the DNS record (mostly CNAME) is misconfigured on your DNS provider side, and the custom domain to the Serverless Container default endpoint, we will not be able to configure the custom domain. | Ensure that on your DNS provider, a CNAME record links your custom domain to the Serverless Container. To test, you can run the following command: `dig <your_custom_domain>` (or `nslookup`), and make sure that the value returned is a `CNAME` record to `<your_container>.containers.fnc.<region>.scw.cloud`. |
+| DNS record is not available yet. | This can be the case if the custom domain is created immediately after the CNAME is configured on your DNS provider side. | Wait a few minutes after creating the CNAME on your DNS provider, or at least wait until the DNS record is available on main resolvers (`1.1.1.1`, `8.8.8.8`). |
 | DNS cache is stale (still pointing to an old endpoint). | If the custom domain was pointing to another endpoint before adding the CNAME record to the Serverless Container, and if the TTL is greater than the maximum time of the check (3 min), it can sometimes happen that the custom domain still resolves to the old endpoint, thus making the challenge fail. | Wait until DNS entry is available and use a smaller TTL. |
 | Negative DNS cache is stale | If the initial check fails (DNS record is not available yet), and the negative TTL configured on your DNS provider side is high, the negative TTL will prevent subsequent checks from querying the nameserver again, until it expires. Depending on the negative TTL configured, this can take more or less time. | Either reduce the negative TTL in your DNS provider configuration, or just wait until you are sure DNS record is available. If you already tried to add the custom domain and faced this issue, you likely have to wait for the negative TTL to expire before making another attempt (so the cache can also expire on our side). |
 | Route `/.well-known/acme-challenge` is not handled correctly. | To perform the HTTP-01 challenge, a call will be made on `<your_custom_domain>/.well-known/acme-challenge/<token>`. If you are using a proxying/caching tool (like Cloudflare) between the custom domain and the Serverless Container endpoint, a cached version of that route can be served, making the check fails. | Do not configure caching rules for routes starting with `/.well-known/acme-challenge`. Refer to the example below with Cloudflare. |
@@ -97,14 +99,14 @@ To clarify, let's take a concrete example:
 - you own a domain `mydomain.com`
 - an `A` record is configured on `website.mydomain.com` and points to `51.15.x.x`
 - when a client accesses `http://website.mydomain.com`, the request hits your Instance IP `51.15.x.x:80`
-- you also have a running version of your website hosted as a Serverless Container (only accessible using `example-website.functions.fnc.fr-par.scw.cloud`), and now you want your users to access this version from `http://website.mydomain.com`
+- you also have a running version of your website hosted as a Serverless Container (only accessible using `example-website.containers.fnc.fr-par.scw.cloud`), and now you want your users to access this version from `http://website.mydomain.com`
 
 Before adding the custom domain on your Serverless Container, you must change the DNS record to point to the Serverless Container endpoint:
 
 - before: `website.mydomain.com` is an A record to `51.15.x.x`
-- after: `website.mydomain.com` is a CNAME record to `example-website.functions.fnc.fr-par.scw.cloud`
+- after: `website.mydomain.com` is a CNAME record to `example-website.containers.fnc.fr-par.scw.cloud`
 
-By doing this, clients that already have the `website.mydomain.com` DNS record cached locally will continue to hit `51.15.x.x`, until the TTL expires. New clients (or those whose cache has expired) will start to hit `example-website.functions.fnc.fr-par.scw.cloud`. **However**, as long as the custom domain is not configured on the Serverless Container, these requests will end up in 404, because `website.mydomain.com` is not (yet) known in our infrastructure. Depending on your downtime tolerance (clients receiving 404) for a few minutes, there are 2 cases:
+By doing this, clients that already have the `website.mydomain.com` DNS record cached locally will continue to hit `51.15.x.x`, until the TTL expires. New clients (or those whose cache has expired) will start to hit `example-website.containers.fnc.fr-par.scw.cloud`. **However**, as long as the custom domain is not configured on the Serverless Container, these requests will end up in 404, because `website.mydomain.com` is not (yet) known in our infrastructure. Depending on your downtime tolerance (clients receiving 404) for a few minutes, there are 2 cases:
 
 - downtime is acceptable or can be planned (e.g. during the night or when there is less traffic on your website). In that case, after creating the CNAME record, and once you are sure DNS is available everywhere, create the custom domain on the Serverless Container. Once ready, requests to `http://website.mydomain.com` will hit your Serverless Container (no more 404).
 - downtime is not acceptable. Unfortunately, this is not possible right now out-of-the-box. To serve requests from `website.mydomain.com`, our infrastructure must know it, so a custom domain has to be configured. However, for the custom domain to be configured, the DNS record must point to the Serverless Container endpoint, resulting in a chicken-and-egg problem. To handle such scenarios, a CDN can be configured to serve a cached version of your website while the domain is being reconfigured (for example with [`stale-if-error`](https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Cache-Control#stale-if-error) option). If you choose this solution, be sure to disable caching on routes starting with `/.well-known/acme-challenge` to avoid issues described in the "Technical details and troubleshooting" section.
diff --git a/pages/serverless-containers/reference-content/containers-concurrency.mdx b/pages/serverless-containers/reference-content/containers-concurrency.mdx
@@ -6,7 +6,7 @@ content:
   h1: Containers concurrency
   paragraph: Learn about concurrency settings for Scaleway Serverless Containers.
 dates:
-  validation: 2024-10-03
+  validation: 2025-04-08
   posted: 2024-03-26
 tags: serverless containers concurrency concurrent execution scaling parallelism parallel instances
 categories:
@@ -46,9 +46,7 @@ A higher number of instances processing requests at the same time implies a grea
 
 ## Concurrency setting
 
-When [deploying a container](/serverless-containers/how-to/deploy-container/), Scaleway Serverless Containers allows you to configure the [concurrency](/serverless-containers/concepts/#concurrency), which is the maximum number of requests a single container instance can handle at the same time. The concurrency setting ranges from 1 to 1,000 simultaneous instances.
-
-By default, Serverless Containers allow **80 concurrent requests** per container instance. We recommend using the default value, as Serverless Containers are designed to efficiently function with it, but you can lower it to better fit specific requirements.
+When [deploying a container](/serverless-containers/how-to/deploy-container/), Scaleway Serverless Containers allows you to configure the [concurrency](/serverless-containers/concepts/#concurrency), which is the maximum number of requests a single container instance can handle at the same time. By default, Serverless Containers allow **80 concurrent requests** per container instance. We recommend using the default value, as Serverless Containers are designed to efficiently function with it, but you can lower it to better fit specific requirements.
 
 ## Impact of concurrency on container scaling
 
diff --git a/pages/serverless-containers/reference-content/deploy-container.mdx b/pages/serverless-containers/reference-content/deploy-container.mdx
@@ -6,7 +6,7 @@ content:
   h1: Methods to deploy Serverless Containers
   paragraph: Step-by-step guide to deploying a container on Scaleway.
 dates:
-  validation: 2024-10-03
+  validation: 2025-04-08
   posted: 2023-03-10
 ---
 
diff --git a/pages/serverless-functions/faq.mdx b/pages/serverless-functions/faq.mdx
@@ -5,7 +5,7 @@ meta:
 content:
   h1: Serverless Functions FAQ
 dates:
-  validation: 2024-10-03
+  validation: 2025-04-08
 category: serverless
 productIcon: FunctionsProductIcon
 ---
@@ -137,11 +137,11 @@ We recommend you set high values, [use metrics to monitor](/serverless-functions
 
 ### How does scaling work in these serverless services?
 
-Scaling in Serverless Containers and Serverless Functions is handled automatically by the platform. When demand increases - more requests or events - the platform spins up additional instances to handle the load. When demand decreases, instances spin down. This ensures optimal performance without manual intervention.
+Scaling in Serverless Containers and Serverless Functions is handled automatically by the platform. When demand increases - more requests or events - the platform creates additional instances to handle the load. When demand decreases, instances that are not used anymore are removed. This ensures optimal performance without manual intervention.
 
 ### Can I upgrade Serverless Function resources (vCPU and RAM) at any time?
 
-Yes, Serverless Functions resources can be changed at any time without causing downtime, see the previous question for full details.
+Yes, Serverless Functions resources can be changed at any time without causing downtime. Refer to the next question for full details.
 
 ### Does updating a Serverless Function cause downtime?
 
@@ -173,7 +173,7 @@ Refer to our dedicated page about [Serverless Functions limitations and configur
 
 Serverless Functions enables you to deploy functions using popular languages: `Go`, `Node`, `Python`, `PHP`, and `Rust`.
 
-Refer to our dedicated page about [Serverless Functions Runtimes Lifecycle](/serverless-functions/reference-content/functions-runtimes/)
+Refer to our dedicated page about [Serverless Functions Runtimes Lifecycle](/serverless-functions/reference-content/functions-runtimes/).
 
 ### Why does my function have an instance running after deployment, even with min-scale 0?
 
@@ -211,7 +211,7 @@ Check out our [serverless-examples repository](https://github.com/scaleway/serve
 
 On a Serverless Function, you can change the runtime if the new runtime is from the same family as the old one. Example: migrate from `go1.23` to `go1.24`. To change programming language, you must create a new Serverless Function.
 
-See the [functions runtimes lifecycle documentation](/serverless-functions/reference-content/functions-runtimes/) for more information about runtimes.
+See the [functions runtimes documentation](/serverless-functions/reference-content/functions-runtimes/) for more information about runtimes.
 
 ## Network and storage
 
@@ -236,8 +236,7 @@ By design, it is not possible to guarantee static IPs on Serverless Compute reso
 ### How can I attach Block Storage to a Serverless Function?
 
 Scaleway Serverless Functions do not currently support attaching Block Storage. These functions are designed to be
-stateless, meaning they do not retain data between invocations. For persistent storage, we recommend using external
-solutions like Scaleway Object Storage.
+stateless, meaning they do not retain data between invocations. For persistent storage, we recommend using external solutions like Scaleway Object Storage.
 
 ### How can I store data in my Serverless resource?
 
@@ -249,7 +248,7 @@ For some use cases, such as saving analysis results, exporting data etc., it can
 
 * [Serverless Databases](/serverless-sql-databases/): Go full serverless and take the complexity out of PostgreSQL database operations.
 * [Managed MySQL / PostgreSQL](/managed-databases-for-postgresql-and-mysql/): Ensure scalability of your infrastructure and storage with our new generation of Managed Databases designed to scale on-demand according to your needs.
-* [Managed Database for Redis®](/managed-databases-for-redis/): Fully managed Redis®* in seconds.
+* [Managed Database for Redis®](/managed-databases-for-redis/): Fully managed Redis® in seconds.
 * [Managed MongoDB®](/managed-mongodb-databases/): Get the best of MongoDB® and Scaleway in one database.
 
 #### Storage
diff --git a/pages/serverless-jobs/faq.mdx b/pages/serverless-jobs/faq.mdx
@@ -5,7 +5,7 @@ meta:
 content:
   h1: Serverless Jobs FAQ
 dates:
-  validation: 2024-10-03
+  validation: 2025-04-08
 category: serverless
 productIcon: ServerlessJobsProductIcon
 ---
diff --git a/pages/serverless-jobs/reference-content/jobs-limitations.mdx b/pages/serverless-jobs/reference-content/jobs-limitations.mdx
@@ -7,7 +7,7 @@ content:
   paragraph: Learn the limitations of Scaleway Serverless Jobs.
 tags: Jobs limitations serverless
 dates:
-  validation: 2024-10-03
+  validation: 2025-04-08
   posted: 2021-03-28
 categories:
   - serverless
@@ -43,7 +43,7 @@ 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 must ensure that you build your image to target `amd64` architecture, to achieve 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.
 
