Edge Services - Concepts

Reviewed on June 09, 2026

Backend

A backend (formerly referred to as origin) is the primary source from which a Scaleway Edge Services pipeline retrieves and caches data. An Edge Services backend can consist of either:

• An Object Storage bucket, or
• A Load Balancer and frontend port that Edge Services connects to in order to request content, and (optionally) a specified host associated with the Load Balancer, used in the HTTP request Host header.

Cache

The storage location where Edge Services stores copies of content that it has retrieved from a given backend. When users request content from the Edge Services endpoint, it serves content directly from the cache wherever possible, in accordance with the caching rules defined by the user. This reduces load on the bucket or Load Balancer/backend servers.

Note that if an object has a caching directive, the caching directive always takes precedence over any lifetime setting defined in Edge Services.

Certificate

The SSL/TLS certificate for your subdomain to enable Edge Services to serve content over HTTPS, if you have customized your Edge Services endpoint. You can choose between uploading your own certificate held in Scaleway Secret Manager, or letting Edge Services generate a fully-managed Let's Encrypt certificate.

CNAME record

The CNAME record pointing your subdomain to the Edge Services endpoint, if you have customized your Edge Services endpoint. This is necessary to ensure that traffic for your customized subdomain is correctly directed towards the Edge Services endpoint by DNS servers.

Refer to CNAME records for Edge Services for more information.

Edge Services

Edge Services is an additional feature for Scaleway Load Balancers and Object Storage buckets. It provides:

• A caching service to improve performance by reducing load on your backend
• A Web Application Firewall to protect your backend from threats and malicious activity
• A customizable and secure endpoint for accessing content via Edge Services, which can be set to a subdomain of your choice.

Read the Edge Services Quickstart to get started.

Endpoint

The endpoint from which a given Edge Services pipeline can be accessed, e.g. https://pipeline-id.svc.edge.scw.cloud. When a client requests content from the Edge Services endpoint, it is served by Edge Services and its cache, rather than from the backend (Object Storage bucket or Load Balancer) directly. Edge Services automatically manages redirection from HTTP to HTTPS.

The endpoint can be customized with a user-defined subdomain, allowing you to replace the standardized endpoint with the subdomain of a domain you already own, e.g. http://my-own-domain.com. An associated certificate, and CNAME record will be required, in this case.

Exclusions

In the context of an Edge Services Web Application Firewall, exclusions let you define filters for requests that should not be evaluated by WAF, but rather pass straight to the backend. Learn more about creating exclusions.

Origin

Previously, the term origin was used to describe a Load Balancer or Object Storage bucket that was the target of an Edge Services pipeline. Moving forward, for enhanced clarity, we will use the term backend rather than origin.

Destination host

In the case of a Load Balancer as an Edge Services backend, the specific host for which Edge Services requests and caches data. This is an optional setting: when specified, this host (e.g. mydomain.com) is used in the HTTP Host header when Edge Services requests data from the Load Balancer. If no destination host is specified, the Host from the incoming request will be used.

The destination host must be associated with the Load Balancer / its backend servers, and only one host may be set per pipeline. If your Load Balancer is in front of multiple hosts, you can create a separate Edge Services pipeline for each. Each host will therefore get its own Edge Services endpoint and cache.

Paranoia level

In the context of an Edge Services Web Application Firewall, the paranoia level determines how sensitive the request-evaluation mechanism is to potential threats. Four paranoia levels are available, with level 1 being the least sensitive, and level 4 being the most sensitive. The higher the paranoia level, the more likely it is that a given request will be judged to be malicious. For full details on paranoia levels, see our detailed documentation.

Pipeline

Open Image over content

An Edge Services pipeline consists of a backend, which Edge Services can protect from threats with a Web Application Firewall, and for which it also requests and caches content. Each pipeline also has an endpoint from which content is accessed and served via Edge Services. The pipeline's endpoint can be customized with a user-defined subdomain and associated certificate so that Edge Services can serve content over HTTPS.

You can create an Edge Services pipeline for each of your Object Storage buckets or Load Balancers. Note that caching and WAF can be enabled and disabled at will, so are optional parts of the pipeline, as is the customization of the endpoint.

Protocol

The protocol (HTTP or HTTPS) that the Edge Services pipeline should use when sending requests to a backend. HTTPS is recommended, but you should choose the protocol that corresponds to your Load Balancer setup.

WAF

An Edge Services Web Application Firewall (WAF) evaluates requests to your backend to determine whether they are potentially malicious. You can set the paranoia level to be used when evaluating requests. Requests identified as malicious are then blocked or logged depending on your settings. Find out more about configuring a WAF.