When these exchanges require the ports of different services to be publicly exposed, the attack surface increases and the network configuration becomes more cumbersome to maintain. Creating a private network between applications directly addresses this problem without requiring you to deploy or manage VPN infrastructure.
This approach allows cloud services to communicate directly with one another, over any port, without exposing the ports required for these exchanges to the Internet. Data travels over an encrypted overlay network that is independent of the physical network. On Clever Cloud, Network Groups provide this functionality: they establish WireGuard tunnels between resources, with no low-level network configuration.
Why exposing your services to the Internet is a problem
When application components communicate over public ports, each exposed service becomes a potential entry point. This has three practical consequences:
- Larger attack surface: every public access point must be secured, monitored, and maintained.
- Unnecessary exposure of technical ports: some protocols require dedicated ports for internal communications, even though they are not intended to be publicly accessible. A private network lets you use them without creating new entry points from the Internet.
- Reliance on external tunnels: connecting services distributed across several zones usually requires you to configure and manage an additional network layer, often a VPN.
Connecting services within a private network allows their internal traffic to flow without exposing the ports used for these communications. However, this does not disable any public access that is already configured. If only an API gateway should provide access to the backends from the Internet, you must also block their public endpoints.
How a private network between applications works
The approach is based on an overlay network: a logical network layer built on top of the existing physical network. Resources have private connectivity to one another, and their communications are encrypted by default. Because the overlay is independent of the underlying physical network, it can connect resources distributed across multiple zones or datacenters.
Consider an application comprising a public API, several backend services, and a database: only the API is exposed to the Internet. The internal services and database communicate with one another over the private network, using the ports they require.
Creating a private network between applications on Clever Cloud
Network Groups provide this setup. Each resource attached to a Network Group receives a private IP address from a dedicated CIDR, as well as an internal domain name in the format “<memberID>.m.<ngID>.cc-ng.cloud”. The resources can then connect directly to one another, over any port, with no network configuration required.
A Network Group can connect Clever Cloud applications, add-ons, and external machines within the same private network. Communications are encrypted using WireGuard, a protocol known for its simplicity and speed.
You can create and manage Network Groups from the Clever Cloud Console, Clever Tools (CLI), or the public API. For example, from the command line:
clever features enable ng
clever ng create monNG –link app_xxx,postgresql_xxx
Note: add-on compatibility depends on their generation. Add-ons deployed since 2024 are compatible; older ones may require a migration or restart. See the documentation for the current limitations.
When should you use a private network between applications?
Network Groups are not a standalone solution: they enable certain secure architectures rather than replace an existing product. Several use cases are common.
- Protect applications behind an API gateway: the backends remain unreachable from outside while still being accessible from the gateway.
- Deploy Keycloak for high availability: multiple Keycloak instances synchronise over the private network without being publicly exposed.
- Enable microservices to communicate: in a distributed architecture, services communicate continuously without opening public ports or configuring tunnels.
- Integrate external resources: connect a local machine or third-party server to your Clever Cloud applications over an encrypted channel.
Connect your services without the complexity of a VPN
With Network Groups, private connectivity becomes a platform capability rather than infrastructure that you have to build and maintain. You choose which resources need to communicate; Clever Cloud establishes the encrypted private network between them. This allows you to use the ports required for internal communications without exposing them publicly, whether your resources are in the same zone, distributed across several data centres or, where applicable, external to Clever Cloud.
FAQ
What is the difference between a VPN and a private network between applications?
The main difference is what you have to manage. With a traditional VPN, you generally need to deploy, configure, and maintain connectivity between the relevant machines or networks. With Network Groups, Clever Cloud manages this layer for you: you attach the resources to the group, and the platform establishes encrypted private connectivity using WireGuard.
Do you need to modify your application code to use Network Groups?
In most cases, no. You do not need to rewrite your application. The change is in the configuration, not the code: the calling application must target the destination service using its internal Network Group domain name (<memberID>.m.<ngID>.cc-ng.cloud) and the required port, usually through an environment variable. No specific library or application changes are required for the traffic to use the private network.
Does a private network between applications work with machines outside Clever Cloud?
Yes. A Network Group can connect Clever Cloud applications, add-ons, and external machines within the same private network. However, support for attaching an external peer is still being stabilised during the testing phase.
Does a private network make an application invisible from the Internet?
No, not by itself. Network Groups provide private access to resources, but they do not disconnect an application from the Internet. Restricting public exposure is handled by other platform mechanisms.