Reverse Proxy vs Load Balancer vs CDN: What Goes Where

Separate the jobs before selecting a service

A load balancer is a service that distributes incoming traffic across application instances. For a small team, the practical question is whether you have another instance that can handle the request. Putting a load balancer in front of your only application process does not create spare capacity or a replacement when that process fails.

A reverse proxy accepts a client's request and forwards it to an application on the client's behalf. It gives you a public entry point where you can terminate HTTPS and route requests by hostname or path. When it selects between interchangeable application instances, it is also doing load balancing.

A content delivery network, or CDN, places serving locations between visitors and your origin, the server that supplies the original content. It can answer eligible requests from cache instead of contacting your VPS each time. A CDN commonly acts as a distributed reverse proxy, but caching content and selecting a healthy origin are separate capabilities.

These are responsibilities, so they do not require separate products. Nginx can proxy HTTP requests and distribute them across an upstream group within the same configuration. Its HTTP load-balancing documentation describes that overlap directly.

Start a single VPS with a reverse proxy

On a single VPS running Ubuntu 24.04 LTS, we would start with a reverse proxy on the host and an application listening on loopback. Public web requests reach the proxy, which forwards them to the local application. Keep the application port out of the public firewall rules, and check container port publishing separately if you use containers.

This arrangement gives the application a stable public address while its local process can change. You can route a second hostname to a different application without exposing another public application port. Routing a blog and an API to different services is reverse proxying; those services are not interchangeable members of a load-balancing pool.

We would consider Caddy for a new, straightforward configuration and keep Nginx where the team already understands its configuration and operation. Familiarity matters when a reload fails during a deployment. Use the Caddy versus Nginx comparison to make that implementation choice after deciding which responsibilities the proxy needs.

A proxy on the same VPS remains dependent on that VPS. It can keep accepting connections while an application restarts, but without a usable backend it cannot deliver the application's normal response. Treat a maintenance response as a deliberate fallback, and decide whether a short deployment interruption is acceptable before building around it.

Add load balancing for an actual second backend

Add load balancing when you need to distribute work across interchangeable application instances or remove an instance from service during deployment. Each backend must be able to handle the requests assigned to it. A second process that cannot access the required state is not a useful substitute for the first.

Multiple processes on the same VPS can help you deploy with less interruption or use available compute capacity. They still share the host's failure boundary. Surviving loss of the VPS requires a working backend elsewhere and a public entry point that remains available when that VPS disappears.

Check application state before adding another backend. A session stored only in local memory may disappear when the next request reaches a different process, and a locally stored upload may be missing there. Sticky sessions can reduce switching between backends, but they cannot recover state from a failed machine.

Health checks determine whether a backend should receive new work. A readiness endpoint should report whether the instance can serve its intended requests, with dependency checks chosen carefully so that an unrelated failure does not remove every backend. Caddy supports configurable active and passive checks through its reverse proxy directive; configure the behavior explicitly.

For deployment, stop assigning new work to an instance, allow existing work to finish within a defined limit, then replace it. Long-lived connections need a reconnect strategy, and retrying a request that changes state can duplicate an operation unless the application handles that safely. Work through whether you actually need a load balancer before accepting these additional operating responsibilities.

Use a CDN where responses can be shared safely

A CDN is useful when visitors repeatedly fetch the same public content and the edge can serve that content without consulting your application. Versioned static assets are a sensible starting point because the filename changes when the content changes. A cache hit avoids an origin fetch; a cache miss still depends on the origin or another configured cache tier.

Do not assume that putting a hostname behind a CDN makes every response cacheable. Cloudflare does not cache HTML or JSON by default, although cache rules can change that behavior. Check its default cache behavior before interpreting a proxied request as a cached request.

Start with an explicit boundary between public assets and personalized responses. Keep authenticated pages and private API responses out of shared caches unless you have designed and verified the cache rules for them. A rule that ignores a session cookie or an authorization header can turn a performance change into exposure of another user's data.

Caching also changes how you publish corrections. A response may remain visible until it expires or you invalidate it, so decide how content updates reach visitors before extending caching to public HTML. Preserve older versioned assets long enough for already-open pages to continue loading their dependencies.

A CDN may offer additional traffic filtering, but that does not make the origin unreachable through other paths. If you rely on edge filtering, restrict origin web access to the intended ingress and maintain those rules. Cached assets may remain available during an outage, while requests requiring your application still fail.

Draw the request path and mark each trust boundary

Write down the path a request actually takes before adding another component. DNS tells the client where to connect; it does not necessarily sit in the request path after resolution. With a proxied CDN hostname, the client connects to the edge, which contacts your origin when it needs an origin response.

Mark where HTTPS terminates and how the next connection is protected. Browser-to-edge encryption does not establish the security of the edge-to-origin connection. With Cloudflare, use HTTPS and Full (strict) origin certificate validation, with an unexpired certificate that matches the origin hostname and is trusted by Cloudflare.

Also mark which component supplies the client address and original request scheme. Forwarded headers are assertions from another system, so configure the application to trust only the proxies that should supply them. Trusting arbitrary client-supplied headers can corrupt access logs or undermine address-based controls.

An HTTP load balancer can make routing decisions using request details such as the hostname. A transport-level load balancer works with connections and does not need to decrypt HTTP traffic to forward them. Choose the behavior your application requires; a CDN's ordinary web proxy should not be assumed to forward arbitrary non-web services.

Match the next component to the failure you need to fix

Describe the current problem in observable terms before selecting another service. If requests spend most of their time waiting on a database query, distributing them across more application processes may increase pressure on the same database. If public asset transfers dominate origin traffic, caching those assets addresses a different problem.

• You need HTTPS and several hostnames on one VPS: use a reverse proxy with explicit routes.
• Deployments interrupt requests: consider overlapping application instances with readiness checks and draining.
• Repeated public downloads burden the origin: introduce CDN caching for those responses.
• You must survive loss of an application host: provide a backend on another host and an independently available ingress path.
• All instances wait on the same dependency: investigate that dependency before expanding the application pool.

A dedicated load-balancer VPS can become another single point of failure. A managed load-balancing service can reduce the work of operating that entry point, but you still own backend readiness and application behavior. Confirm the service's failure model instead of treating the product name as an availability guarantee.

Observe the public path and the origin separately so you can distinguish an edge problem from an application failure. Include a dynamic request in your external checks, because a cached homepage can remain healthy while the application is unavailable. The minimum monitoring setup for a small fleet helps you gather evidence before changing the architecture.

Give Claude Code bounded configuration work

We would use Claude Code to inspect proxy configuration and prepare a narrow change with a rollback plan. Give it the intended request path and the specific symptom you need to resolve. Ask it to identify assumptions about backend readiness or caching before it changes either behavior.

Keep production authority separate from investigation. An agent reviewing an upstream route does not need permission to rewrite DNS or loosen the origin firewall. Use production guardrails for AI agents to scope access and require review of changes that affect public traffic.

Require a configuration diff and the proxy's native validation result before a reload. Validation can catch configuration errors, but it cannot establish that a login session survives backend switching or that private responses bypass the cache. Those checks must exercise application behavior through the intended public path.

Make one routing change at a time and keep the previous working configuration available. If an agent suggests increasing retries to hide intermittent failures, first establish whether the affected requests are safe to repeat. A cleaner error graph is not evidence that user operations completed correctly.

Write your ingress decision and verify it

First, record your current request path and the failure you are willing to tolerate. For a new single VPS, use a host reverse proxy as the starting decision and explicitly acknowledge that host loss makes the application unavailable.

Next, verify the public route from a machine outside the VPS. Request the intended hostname over HTTPS, exercise a dynamic application endpoint, and confirm that the application listener is not publicly reachable.

If you add a CDN, request a public asset repeatedly and inspect the provider's cache-status response header. Separately check an authenticated route using distinct test sessions, then publish an asset change to verify your invalidation or filename strategy.

If you add multiple backends, rehearse removing one from service in a staging environment before changing production. Confirm that readiness controls new traffic and that the remaining backend preserves a test user's session and completed writes.

Put the chosen configuration and its rollback procedure into your deployment notes now. Name the observation that would justify the next component, such as deployment interruptions or repeated public asset fetches, so your next infrastructure change starts with evidence.