When evaluating high availability options for SFTP and file transfer infrastructure, most platforms on the market lead with the same architectural assumption: achieving true active-active redundancy requires a dedicated external load balancer. For most production deployments, that assumption holds up well, and pairing an active-active SFTP cluster with a properly configured load balancer remains the preferred topology for organizations with the infrastructure and operational maturity to support one. What is less commonly discussed is what happens when that external dependency is not available, not yet justified, or simply not wanted, and whether active-active redundancy is achievable without it.
High availability means a system continues operating without interruption even when individual components fail. For SFTP server infrastructure specifically, this means trading partners, automated workflows, and internal systems should never experience a failed connection because one node in a cluster went down.
There are two common architectural approaches. Active-passive keeps one server actively serving traffic while a second server sits in standby, ready to take over if the active node fails. This is simpler to configure but means the passive node sits idle, consuming infrastructure cost without contributing capacity, and there is typically a delay, however brief, while the passive node detects the failure and activates.
Active-active keeps multiple servers running and serving traffic concurrently. If one node fails, the remaining nodes continue handling the load without any failover delay, because they were already active. This is the architecture most organizations actually want: no wasted capacity, no failover lag, and better overall throughput because the workload is distributed across all available nodes.
The most common and best-supported way to achieve active-active redundancy is to place a dedicated load balancer in front of the cluster, distributing incoming connections across the active nodes using algorithms such as round robin or weighted distribution. This is the approach used across most SFTP and managed file transfer platforms, including GoAnywhere MFT, JSCAPE MFT, and SolarWinds Serv-U, and for good reason: it is mature, well understood, and gives administrators fine-grained control over traffic distribution, health checks, and SSL termination.
For organizations that already operate load balancing infrastructure, or that have the operational capacity to manage a redundant load balancer pair, this remains the recommended topology. A well-configured, redundant load balancer setup in front of an active-active SFTP cluster is a proven, production-grade architecture used successfully across countless deployments.
The one caveat worth understanding clearly, because it shapes the rest of this discussion, is that the load balancer itself needs to be made redundant to avoid becoming a single point of failure in its own right. As system design analysis consistently notes, a single load balancer in front of a healthy cluster is still a single point of failure: if it goes down, every node behind it becomes unreachable regardless of node health. This is not a flaw unique to any vendor's implementation. It is simply a property of the architecture, and it is the reason serious load balancer deployments are themselves built in redundant pairs.
Analysis of single point of failure elimination puts the economics plainly: each time a single point of failure is eliminated, the cost and complexity of the system at least doubles. Making the load balancer layer itself redundant means a second load balancer, failover configuration between them, and an additional layer of infrastructure to patch, monitor, and maintain indefinitely, on top of the SFTP cluster it is routing traffic to.
Technical analysis of load balancing tradeoffs identifies configuration complexity, ongoing maintenance burden, and direct infrastructure cost as standard, expected consequences of running a load balancing layer well. None of this is a reason to avoid load balancers. It is simply the known cost of doing HA the proven way, and for many organizations that cost is entirely justified by the control and maturity the approach provides.
Where it becomes a genuinely relevant question is for organizations that do not have a load balancing tier already in place, that are standing up a smaller or simpler active-active deployment, or that want the option of true active-active redundancy without taking on a second piece of infrastructure purely to route traffic. For those cases, the relevant question becomes: is the load balancer a strict requirement for active-active redundancy, or is it the best practice with an optional, capable alternative underneath it?
Whichever topology an organization chooses, the reason high availability matters at all is that downtime is extraordinarily expensive, and getting worse every year. ITIC's 2024-2025 Hourly Cost of Downtime Survey found that 93% of organizations report that a single hour of downtime costs more than $300,000, with 41% of enterprises reporting hourly costs between $1 million and $5 million. EMA Research's 2024 analysis found that unplanned downtime now averages $14,056 per minute across organizations of all sizes, rising to $23,750 per minute for large enterprises.
For SFTP and file transfer infrastructure specifically, the downtime calculation is not abstract. A trading partner that cannot connect to submit a file, an automated workflow that depends on a scheduled transfer completing on time, a regulatory submission with a hard deadline: each of these translates a server outage directly into a business consequence, regardless of whether the outage originated in the SFTP cluster or in the infrastructure routing traffic to it.
Beyond the routing layer, high availability in distributed systems carries a category of failure modes that are difficult to anticipate because they only surface under real-world conditions over time: clock drift that appears during a daylight saving transition, a network partition that heals in the middle of a data sync cycle, a node that crashes between writing a change to its log and propagating that change to its peers. These failure modes exist regardless of whether a load balancer sits in front of the cluster, and they deserve as much scrutiny as the routing question.
Most HA implementations infer node health indirectly, from whether data synchronization is succeeding. This creates a specific blind spot: if a node has nothing new to synchronize, there is no communication at all, and silence becomes indistinguishable from unavailability. A more robust design separates health detection from data replication entirely, using a lightweight, continuous heartbeat that runs independently of whether any data has changed. This gives the cluster an accurate, current picture of which nodes are reachable at all times, rather than a picture that is only as fresh as the last sync event.
Clock synchronization is another frequently underestimated failure mode. Timestamp-based HA coordination depends on synchronized clocks across every node, and clock drift that goes undetected can cause subtle data inconsistencies that are difficult to diagnose after the fact. A more rigorous approach continuously verifies clock accuracy throughout operation, not only at startup, and can identify which specific node is the source of drift rather than merely detecting that a discrepancy exists somewhere in the cluster. A node that determines it is drifting can quarantine itself from pushing further changes, preventing inaccurate data from propagating to the rest of the cluster.
Rolling upgrades introduce their own risk. A cluster running a binary or proprietary wire format for inter-node communication can fail silently when the data structures on two nodes diverge during an upgrade window. A versioned, human-readable wire format that ignores unknown fields gracefully and detects protocol version mismatches explicitly turns a silent corruption risk into a clean, reportable event.
High availability is typically framed purely as an uptime and resilience problem, but the communication between cluster nodes is itself a security surface that deserves the same scrutiny as any other network traffic. Every message exchanged between nodes in a cluster is an opportunity for tampering or replay if it is not properly authenticated.
A rigorous implementation cryptographically signs every inter-node request, covering the full request body, with a timestamp embedded in the signature specifically to prevent replay attacks. Combined with encrypted transport, this closes a class of inter-node threat scenarios that less security-conscious HA implementations leave open. High availability and security are not separate concerns in a well-designed cluster. They are the same engineering discipline applied to different failure modes.
Some SFTP platforms build active-active clustering directly into the server software itself, with the nodes coordinating session state, configuration synchronization, and automatic recovery through their own inter-node protocol. This does not replace the recommendation to use a load balancer where one is already part of the infrastructure. It does mean that, where a load balancer is not in place, active-active redundancy is still genuinely available rather than requiring a fallback to active-passive or a delayed HA rollout while load balancing infrastructure is procured and configured.
In practice, this means a platform built this way can remain fully functional with nothing as simple as DNS round robin in front of it, while still supporting a dedicated load balancer for organizations that prefer that topology. The load balancer becomes an optional addition for those who want the extra control it provides, rather than a strict prerequisite for active-active redundancy to exist at all.
There is a second, related capability worth understanding on its own merits: the number of nodes required before a cluster can guarantee consistency. Most distributed systems rely on majority consensus to agree on the current state, which means at least three nodes are typically required, since two nodes can never produce a tie-breaking majority on their own. A platform that can guarantee strong consistency between exactly two active nodes, without requiring a third node purely to break ties, has solved a harder distributed-systems problem than most HA implementations attempt, while still scaling to three or more nodes for organizations that want a larger cluster. This matters specifically for smaller deployments that want genuine active-active redundancy without the cost of a third node whose only function is breaking ties.
For organizations with load balancing infrastructure already in place, pairing it with an active-active SFTP cluster remains the recommended, best-supported deployment topology, and nothing in this discussion changes that. The value of a platform that can also run active-active without an external load balancer shows up in different, narrower circumstances: smaller deployments where standing up a redundant load balancer pair is disproportionate to the workload, organizations evaluating their first HA deployment and wanting to avoid taking on two new pieces of infrastructure simultaneously, or environments where DNS-based routing is simpler to operate than a dedicated load balancing tier.
The broader point worth taking away is that the engineering quality of an HA implementation is not fully captured by whether it supports active-active. Most platforms on the market do. The more useful questions, regardless of which routing topology is chosen, are how the cluster detects node health, how it handles clock drift, how it secures communication between nodes, and what happens during a rolling upgrade. A platform that addresses health detection independent of data sync, cryptographically authenticated inter-node communication, and a wire format that survives version mismatches gracefully has addressed the harder, less visible engineering problems that most HA evaluations skip over entirely, whatever sits in front of the cluster routing traffic to it.
