We compared 8 SFTP server implementations in a controlled test environment, focusing on transfer performance, concurrency, connection overhead, small-file workloads, resource efficiency, and operational experience.
If you already use SFTP but want a more enterprise-ready file transfer approach, consider MFT solutions.
SFTP server software benchmark results
Transfer performance
Operational cost
Note: Lower scores indicate better performance.
Read the methodology to learn about our test environment and scoring processes.
SFTPGo
SFTPGo is a Go-based SFTP server distributed as a standalone binary, with configuration available through JSON, environment variables, a web administration interface, and a REST API. It supports local storage, S3, Google Cloud Storage, and Azure Blob backends, and includes operational features such as quotas, event rules, two-factor authentication, and Prometheus metrics.
Figure 1: SFTPGo login example.
It required minimal setup during the benchmark. The main issue was a default per-host connection limit that rejected writes during the small-file test, but disabling that limit resolved the problem.
Once configured, SFTPGo combined high transfer performance with the lowest handshake latency in the tested group (25 ms at p50, less than half the next-fastest server) and low per-session memory consumption (0.091 MB, roughly 145× below OpenSSH). Its multi-stream performance also scaled well without adopting a process-per-connection model. That combination made it the strongest general-purpose result in this benchmark.
Figure 2: SFTPGo admin dashboard.
HPN-SSH
HPN-SSH is a performance-oriented OpenSSH derivative. It installs alongside the system OpenSSH binaries and retains essentially the same configuration model, adding HPN-specific behavior intended primarily for high-bandwidth, high-latency networks. For administrators familiar with OpenSSH, the operational differences are small.
The package automatically started an hpnssh.service during installation, which occupied the port assigned to the OpenSSH benchmark instance until the service was stopped and masked. Aside from that conflict, it behaved similarly to OpenSSH.
It delivered the highest single-stream upload result (167.4 MB/s, though MINA at 166.9 MB/s and SFTPGo at 165.3 MB/s finished within 1.3%) and the fastest process startup in the benchmark (0.88 s), but inherited OpenSSH’s fork-per-connection memory model. Under the imposed 6 GB memory limit, it failed when the concurrent-session test reached 300 connections.
The benchmark ran entirely over loopback, so it does not test the environment in which HPN-SSH is specifically designed to distinguish itself. Near-zero network latency removes most of the bandwidth-delay-product constraint that its larger-window modifications target. Its WAN advantage therefore remains outside the scope of these results.
Apache MINA SSHD
Apache MINA SSHD differs from the others because it is a Java library, unlike a ready-to-run SFTP server. For the benchmark, we had to write a server using the sshd-core and sshd-sftp components and then build it as a standalone JAR with Maven. The application controls host keys, authentication, SFTP support, and cipher configuration, rather than a conventional server configuration file.
This introduced more setup work than any packaged daemon. The build required an explicit modern Java compiler target, and Ed25519 authentication needed an additional dependency. The standard authorized-key authenticator also rejected the benchmark key file because of its permission checks, so the test server used a custom key comparison path.
Once running, however, MINA performed well: it produced the strongest download result (172.4 MB/s), low memory consumption per session, and the second-best CPU efficiency measured in the resource-efficiency test (132.8% per Gbps, behind OpenSSH’s 119.4%). The main runtime penalty was JVM startup time (3.39 s to first connection). It is therefore a compelling implementation component for applications that need an embedded SFTP endpoint, but not a direct substitute for an administrator-oriented SFTP product.
OpenSSH
OpenSSH served as the reference implementation. It was present on the Ubuntu test system and required no additional server installation. SFTP is exposed through internal-sftp, while users, public keys, chroot rules, and access controls use the standard OpenSSH account and sshd_config mechanisms.
The operational issues were familiar OpenSSH problems, not instability in the SFTP subsystem itself. Incorrect ownership or permissions triggered StrictModes, and the HPN-SSH systemd service initially occupied the benchmark port. After removing that conflict, the server ran consistently.
OpenSSH handled the small-file workload better than any other tested implementation (4,466 files per second, 42% ahead of the next-fastest server) and recorded the lowest CPU cost per unit of throughput at 119.4% per Gbps, but its fork-per-connection architecture used comparatively more memory per active session (13.283 MB).
Its large-file throughput results require an additional qualification: this benchmark instance wrote into the system user’s home directory on disk, while the other tested servers used tmpfs. Its T1 and T2 absolute throughput values and the CPU-per-Gbps figure normalized against them, therefore, should not be treated as directly equivalent to the rest of the field.
ProFTPD
ProFTPD provides SFTP through mod_sftp. It does not treat SFTP as its primary protocol. Its Apache-style configuration system is mature and flexible, and the broader server can combine FTP, FTPS, and SFTP with SQL or LDAP authentication and granular access controls.
It was also the most troublesome server to configure during this benchmark. mod_sftp had to be loaded explicitly, the default overwrite policy blocked uploads, shell validation affected the benchmark user, and a stale ProFTPD process prevented a subsequent instance from binding to its port.
Its SFTP path produced the lowest download throughput (77.2 MB/s) and by far the highest handshake latency among the measured servers (423 ms at p50, 3.6× the next-slowest). The exception was parallel-stream scaling: aggregate throughput increased substantially as concurrency rose, reaching 3.51× single-stream at four streams, giving ProFTPD the strongest scaling ratio in that test. These results make more sense in environments that need its mature multi-protocol capabilities than in deployments choosing a server specifically for SFTP performance.
SFTPPlus
SFTPPlus is a commercial managed file transfer platform built on Python and Twisted. It ships with its own Python runtime and uses a readable INI-based configuration format. In addition to SFTP, it supports FTPS, HTTPS, and WebDAV, along with administrative, automation, audit, directory-integration, and high-availability functions expected from an MFT product.
Installation itself was straightforward, but process management introduced several benchmark-specific problems. Starting as root required an explicit account setting, the foreground launcher depended on running from the installation directory, and the runtime process name differed from what the initial monitoring logic expected.
Performance reflected different priorities than the throughput-oriented servers: SFTPPlus had exceptionally low incremental memory consumption per session (0.028 MB, the lowest measured) and good connection-establishment latency (52 ms at p50), but relatively slow large-file uploads (41.8 MB/s), small-file handling (244 files per second), and process startup (7.49 s, more than double the next-slowest server).
Wing FTP Server
Wing FTP Server is a commercial native server with a web-based administration interface and support for FTP, FTPS, SFTP, HTTP, and HTTPS. Configuration is organized around domains and users, with the web interface serving as the primary management path; XML configuration and a Lua-based console interface are also available.
Figure 3: Wing FTP admin dashboard.
The GUI was easier to approach than most text-based configurations, but several behaviors complicated automation. The Lua domain-creation call repeatedly failed without a useful error; it rejected an Ed25519 client key. At the same time, RSA-3072 worked, and a home-directory mapping created through the GUI did not persist until we added it manually.
Measured performance was notably asymmetric: downloads were considerably faster than uploads (129.7 MB/s against 34 MB/s, a 3.8× gap and the lowest upload figure in the benchmark), small-file processing was the slowest in the group (90 files per second, against 244 for the next-slowest), and CPU consumption relative to achieved throughput was high (433.7% per Gbps, nearly double the next-highest server). Session memory usage, by contrast, remained low (0.107 MB) because the server uses a threaded rather than fork-per-connection architecture.
Figure 4: Wing FTP user editor.
CrushFTP
CrushFTP 11.5.2 was installed successfully and accepted SFTP connections using Ed25519 public-key authentication, but it could not be included in the performance comparison. Every upload failed with a server-side 550 openFile error:Denied! response despite writable filesystem permissions and a valid user home configuration.
Figure 5: CrushFTP login example.
The investigation pointed to the installed registration state as the probable cause because writes were denied globally rather than at a specific path, but we did not conclusively verify it. We did not attempt to bypass or fabricate licensing.
A valid trial or production license is required before CrushFTP can be tested on the same basis as the other servers, so we cannot draw any performance conclusion from this run.
Figure 6: CrushFTP web interface.
SFTP server software benchmark methodology
Test objective
The benchmark compares the server-side behavior of SFTP implementations under controlled conditions. We constrained or isolated storage, network latency, client throughput, available CPU, and memory where possible so differences between server implementations would remain visible.
This deliberately makes the benchmark narrower than an end-to-end production transfer test. In particular, loopback and memory-backed storage were intended to expose protocol processing, encryption, concurrency, process architecture, and connection-management costs rather than WAN or storage-system performance.
Test environment
Separating the client and server CPU affinity reduced direct CPU contention between the load generator and the server. The 6 GB memory ceiling provided a consistent limit for the concurrent-session test and made the cost of process-per-connection designs visible. tmpfs removed normal disk throughput from most tests, while loopback removed physical network variability.
Before testing the SFTP implementations, we measured the host’s approximate ceilings independently. AES-128-GCM reached 2,737 MB/s, ChaCha20-Poly1305 1,430 MB/s, sequential storage writes 2,687 MB/s, random writes approximately 263,000 IOPS, and loopback networking 1,889 MB/s. SFTP results substantially below these values can therefore be interpreted as limited primarily by the server and protocol path rather than by those individual hardware subsystems.
Client implementation
The standard OpenSSH sftp command was not used as the main transfer generator because, in this environment, its single-stream behavior plateaued at roughly 90 MB/s. At that point, the benchmark would have been measuring a client limitation rather than differences between servers.
Instead, the tests used a custom Go client based on github.com/pkg/sftp. It performs concurrent reads and writes so that the server becomes the limiting side of the transfer. The SFTP packet size remained at 32 KB, matching the normal defaults used by OpenSSH and pkg/sftp. We tested a 256 KB setting during development, but it caused OpenSSH connections to fail, so we did not use it.
T1: Single-stream throughput
T1 measured the basic large-file transfer path. We uploaded a single 3 GB file and downloaded it, recording each direction independently. We repeated each measurement three times, and retained the median result. Filesystem caches were dropped between repetitions.
This test was not intended to estimate real-world WAN throughput. With the client and server on the same machine, it provides a controlled view of how quickly each server can process a sustained SFTP stream when network and, for most implementations, physical-disk limits have been removed.
T1b: Cipher comparison
T1b repeated the download workload while forcing either AES-128-GCM or ChaCha20-Poly1305 from the client side. This exposed differences in cipher support and in how each implementation interacts with the host CPU’s cryptographic capabilities.
We recorded unsupported ciphers or failed transfers as missing results. The host supports AES acceleration, so the test environment naturally favors efficient AES-GCM implementations, but results remained implementation-dependent.
T2: Parallel-stream scaling
T2 measured how aggregate throughput changed when the same workload was divided among one, two, and four simultaneous streams. Total transferred data remained fixed at 3 GB; increasing the number of streams therefore changed concurrency.
The four-stream-to-one-stream ratio was used as the main scaling indicator. A result near one suggests that additional connections do little to increase throughput, while a larger ratio indicates that the server can use additional execution capacity under parallel load. Because the total payload was fixed, the test emphasizes concurrency and CPU utilization rather than rewarding a larger workload.
T3: Small-file workload
Large sequential transfers do not represent workloads dominated by filesystem and protocol operations. T3 therefore uploaded 20,000 files of 4 KB each and measured completed files per second.
At this size, bulk transfer bandwidth is not the main cost. Each file requires a sequence of SFTP operations and filesystem metadata work, making the test sensitive to open, create, close, and request-handling overhead. It complements T1 rather than serving as another throughput measurement.
T4: Connection and authentication overhead
T4 performed 500 sequential sessions. Each iteration established a connection, authenticated using a public key, and disconnected without running a sustained transfer.
We recorded connection latency as p50, p95, and p99 values, along with completed logins per second. This isolates SSH/SFTP session establishment and makes architectural differences visible, including the extra process-management cost associated with servers that fork for each connection.
We tested public-key authentication. We left password, keyboard-interactive, certificate, GSSAPI/Kerberos, and multi-factor authentication paths outside the current benchmark, so T4 should not be generalized to those authentication mechanisms.
T5: Concurrent sessions and memory scaling
T5 progressively increased the number of simultaneous sessions from 50 toward 500 and recorded both the highest sustainable connection count and resident memory consumed per session. All servers ran under the same 6 GB memory limit.
This test was particularly useful for distinguishing server architectures. OpenSSH-derived and other fork-per-connection implementations create substantial per-session process overhead. By contrast, event-driven, goroutine-based, or threaded implementations can share considerably more state between connections. When a server failed before reaching the top of the ramp, the failure point was retained as part of the result, not as extrapolating a higher capacity.
The 500-session ceiling is a limit of this test environment. It is not a claim about the maximum capacity of servers that completed it. Measuring their actual upper limit would require a larger host and a substantially higher connection ramp.
T6: Resource efficiency
T6 measured CPU and memory use while a continuous transfer was active. CPU utilization and RSS were sampled across the complete server process tree every 0.5 seconds rather than monitoring the parent process.
CPU efficiency was normalized as CPU percentage per Gbps of achieved throughput. This provides context: low CPU consumption is useful if the server is also transferring data at a meaningful rate.
T7: Cold start
T7 measured elapsed time from starting the server process until it accepted its first connection. This captures startup overhead that is largely irrelevant for long-running daemons but can matter for disposable test environments, containers, short-lived services, and automated deployment workflows.
The measurement also exposes runtime differences that are mostly absent once a process is warm, particularly between small native daemons and applications that must initialize a JVM or Python-based runtime before accepting connections.
Interpreting the results
Missing values indicate either unsupported functionality or a measurement we could not complete; we did not infer replacement values.
The loopback environment is especially important when interpreting T1 and T2. Relative rankings and scaling behavior are useful in this controlled host, but do not treat the absolute MB/s figures as predictions for a real network. Latency, packet loss, bandwidth-delay product, remote storage, and client behavior can materially change the outcome.
OpenSSH also requires a specific qualification: its benchmark account wrote to a disk-backed home directory rather than the tmpfs used by the other implementations. Its absolute T1 and T2 numbers are therefore not strictly comparable with the other servers, even though the measurements remain useful for understanding its behavior in the tested configuration.
Managed file transfer solutions for SFTP
If you want more administrative features and easier use, you can also choose managed file transfer solutions:
JSCAPE
JSCAPE provides a managed file transfer platform with SFTP server capabilities, enabling secure, encrypted file exchanges across networks. It also supports the OFTP2 protocol for secure data transmission in automotive and other industries.
Choose JSCAPE as SFTPStonebranch
Stonebranch’s Secure File Transfer Protocol (SFTP) feature is part of its Managed File Transfer (MFT) solution and provides secure, reliable, and automated data transfers. Supporting various IT environments, including mainframes, cloud platforms, and hybrid systems, the SFTP server software feature ensures encryption and compliance with industry security standards, making it suitable for both internal and external file exchanges.
Explore StonebranchDiplomat MFT by Coviant Software
Diplomat MFT by Coviant Software is an on-premise managed file transfer platform built around SFTP as its core secure transport layer, with PGP encryption as a first-class capability. Coviant Diplomat MFT is designed for organizations in regulated industries, such as healthcare, financial services, government, and manufacturing, that need no-code workflow automation, built-in compliance tooling, and a stable, self-hosted deployment model.
Explore Diplomat MFTCerberus FTP Server
Cerberus FTP Server is a Windows-based solution designed for on-premise or cloud setups. It features AD/LDAP integration, SSO, web client transfers, and compliance with encryption standards like FIPS 140-2. Essential features include automated scanning, event-driven automation, and HIPAA compliance support.
Choose CerberusGoAnywhere MFT
GoAnywhere MFT provides a secure SFTP solution for file transfers, emphasizing encryption and compliance. It aims to ensure data integrity and confidentiality, with features for key management, authentication, and logging, catering to organizations that prioritize secure, regulated data exchanges.
Further Reading
- Top 10 Managed File Transfer (MFT) Solutions
- Top 6 AS2 Software Solutions: Picks from 400+ Reviews
- Axway Managed File Transfer: Key Things to Consider
Add as preferred sourceCite this benchmark
Pick the format that matches where you're publishing. Pasting the link version into your CMS preserves the backlink.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Ermut, Sıla},
title = {{Top 8 SFTP Server Software}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/sftp-server-software}},
note = {AIMultiple. Retrieved August 20, 2026}
}Results and timestamps of 16 data points. Download the data used in this article as a ZIP file containing 2 CSV files and a README.
Changelog
11 updates- 2026
Added a benchmark methodology section covering eight SFTP servers.
Replaced the Files.com section with a new section on Diplomat MFT by Coviant Software.
Added Stonebranch and Files.com to the list of SFTP server solutions.
- 2025
Removed Globalscape MFT and MOVEit Managed File Transfer from the list of analyzed solutions.
Removed MOVEit Managed File Transfer from the list of SFTP server software.
Removed Figure 1 and Figure from the Cerberus section.
Added Stonebranch to the "Top 8 SFTP Server Software in 2026" section.
- 2024
Added JSCAPE, Cerberus FTP, MOVEit, GoAnywhere MFT, Files.com, Thru, and SolarWinds SFTP/SCP Server to the introduction.
Added a link to free SFTP solutions in the introduction.
Added Cerberus FTP Server to the list of top SFTP server solutions.
Added JSCAPE to the list of SFTP server software.
Cem's work at AIMultiple has been cited by leading global publications including Business Insider, Forbes, Morning Brew, and Washington Post, global firms like Deloitte and HPE, NGOs like World Economic Forum, and supranational organizations like European Commission. [1], [2], [3], [4], [5]
Throughout his career, Cem served as a tech consultant, tech buyer and tech entrepreneur. He advised enterprises on their technology decisions at McKinsey & Company and Altman Solon for more than a decade. He also published a McKinsey report on digitalization.
He led technology strategy and procurement of a telco while reporting to the CEO. He has also led commercial growth of deep tech company Hypatos that reached a 7 digit annual recurring revenue and a 9 digit valuation from 0 within 2 years. Cem's work in Hypatos was covered by leading technology publications like TechCrunch and Business Insider.
Cem regularly speaks at international technology conferences. He graduated from Bogazici University as a computer engineer and holds an MBA from Columbia Business School.
She previously worked as a recruiter in project management and consulting firms. Sıla holds a Master of Science degree in Social Psychology and a Bachelor of Arts degree in International Relations.
Be the first to comment
Your email address will not be published. All fields are required. Comments are left in their original language.