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).
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.
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/:
https://myapp-myorg.koyeb.app/api/list will be received by the
service as https://myapp-myorg.koyeb.app/listhttps://myapp-myorg.koyeb.app/api/resource/list will be received by the
service as https://myapp-myorg.koyeb.app/resource/listTo 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.
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.
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.
The content cached for your service is invalidated after each successful deployment.
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.
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