Private Networks Private Beta Is Now Available — Secure Networking for Your Apps

We are pleased to announce the launch of the private beta for our highly anticipated Private Networks feature. Find out more below!

Private Networks: The Foundation of Your Security

Introduced a few months ago, Projects offer a new way to organize your applications and resources by service, product, customer, environment, or team.

Building on this foundation, Private Networks equips each project with a dedicated private network that connects your services and secures their communications. True to our mission to simplify developers’ daily workflows, we designed a ready-to-use solution that requires no complex configuration or networking expertise and comes at no additional cost.

Your projects and applications can rely on it from the earliest stages of development, without sacrificing security for agility.

How It Works

To enhance our infrastructure seamlessly, without impacting your workflows or application availability, Private Networks integrates smoothly into your existing setup.

An additional VXLAN-based network, secured with WireGuard, connects all applications and their containers, enabling private and secure mesh communications. For readers with a technical background, we’ll dive deeper into these mechanisms in an upcoming article.

The behavior of web processes remains unchanged. Internet traffic will continue to reach them through your domain name. They can then forward this traffic to any other container within their private network, including their own non-web processes and the processes of other applications in the same project.

For more details, please refer to our documentation.

Private DNS

Each container is assigned a private domain name following this format:

<container-number (optional)>.<container-type (optional)>.<application-id>.<private-network-id>.private-network.internal

This hostname resolves to the private IP address (or addresses) of your application’s containers and is accessible only within the project’s private network.

To simplify integration, we’ve also introduced new Runtime Environment Variables:

• SCALINGO_APPLICATION_ID: the unique ID of the application
• SCALINGO_PRIVATE_NETWORK_ID: the unique ID of the private network, also included in the container hostname
• SCALINGO_PRIVATE_HOSTNAME: the full container hostname, particularly useful for precise container identification in logs and for monitoring purposes

To inspect DNS records from a one-off container, you can use commands such as:

host <application-id>.<private-network-id>.private-network.internal

Example output:

<application-id>.<private-network-id>.private-network.internal has address 10.240.0.4

Benefits of Private Networks at Scalingo

Any Port, Any Protocol

Within a private network, there are no restrictions on HTTP or on the default port imposed by the PORT environment variable. Your processes, containers, and microservices can communicate using the ports and protocols they require.

Secure by Design

Private Networks enable the processes you choose to make private to communicate within an isolated environment. By publicly exposing only selected services, you reduce your attack surface and strengthen your overall security posture.

Service Discovery

A standardized DNS naming convention simplifies service-to-service communication. Containers can deterministically connect to other processes, saving valuable development and operational time.

Powerful Use Cases

Private Apps

Renaming a web process (for example, to backend or privateweb) limits its visibility to the project’s private network. This approach is particularly well suited for applications running behind a proxy (see the ModSecurity example below).

Note that renaming your web process comes with certain limitations. Features that rely on public routers are available only to publicly exposed processes, including operational metrics, autoscaling based on requests per minute per container, custom domains, and some routing options.

To make this choice simpler and reversible, we plan to introduce an option, similar to what is available for databases, that allows you to disable public exposure of a web process without renaming it.

Enhanced Security With ModSecurity

Many Scalingo customers already rely on authentication strategies such as header-based filtering to block unauthorised traffic.

With Private Networks, you can fully isolate your applications by exposing only your ModSecurity proxy to the public Internet, keeping sensitive services protected within your private network.

Simplified Microservices Architecture

Managing microservice architectures has long been challenging, particularly when it comes to service discovery and inter-service communication. Private Networks ensure that your Scalingo containers can securely discover and communicate with one another.

Efficient N-Tier Architectures

Previously, organizing and interconnecting multi-tier services was complex. With private DNS and project-level private networks, deploying n-tier architectures becomes straightforward: you gain scalability while exposing only the services that need public access.

Keycloak Clustering

Many applications benefit from unrestricted internal communication. We’ll soon publish a guide on deploying Keycloak in a cluster to achieve high availability.

If you have additional ideas or complementary use cases, feel free to contact us—we’d love to discuss them!

The Private Beta Phase

We are opening this feature to a select group of customers. To get early access, sign up for the beta and tell us about your use cases.

In the coming weeks, we’ll also share more technical details about how we built Private Networks at Scalingo.