All of your containers are running behind our load balancers, which offer a variety of features for you.

How it works

Fast scaling

When horizontally scaling containers  that are stateless, i.e. without volumes, the load balancer lets you do so in seconds. If you scale your stateless containers to two or more instances, the load will get distributed using a round robin distribution.

Managing traffic

Our load balancers handle incoming traffic and route requests to all web apps. Routing requires a Host header that is only provided by HTTP, excluding other protocols from being used. Also, on, static IP addresses are reserved for load balancers. To direct all requests from a single user to the same container, our load balancers can be instructed to use sticky sessions.

Improving security

You can instruct our load balancers to redirect all HTTP requests to your domain to HTTPS, using a 301 status code. You can also enable HTTP Strict Transport Security (HSTS) to protect against protocol downgrade attacks and cookie hijacking. This adds "Strict-Transport-Security: max-age=15768000" to every response. Further restrict the access to your web app by setting up a username and password with basic authentication.

Routing TCP requests

Most applications hosted on are web apps accessible via HTTPS and Domains. Our load balancer also allows you to expose applications via TCP.


Web UI

When entering the settings of an app, either through creating or editing a project, go to the "Basic Setup" tab and the subsequent "Networking" setup. Under the web app option, you can "Customize Load Balancer" by enabling or disabling HTTP to HTTPS redirects or HSTS Header, enabling Sticky Sessions, or setting up basic authentication using the format "Authentication:[username]:[password hash]". Look up here how to create a password hash.

Example for a "Customize Load Balancer" form, enabling HTTP to HTTPS redirects, disabling HSTS Header, enabling Sticky Sessions, and setting up basic auth for user "admin" and password "test".

Note: Older projects might still use the Environment Variables HAPROXY_0_REDIRECT_TO_HTTPS, HAPROXY_0_USE_HSTS, HAPROXY_0_STICKY, and HAPROXY_0_AUTH. We recommend using the new UI elements or JSON properties (see below) instead.


When describing your project in either our JSON or YAML formats, you can set "redirectHttps", "hstsHeader", and "stickySessions" to either true or false (default: false) and "basicAuth" to a value of "Authentication:[username]:[password hash]" as part of the domain. Look up here how to create the password hash.


   "domain": {
      "uri": "",
      "redirectHttps": true,
      "hstsHeader": false,
      "stickySessions": true,
      "basicAuth": "Authentication:admin:\\$1\\$000000\\$qNWrOu23wl6m4CxfO33Qn."


   uri: ""
   redirectHttps: true
   hstsHeader: false
   stickySessions: true
   basicAuth: "Authentication:admin:\\$1\\$000000\\$qNWrOu23wl6m4CxfO33Qn."

Both examples enable HTTP to HTTPS redirects, disable HSTS Header (though that could be left out), enable Sticky Sessions, and set up basic auth for user "admin" and password "test". Note that the dollar sign needs to be escaped for the password hash in JSON.


If you want to deploy from docker-compose.yml, you need to use the Environment Variables listed above (see section "Note:"  under the Web UI paragraph).

Feature Details

Category: Deploy
Hosting Plan: Basic, Professional, Business
Tags: TLS, SSL

Did this answer your question?