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 / 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.