What changed
Scaleway's October 2026 product changelog announces private endpoints for Serverless Containers. A container attached to a Scaleway Private Network can now expose an internal ingress endpoint, while the public default endpoint can be disabled separately. Previously supported private egress enabled outbound access to VPC resources; the new inbound endpoint completes a private-only service path. Scaleway's current how-to, endpoint concepts and security documentation describe console controls, API visibility and internal DNS.
Why it matters
Small teams often want a worker, API, webhook processor or internal AI service to run on serverless infrastructure but be reachable only by other applications or databases in a VPC. Before private ingress, a public endpoint with authentication or a proxy added an internet-facing surface and operational complexity. Disabling the public endpoint and using internal service discovery changes the default exposure model, without making application authentication or network design optional.
A private endpoint is distinct from private egress
Attach a Serverless Container to a Scaleway Private Network, then enable its private endpoint in Network & Domains. Resources with connectivity to the same VPC can reach the container at an internal hostname of the form http://<CONTAINER_ID>.<PRIVATE_NETWORK_ID>.internal. The API exposes a private_endpoint field only when the feature is enabled. Private egress, which lets a container call internal resources, existed before this October ingress change.
Disable public ingress to achieve isolation
The private endpoint and the public default endpoint are independent controls. Scaleway's security guide explicitly instructs operators to attach the container to a Private Network, enable private ingress and disable the public endpoint to prevent internet access. Merely enabling a private endpoint while leaving the public one on does not isolate the service. IAM-based X-Auth-Token authentication remains compatible with private endpoints.
DNS, HTTPS and VPC routing need testing
Scaleway assigns an internal DNS name to the private endpoint and supports TLS through a generated private-endpoint certificate. Clients may need to trust the certificate authority. DNS is resolved through the VPC's DNS service; custom routes and automatic routing across Private Networks in the same VPC are supported. Operators should verify the caller's VPC connectivity and certificate trust before disabling their public route.
There are operational limits
Scaleway permits one attached Private Network per container, with an IP allocated to each instance rather than a reservable fixed container IP. Private Network attachment may lengthen cold starts. Both V1 and V2 sandbox environments support the integration. The official reference says attaching a container to a Private Network does not itself add a charge; that is not a promise that compute, traffic or other resources are free.
A practical migration check
For an internal service, attach it to the intended Private Network, enable the private endpoint, test from a VPC-connected caller with HTTPS and the required IAM token, then disable the public endpoint and verify that internet requests fail. Keep a rollback plan and check any external webhooks, health checks or CI jobs that previously called the public URL. Use a gateway only for deliberately public routes.