Four protocol endpoints share one account and storage layer
SFTPGo presents SFTP, HTTP/S, FTP/S, and WebDAV through 4 protocol endpoints backed by the same user and storage model. A partner can keep an old SFTP client while an internal user works through the browser. Their files may live on a local disk, an encrypted local filesystem, S3-compatible object storage, Google Cloud Storage, Azure Blob Storage, or another SFTP server. That combination is the reason to consider SFTPGo instead of adding another OpenSSH account.
The Community edition also includes WebAdmin and WebClient, standard public links, storage quotas, virtual folders, and event-driven actions. This is closer to a managed transfer gateway than a small SSH daemon. That distinction matters during evaluation. If all you need is one local directory for a few Unix users, SFTPGo adds an account database, an HTTP surface, and configuration choices that OpenSSH already avoids. Its value appears when those extra layers replace separate systems.
Community v2.7.6 keeps core transfer features, while deeper controls cost money
Community v2.7.6 retains the 4 server protocols, cloud backends, browser interfaces, standard links, and shared-database high availability described in the README. Enterprise adds the vendor contract and several operational features: dynamic workflow logic, advanced virtual-folder routing, IMAP attachment ingestion, PGP processing, ICAP antivirus and DLP, richer sharing, and browser document editing. A competent buyer should map requirements to that table before building around the free edition.
The split is reasonable, but the word "Community" does not mean a lightly limited demo. It can serve real transfers, and that makes license and support review more important. Community support runs through GitHub Discussions, while direct support and commercial licensing belong to Enterprise. If a failed partner upload must meet a contractual response time, the free channel is the wrong operating assumption even when the software has the required protocol.
What happened when we ran it
Our sandbox installed commit 87fb508 in 44 seconds, pulling 477 Go packages. The build completed in 233 seconds. This was an unprivileged golang:1.24-bookworm container with 3 CPUs, 8 GB of RAM, and no secrets. The checkout contained 435 files, about 186,653 source lines, and occupied 18.2 MB before installation. It also had 4 CI workflow files, a Dockerfile, and a tests directory.
The test step failed with exit code 1 after 122 seconds: 9 passed and 5 failed out of 14. The supplied log tail names TestSCPUploadMaxSize, TestSCPVirtualFolders, and TestSCPNestedFolders, then records failure for internal/sftpd after 77.148 seconds. internal/telemetry passed in 0.064 seconds and internal/webdavd passed in 32.845 seconds. The tail does not show the cause of those SCP failures, so we will not assign one.
Five failed results do not prove the server is unusable, and 9 passing results do not clear it for production. They say something narrower and useful: the exact commit did not pass the available command in our fresh Debian sandbox. The repository has the expected build and CI scaffolding, but a buyer should reproduce the SCP cases on the deployment image and storage layout before migrating external users.
One instance can stay embedded; replicas need a shared database
SFTPGo v2.7.6 can start with SQLite or bolt, expose SFTP on port 2022, and use WebAdmin on port 8080 to create the first administrator and user. That is enough for a contained trial. A real deployment then has to decide which protocols are enabled, where home directories point, how TLS terminates, which storage credentials exist, and whether public shares or the browser client should be reachable at all.
Several replicas change the database choice. The documentation directs multi-instance deployments to PostgreSQL, MySQL, or CockroachDB instead of SQLite. Object stores bring AWS, Google Cloud, or Azure credentials, while OIDC and SMTP introduce more secrets and callback settings. Open issue 2278 adds a sharp warning for reverse proxies: its reporter found that per-binding security and client-IP settings could be accepted in the wrong place yet have no effect under 2.7.5. The issue remained open when checked.
Release v2.7.6 fixed four security flaws on September 19
Release v2.7.6 fixed 4 security problems: disabled or expired share owners did not lose their links, SCP record parsing allowed unbounded memory allocation, directory names enabled stored cross-site scripting in WebClient, and copy filters missed the source path. The release also tightened ZIP-share scope, file-hash permissions, concurrent account updates, token invalidation, and installed data-directory permissions. None of that establishes a cause for our test failures. It does show why a public transfer server needs a prompt update path.
The project itself is moving. GitHub showed a September 19, 2026 push and the v2.7.6 release on the same day. We counted 12,556 stars, 159 open issues, and 20 open pull requests on September 22. Issue 2294 and pull request 2295 were opened one day earlier to add PBKDF2-SHA256 password creation for FIPS-oriented environments. Recent activity is a health signal, though the open request means the released Community build does not yet satisfy that stated need.
AGPL and the proprietary web theme can decide the purchase
The Community source uses AGPL-3.0-only, and the README adds separate terms for the proprietary KeenThemes components in WebAdmin and WebClient. The project says those interface components cannot be reused in a competing derivative without permission. Teams shipping modified network software, appliances, or branded derivatives should have counsel review both layers before engineering work starts. Enterprise is the cleaner route when copyleft or direct support is a procurement blocker.
SFTPGo makes sense when its 4 protocols, browser access, and mixed backends retire several file-transfer services. Our failed test run keeps it behind a staging gate, while the September security release makes patch ownership part of the adoption decision. For a single local SFTP endpoint, OpenSSH has far less surface. For a partner-facing transfer hub, SFTPGo earns a serious trial once the edition, license, database, proxy, and failing SCP cases have named owners.