Reverse Proxy
A server that forwards incoming client requests to the appropriate backend service.
A reverse proxy is a server that sits in front of one or more backend services and forwards incoming client requests to the appropriate service, returning the response back to the client as if the proxy itself had produced it. Clients connect to the reverse proxy, not directly to the backend services it fronts.
How it works
A reverse proxy typically receives a request on a public-facing address, inspects details such as the hostname, path, or headers, and routes the request to the correct backend service running elsewhere, often on an internal network the client cannot reach directly. Along the way it commonly handles tasks that would otherwise need to be duplicated in every backend service: TLS termination, meaning it decrypts HTTPS so backend services can speak plain HTTP internally, load balancing across multiple instances of a service, and centralized request logging.
Reverse proxy vs forward proxy
A forward proxy, which includes an egress proxy, sits in front of clients and controls or filters what those clients can reach on the outside, acting on behalf of the requester. A reverse proxy sits in front of servers and controls what the outside world can reach inside a network, acting on behalf of the destination. In a typical self-hosted deployment, both may be present: a reverse proxy manages inbound traffic to the platform's public services, while an egress proxy manages outbound traffic from any workloads, such as AI agent containers, that need controlled internet access.
Why it matters for AI agent platforms
A platform running several services, such as a control plane API, a web console, and supporting services, needs a single, consistent entry point for inbound traffic rather than exposing each service on its own port with its own TLS configuration. A reverse proxy provides that single entry point, handling TLS and routing centrally, which also means backend services, including anything with access to sensitive operations, are not directly reachable from the internet at all: only the reverse proxy is.
Agenhood's implementation
Agenhood uses Traefik as its reverse proxy in production, handling TLS termination and routing requests to the appropriate backend service, such as the control plane or web console, running on the same single-VM Docker Compose deployment. This keeps individual services off the public internet directly, with Traefik as the only component that needs to be publicly reachable.