> ## Documentation Index
> Fetch the complete documentation index at: https://unkey.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Request lifecycle

> Trace the full request lifecycle from when a request hits your URL through Sentinel policies, routing, and load balancing to your app.

<Info>
  Unkey Deploy is in public beta. To try it, open the product switcher in the
  top-left of the dashboard and select **Deploy**. During beta, deployed
  resources are free. We're eager for feedback, so let us know what you think
  on [Discord](https://unkey.com/discord), [X](https://x.com/unkeydev), or
  email [support@unkey.com](mailto:support@unkey.com).
</Info>

This page walks through every stage a request passes through on its way to your app.

## DNS

Unkey uses latency-based geolocation routing to resolve both `*.unkey.app` [wildcard domains](/networking/wildcard-domains) and [custom domains](/networking/domains) to the closest region to the client.

## Frontline

The request arrives at Frontline, Unkey's global network layer. Frontline terminates TLS close to the client, so your app never needs to manage certificates. All connections enforce TLS 1.2 or higher, with TLS 1.3 preferred. HTTP requests are redirected to HTTPS automatically.

Certificates are provisioned and renewed automatically for both wildcard and custom domains.

After terminating TLS, Frontline resolves the requested domain to a deployment. It consults a globally replicated metadata store that maps every domain to a deployment ID. If the target deployment runs in a different region, Frontline forwards the request to that region automatically.

## Sentinel

Frontline forwards the request to Sentinel, the application gateway. Sentinel runs the policies configured for the deployment before the request reaches your code:

* [Authentication](/platform/sentinel/authentication) verifies the caller's identity
* [Rate limiting](/platform/sentinel/policies/rate-limiting) enforces request quotas
* [Custom policies](/platform/sentinel/policies) apply additional rules

Requests that fail a policy receive an error response from Sentinel without reaching your app.

After policies pass, Sentinel selects a healthy instance of your deployment and proxies the request to your app. The response flows back through Sentinel and Frontline to the client.

### Request headers

Sentinel adds headers to every proxied request so your app can identify the original client and request context:

| Header              | Description                                                                |
| ------------------- | -------------------------------------------------------------------------- |
| `X-Forwarded-For`   | The original client IP address                                             |
| `X-Forwarded-Host`  | The original `Host` header from the client request                         |
| `X-Forwarded-Proto` | The protocol used by the client (`https`)                                  |
| `X-Deployment-Id`   | The deployment ID that Frontline resolved from the domain                  |
| `X-Unkey-Principal` | The authenticated principal, populated by Sentinel's authentication policy |