> For the complete documentation index, see [llms.txt](https://docs.reo.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.reo.dev/faqs-and-troubleshooting/things-to-know-about-gateway-availability-and-sla.md).

# Things to know about gateway availability and SLA

Reo's redirection gateway sits in front of your Docker images and Helm charts so you can identify which account is downloading your packages. This page explains how the gateway is built for availability, what latency it adds, and the uptime Reo commits to.

For how the redirection itself works, see [Docker](https://docs.reo.dev/integrations/input-sources/developer-insights/docker#reo.dev-docker-helm-redirection) / [Helm.](https://docs.reo.dev/integrations/input-sources/developer-insights/helm)

### **Where the gateway sits in the request path**

The gateway is a redirection layer and not a package host. Reo does not store or serve your package bytes. When a developer runs a pull against your custom domain, the gateway issues a 307 redirect to the original registry, and the registry serves the actual download.

This is the key point for availability. The gateway is only in the path for the initial redirect, which is a small, fast request. The download itself, transferring the image or chart, happens directly between the developer and your original registry (Docker Hub, GitHub, GitLab, or wherever you host today)

### **Performance**

The redirect adds a few milliseconds to the pull. It is a single lightweight hop that resolves the custom domain and returns a 307 to the registry, and it resolves at the network edge location nearest the developer, so it stays fast worldwide. Developers see no meaningful change in pull times, and download speed is unchanged because the bytes still travel directly between the developer and your registry.

### **Uptime SLA**

Reo commits to **99.95% uptime** for the redirection gateway.

### **Multi-region request handling**

Reo runs the redirection gateway on a global edge network, using Amazon CloudFront with Lambda\@Edge. Requests are handled at the CloudFront edge location nearest the developer rather than routed to a single region. This keeps redirects fast worldwide and adds strong redundancy behind the uptime commitment.

The edge network provides automatic failover. If an edge location or region has an issue, CloudFront routes around it on its own, with no manual intervention. Redirects do not depend on the uptime of any single set of servers, so restarts, deploys, or a full cluster outage do not affect package pulls. This is effectively automatic disaster recovery with no failover step on your side or Reo's.

### **Scale**

The gateway is built to handle high request volumes. Because it only issues redirects and never proxies package bytes, it scales independently of package size and download bandwidth. Running on CloudFront means the edge network absorbs traffic spikes automatically, so large bursts of pulls are handled without any capacity planning on your side.

### **What happens during an outage**

Two things limit the impact of a gateway issue:

1. Your packages are never only on Reo. They remain hosted on your original registry. Developers who use the original pull command are unaffected.
2. The redirect layer is decoupled from hosting, so a gateway problem cannot delete, corrupt, or lock your packages.

### Summary

| Question                                | Answer                                                                            |
| --------------------------------------- | --------------------------------------------------------------------------------- |
| Does Reo host my packages?              | No. Reo issues a redirect. Your registry serves the download.                     |
| How much latency does the redirect add? | Less than 2 milliseconds                                                          |
| What uptime does Reo commit to?         | 99.95%.                                                                           |
| Is the gateway multi-region?            | Yes. Requests are served at the nearest CloudFront edge, with automatic failover. |
| What happens if the gateway is down?    | Package bytes are unaffected. Direct pulls from the original registry still work. |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.reo.dev/faqs-and-troubleshooting/things-to-know-about-gateway-availability-and-sla.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.