# Ingress And Routing Model (/docs/runtime/ingress-and-routing-model)



Runtime uses several cooperating components to expose services safely and predictably.

Main Roles [#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 [#typical-traffic-path]

A common Runtime request path looks like this:

1. a hostname is published through **External DNS**
2. TLS is managed through **cert-manager**
3. traffic reaches a service exposed by **MetalLB**, **NGINX**, or **APISIX**
4. routing, proxying, and policy logic are applied
5. the request is forwarded to the target Runtime or higher-layer service

NGINX And APISIX [#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 [#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.