Edge Network: load-balancing, TLS, and caching

Understand the Koyeb edge network and how to access your Apps from the internet.

All your Apps automatically benefit from our global edge network. Apps get a free subdomain of koyeb.app looking like <appname-orgname>.koyeb.app which is routed via our Global Edge Network. Our Global Edge network provides native load-balancing, TLS encryption, and caching (like a CDN).

HTTP Load-balancing

Our edge network provides global load-balancing capabilities.

If you deploy a service in multiple regions, requests will be routed to the nearest edge location to the end-users. The request will then be routed to the nearest core location where you deployed your service.

Proxy Routing and HTTP Path

When you deploy a new Service and want to make it accessible publicly, you need to define on which port it listens and on which HTTP Path your Service should be exposed. All requests will be proxyfied to the port you selected and load-balanced between your instances.

Routing rules are evaluated at the Edge to route requests to the right core location depending on where the service lives.


If you route a sub-path (i.e. /api/) and not the root (/) of your domain, the prefix will be removed when the request reaches your service.

For instance, let's assume that your app domain is myapp-myorg.koyeb.app and you decide to expose your service on /api/.

Requests performed on https://myapp-myorg.koyeb.app/api/ will be seen by your service as being made on https://myapp-myorg.koyeb.app/:

  • A request made on https://myapp-myorg.koyeb.app/api/list will be received by the service as https://myapp-myorg.koyeb.app/list
  • A request made on https://myapp-myorg.koyeb.app/api/resource/list will be received by the service as https://myapp-myorg.koyeb.app/resource/list

Health Checks

To make sure your Services are always up and running, Koyeb automatically performs health checks on your services. Health checks are currently done using TCP connections, the service is marked as healthy if the TCP handshake fully completes. Health-checks are performed every 10 seconds.

Built-in TLS

When you create an app with a public service, end-users connections to your service are automatically encrypted with TLS. The TLS connections are terminated at the edge to increase performances and are securely transported inside of our encrypted Service Mesh to your application.

CDN and Caching at the Edge

Koyeb caches content according to your headers. Your content is automatically cached in 55 edge locations depending on your users' locations.


For our edge network to properly cache your content, you need to properly set Cache-Control headers. If you're not familiar with Cache-Control header, check our post on Using Cache-Control and CDNs to Improve Performance and Reduce Latency.

Cache invalidation

The content cached for your service is invalidated after each successful deployment.

Koyeb headers

Koyeb automatically sets standard x-forwarded-for and x-forwarded-host headers for your application to know the IP of the client and the domain which was requested.

We respect the standard for x-forwarded-for headers and append the IP which was used to connect to Koyeb at the end of the header. From a security perspective, the last IP of the x-forwarded-for is the only IP we can certify as valid.

Unencrypted HTTP connections

HTTP connections are permitted and are not automatically redirected to HTTPS by our edge network.

If you use a standard .koyeb.app domain, browsers will automatically use HTTPS as the .app top-level domain is included on the HSTS preload list. HTTP connections can be made using a CLI tool like curl or in your code.

If you would like to redirect all HTTP traffic to HTTPS, you can vote and track for this feature on our public roadmap: Option to redirect HTTP to HTTPS