Do You Actually Need a Load Balancer?

Keep a single VPS simple until you have a reason to expand

The common belief is that putting an app into production means putting a load balancer in front of it. That does not hold when every request still ends up at the same application instance. Another forwarding service cannot provide spare capacity or a surviving backend that does not exist.

For a small app on Ubuntu 24.04 LTS, we would start with a reverse proxy on the VPS, forwarding requests to an application listening locally. Use a service manager to restart failed processes, and make recovery from a lost machine a documented procedure. Accept the single server as a deliberate availability tradeoff.

A reverse proxy can terminate HTTPS and route different hostnames to different applications. Load balancing adds a choice between interchangeable backends for the same service. The same software can perform both jobs, as explained in where reverse proxies, load balancers and CDNs belong.

That distinction prevents a common purchasing mistake: treating a separate load balancer as a certificate of production readiness. Your first investment should address the failure that would actually hurt you. If restoring the database is still guesswork, another traffic hop is unlikely to be your most useful next change.

Choose based on the problem you need to solve

Start with an observed bottleneck or an explicit availability requirement. An app that spends most of its request time waiting on a slow database query will not become fast because requests arrive through another proxy. More application replicas can make that database work harder.

Scaling the VPS upward is often the simpler response to genuine application resource pressure. It preserves your deployment model and avoids introducing distributed application state. Choose replicas when that simpler option cannot meet your capacity needs, or when server maintenance must happen while the service stays available.

Do not pick a traffic threshold from someone else's architecture diagram. Expensive dynamic requests behave differently from cached pages, and traffic bursts behave differently from steady demand. Use minimum viable server monitoring to connect slow requests with the resource or dependency holding them up.

Use your existing proxy before adding another service

You may already have the software you need. Caddy supports multiple upstream backends and configurable health checks within its reverse proxy. Its reverse proxy documentation describes those controls, including which checks must be enabled explicitly.

Nginx can also distribute requests across an upstream group. Its HTTP load balancing documentation explains backend selection and passive failure handling. If either proxy already serves your application reliably, adding another proxy product needs a specific justification.

For a new single VPS, we would usually start with Caddy for straightforward HTTPS operation; keeping an established Nginx setup is equally reasonable. The Caddy versus Nginx decision guide covers that choice. Switching proxies solely to obtain basic load balancing is usually unnecessary.

Separate the software decision from the placement decision. A proxy balancing application processes on its own VPS can help with process failures and deployment handoffs, but losing that VPS still loses the service. A separate proxy server moves the entry point elsewhere while leaving that entry point dependent on a single machine.

When you genuinely need host failure tolerance, we would generally choose a managed load balancer with documented redundancy over operating a redundant proxy pair ourselves. That recommendation assumes its networking and failure behavior match your application. Check those details before treating the managed service as an availability improvement.

Make application replicas interchangeable first

A second application process is useful only if it can correctly handle the next request. Imagine a login stored in one process's memory: the following request reaches another process and appears unauthenticated. The load balancer has distributed traffic correctly while exposing an application assumption.

• Sessions: use a shared session store or an appropriate signed token design, with consistent signing keys across replicas.
• Uploads: make durable files available to every replica that needs them; a local upload directory does not become shared automatically.
• Database connections: budget the combined connection pools so adding replicas does not exhaust the database.
• Scheduled work: keep recurring jobs under explicit ownership, or use coordination that prevents duplicate execution.
• Releases: keep overlapping application builds compatible with the database schema and shared data they both use.

Sticky sessions can keep a client associated with a backend, but they do not copy that backend's memory to a replacement. Use affinity when the application specifically requires it, with a clear recovery behavior. Do not treat it as a substitute for making important state survive backend loss.

WebSocket connections need separate attention because an established connection stays with its backend. Removing that backend from new traffic does not move existing connections elsewhere. Decide how clients reconnect and recover their application state before promising uninterrupted operation.

Identify the failures your design will still have

Load balancing improves availability only for failures that leave a usable route to a healthy backend. Multiple application servers still depend on whatever they share. If every request requires the same unavailable database, choosing another application server changes nothing.

The surviving backends also need enough spare capacity to handle the displaced work. A pool that operates comfortably only while every backend is present may collapse after one disappears. Validate the reduced pool under representative demand before relying on failover.

Define health as readiness to serve useful requests, rather than merely having an open network port. Keep readiness checks cheap and bounded, and understand what happens when a shared dependency fails. A check that removes every backend during the same dependency outage cannot manufacture a healthy destination.

Restrict backend ingress to the intended proxy path and any explicitly authorized monitoring path. Otherwise, direct requests can bypass controls applied at the load balancer. Configure forwarded client headers so the application trusts only known proxies, rather than accepting identity claims from arbitrary connections.

Verify handoff and failure behavior before relying on it

If deployment interruption is your actual problem, start with overlapping application instances and a controlled handoff. You can do that on the same VPS if it has enough headroom, while accepting that host failure still stops the service. The VPS deployment handoff guide develops that approach.

First, use a staging environment to send representative requests through the proposed entry point to every backend. Include an authenticated workflow and any operation that writes durable data. Add backend identity to internal logs so you can confirm which instance handled each request.

Next, remove a backend from eligibility for new requests while leaving it running to finish existing work. Start its replacement and admit traffic only after readiness succeeds. Set a bounded drain period, with an explicit policy for connections that outlive it.

Then stop an application backend in staging without draining it. Observe how long detection takes and what clients experience before the backend is excluded. Repeat with a backend that accepts connections but responds slowly, because a hung service can behave differently from a stopped process.

Finally, examine retry behavior for requests that change data. A backend can commit a write and lose the connection before returning its response, leaving the proxy uncertain about the outcome. Use application idempotency where retries are required; do not enable broad retries to make error graphs look cleaner.

Write the requirement before changing your traffic path

Your next step is to write the specific condition your current setup cannot satisfy. A useful requirement is that a routine application deployment must not interrupt ordinary requests, or that losing an application server must leave the service usable. Attach an observable acceptance check to that requirement.

If you cannot identify that condition, keep the single VPS and inspect your current bottleneck before adding infrastructure. If deployment interruption is the condition, create a staging handoff with overlapping instances. If host loss is the condition, draw the complete request path and identify every shared dependency before choosing the entry point.

We would use Claude Code to review a sanitized configuration and draft the proposed routing change, including a rollback procedure. Keep that task read-only until you have reviewed the diff, and require approval before production traffic changes. Apply the boundaries in production guardrails for AI agents, then carry out the staging checks above.