Network #

...
apps:
  <APPNAME>:
    ...
    container:
      network:
        protocol: http
        ports:
           - 8080
        public: false
        public_ipv4_allowlist: ["0.0.0.0/0"]
        public_ipv6_allowlist: ["::/0"]
        health_check:
           path: /
           status: 200-499
    ...

protocol #

Determines how the app can be accessed via the network. Valid values for Protocol are http and tcp.

The protocol value also determines how the app is reachable from the outside (if public is set to true), and how it is checked for its health. The details are outlined in the table below.

Make sure your App binds to the address 0.0.0.0. Some frameworks and application servers use the loopback address 127.0.0.1 (localhost) by default, but this does not allow external connections. You can also read the environment variable PORT to find out which port we expect your application to listen on.

ports #

Specifies the port the application listens to internally. For example, when you deploy a webserver that listens on port 4400, you should set the app ports to [4400].

Note, that when you have configured protocol with http the external ports will always be 80 and 443 which are the default http and https ports. Therefore you can also just set one port. Only when you specify tcp as protocol, you can specify multiple ports which are available externally.

public (optional) #

Specifies whether an App should be publicly reachable. If it is set to false, no external traffic is ever routed to the app. Setting an app as private makes sense for apps working on background jobs, for example.

The default value is false.

When making an App public, external traffic reaches the app through a load balancer. When using the protocol http, the load balancer terminates TLS connections and forwards the requests to the App containers. It uses the Least Outstanding Requests (LOR) algorithm to select a target to forward the request to. This algorithm optimizes response times , though it has some risks to consider:

The main risk when using the LOR algorithm is causing a flood of requests when the load balancer adds a new target to the target group. This happens when the infrastructure creates a new app container due to a deployment or scaling, for example. If your app is under heavy load, and you scale your app, consider increasing the scale by more than one additional container to distribute initial load.

The other potential issue is that a failing target will often respond quicker than a healthy one. For example, your service might immediately respond with a 500 error if it’s not connected to the database. In this situation, the failing target will receive a higher proportion of requests, causing a much larger incident. So, it’s important to ensure that container health checks are quick to react to a failing target. This might still result in some seconds of failed requests though, so it might also be worth introducing some artificial error latency.

public_ipv4_allowlist (optional) #

When public is set to true, public_ipv4_allowlist can be set to limit the public IPv4 IPs which have access to the application from the internet, e.g. public_ipv4_allowlist: ["1.2.3.4/32"].

The default is 0.0.0.0/0, which means that all public IPs can access the application.

If you only want to allow these specific IPv4 addresses, you should set public_ipv6_allowlist to []. Otherwise IPv6 addresses are still allowed to access your app.

public_ipv6_allowlist (optional) #

When public is set to true, public_ipv6_allowlist can be set to limit the public IPv6 IPs which have access to the application from the internet, e.g. public_ipv4_allowlist: ["2001:0db8:/32"].

The default is ::/0, which means that all public IPs can access the application.

If you only want to allow these specific IPv6 addresses, you should set public_ipv4_allowlist to []. Otherwise IPv4 addresses are still allowed to access your app.

health_check (optional) #

The network health check is a check which is performed for every public app. Its implementation depends on the Protocol setting:

• For protocol http, it’s a HTTP request to a user-configurable path (defaults to /), with the expectation that the App responds with a certain HTTP status code range (defaults to 200-499). The request goes to the app’s port.

• For protocol tcp, it’s a connection check. It opens a TCP connection to the app’s port. The check is successful when the connection can be established. In this case, you may see invalid or erroneous connections in your app’s logs, because from the application point of view, the health check looks like an invalid connection request.

Check out the health checks section for more details about the difference between the container.health_check and network.health_check fields.

Configure HTTP Network Health Check #

The HTTP check can be customized in two ways: setting a path and a range of acceptable HTTP response status codes.

...
apps:
  <APPNAME>:
    ...
    container:
      network:
         ...
         health_check:
            path: /.well-known/health-check
            status: 200
    ...

Note that path needs to start with /. You should use /healthz instead of healthz, for example.

The expected healthy statuscode range can be specified with comma-separated values with an optional range. The following are some examples of valid range values:

Please note that although 200-499 is a valid port range for this option, all Health Check responses with HTTP status codes 400 and higher will currently lead to an availability alert if you have configured a target. The app will still be available and work but the alert must be ignored. Therefore we recommend to always use a status code below 400 or a path without authorization if that causes a 401 or 403 response.

Going further #

Configure Resources