Ingress And Routing Model
How Runtime exposes services and routes traffic.
Runtime uses several cooperating components to expose services safely and predictably.
Main Roles
| Component | Main role |
|---|---|
| MetalLB | provides external load-balancer behavior in self-managed environments |
| NGINX | handles ingress for web-facing services and general endpoint exposure |
| APISIX | acts as the API gateway and policy enforcement point |
| External DNS | publishes DNS records for exposed services |
| cert-manager | manages certificates and TLS lifecycle |
Typical Traffic Path
A common Runtime request path looks like this:
- a hostname is published through External DNS
- TLS is managed through cert-manager
- traffic reaches a service exposed by MetalLB, NGINX, or APISIX
- routing, proxying, and policy logic are applied
- the request is forwarded to the target Runtime or higher-layer service
NGINX And APISIX
Both NGINX and APISIX appear in the Runtime stack, but they are not identical.
- NGINX is typically used as the ingress layer for web services and UI endpoints.
- APISIX is used where API gateway behavior is required, especially for richer traffic control and API-facing security patterns.
Why This Matters
The routing model is one of the most visible parts of Runtime because it defines how users, systems, and services reach the platform. It is also one of the main places where network exposure, DNS, TLS, and access control come together.