SFTPGo alternatives and similar packages
Based on the "Server Applications" category.
Alternatively, view SFTPGo alternatives based on common mentions on social networks and blogs.
10.0 9.7 SFTPGo VS etcdDistributed reliable key-value store for the most critical data of a distributed system
9.9 9.8 SFTPGo VS VaultA tool for secrets management, encryption as a service, and privileged access management
9.9 9.9 SFTPGo VS consulConsul is a distributed, highly available, and data center aware solution to connect and configure applications across dynamic, distributed infrastructure.
9.3 0.0 SFTPGo VS PonzuHeadless CMS with automatic JSON API. Featuring auto-HTTPS from Let's Encrypt, HTTP/2 Server Push, and flexible server framework written in Go.
9.3 9.8 SFTPGo VS RoadRunner🤯 High-performance PHP application server, load-balancer and process manager written in Golang
8.4 1.1 SFTPGo VS discoveryA registry for resilient mid-tier load balancing and failover.
8.3 4.1 SFTPGo VS FlagrFlagr is a feature flagging, A/B testing and dynamic configuration microservice
8.2 1.0 SFTPGo VS Key TransparencyA transparent and secure way to look up public keys.
8.1 7.7 SFTPGo VS TricksterOpen Source HTTP Reverse Proxy Cache and Time Series Dashboard Accelerator
5.5 0.0 SFTPGo VS marathon-consulIntegrates Marathon apps with Consul service discovery.
5.5 9.0 SFTPGo VS EruEru, a simple, stateless, flexible, production-ready orchestrator designed to easily integrate into existing workflows. Can run any virtualization things in long or short time.
Do you think we are missing an alternative of SFTPGo or a related project?
Fully featured and highly configurable SFTP server with optional FTP/S and WebDAV support, written in Go. Several storage backends are supported: local filesystem, encrypted local filesystem, S3 (compatible) Object Storage, Google Cloud Storage, Azure Blob Storage, SFTP.
- Support for serving local filesystem, encrypted local filesystem, S3 Compatible Object Storage, Google Cloud Storage, Azure Blob Storage or other SFTP accounts over SFTP/SCP/FTP/WebDAV.
- Virtual folders are supported: a virtual folder can use any of the supported storage backends. So you can have, for example, an S3 user that exposes a GCS bucket (or part of it) on a specified path and an encrypted local filesystem on another one. Virtual folders can be private or shared among multiple users, for shared virtual folders you can define different quota limits for each user.
- Configurable [custom commands and/or HTTP hooks](./docs/custom-actions.md) on file upload, pre-upload, download, pre-download, delete, pre-delete, rename, mmkdir, rmdir on SSH commands and on user add, update and delete.
- Virtual accounts stored within a "data provider".
- SQLite, MySQL, PostgreSQL, CockroachDB, Bolt (key/value store in pure Go) and in-memory data providers are supported.
- Chroot isolation for local accounts. Cloud-based accounts can be restricted to a certain base path.
- Per user and per directory virtual permissions, for each exposed path you can allow or deny: directory listing, upload, overwrite, download, delete, rename, create directories, create symlinks, change owner/group/file mode.
- [REST API](./docs/rest-api.md) for users and folders management, data retention, backup, restore and real time reports of the active connections with possibility of forcibly closing a connection.
- [Web based administration interface](./docs/web-admin.md) to easily manage users, folders and connections.
- [Web client interface](./docs/web-client.md) so that end users can change their credentials and browse their files.
- Public key and password authentication. Multiple public keys per user are supported.
- SSH user certificate authentication.
- Keyboard interactive authentication. You can easily setup a customizable multi-factor authentication.
- Partial authentication. You can configure multi-step authentication requiring, for example, the user password after successful public key authentication.
- Per user authentication methods.
- Two-factor authentication based on time-based one time passwords (RFC 6238) which works with Authy, Google Authenticator and other compatible apps.
- Custom authentication via external programs/HTTP API.
- [Data At Rest Encryption](./docs/dare.md).
- Dynamic user modification before login via external programs/HTTP API.
- Quota support: accounts can have individual quota expressed as max total size and/or max number of files.
- Bandwidth throttling, with distinct settings for upload and download.
- Per-protocol [rate limiting](./docs/rate-limiting.md) is supported and can be optionally connected to the built-in defender to automatically block hosts that repeatedly exceed the configured limit.
- Per user maximum concurrent sessions.
- Per user and global IP filters: login can be restricted to specific ranges of IP addresses or to a specific IP address.
- Per user and per directory shell like patterns filters: files can be allowed or denied based on shell like patterns.
- Automatically terminating idle connections.
- Automatic blocklist management using the built-in [defender](./docs/defender.md).
- Atomic uploads are configurable.
- Per user files/folders ownership mapping: you can map all the users to the system account that runs SFTPGo (all platforms are supported) or you can run SFTPGo as root user and map each user or group of users to a different system account (*NIX only).
- Support for Git repositories over SSH.
- SCP and rsync are supported.
- FTP/S is supported. You can configure the FTP service to require TLS for both control and data connections.
- [WebDAV](./docs/webdav.md) is supported.
- Two-Way TLS authentication, aka TLS with client certificate authentication, is supported for REST API/Web Admin, FTPS and WebDAV over HTTPS.
- Per user protocols restrictions. You can configure the allowed protocols (SSH/FTP/WebDAV) for each user.
- [Prometheus metrics](./docs/metrics.md) are exposed.
- Support for HAProxy PROXY protocol: you can proxy and/or load balance the SFTP/SCP/FTP/WebDAV service without losing the information about the client's address.
- Easy [migration](./examples/convertusers) from Linux system user accounts.
- [Portable mode](./docs/portable-mode.md): a convenient way to share a single directory on demand.
- [SFTP subsystem mode](./docs/sftp-subsystem.md): you can use SFTPGo as OpenSSH's SFTP subsystem.
- Performance analysis using built-in [profiler](./docs/profiling.md).
- Configuration format is at your choice: JSON, TOML, YAML, HCL, envfile are supported.
- Log files are accurate and they are saved in the easily parsable JSON format ([more information](./docs/logs.md)).
- SFTPGo supports a [plugin system](./docs/plugins.md) and therefore can be extended using external plugins.
SFTPGo is developed and tested on Linux. After each commit, the code is automatically built and tested on Linux, macOS and Windows using a [GitHub Action](./.github/workflows/development.yml). The test cases are regularly manually executed and passed on FreeBSD. Other *BSD variants should work too.
- Go as build only dependency. We support the Go version(s) used in [continuous integration workflows](./tree/main/.github/workflows).
- A suitable SQL server to use as data provider: PostgreSQL 9.4+ or MySQL 5.6+ or SQLite 3.x or CockroachDB stable.
- The SQL server is optional: you can choose to use an embedded bolt database as key/value store or an in memory data provider.
Binary releases for Linux, macOS, and Windows are available. Please visit the releases page.
An official Docker image is available. Documentation is [here](./docker/README.md).
Some Linux distro packages are available:
- For Arch Linux via AUR:
- sftpgo. This package follows stable releases. It requires
- sftpgo-bin. This package follows stable releases downloading the prebuilt linux binary from GitHub. It does not require
- sftpgo-git. This package builds and installs the latest git
mainbranch. It requires
- sftpgo. This package follows stable releases. It requires
- Deb and RPM packages are built after each commit and for each release.
- For Ubuntu a PPA is available here.
SFTPGo is also available on AWS Marketplace, purchasing from there will help keep SFTPGo a long-term sustainable project.
On FreeBSD you can install from the SFTPGo port.
On Windows you can use:
- The Windows installer to install and run SFTPGo as a Windows service.
- The portable package to start SFTPGo on demand.
You can easily test new features selecting a commit from the Actions page and downloading the matching build artifacts for Linux, macOS or Windows. GitHub stores artifacts for 90 days.
Alternately, you can [build from source](./docs/build-from-source.md).
[Getting Started Guide for the Impatient](./docs/howto/getting-started.md).
A full explanation of all configuration methods can be found [here](./docs/full-configuration.md).
Please make sure to initialize the data provider before running the daemon.
To start SFTPGo with the default settings, simply run:
Check out [this documentation](./docs/service.md) if you want to run SFTPGo as a service.
Data provider initialization and management
Before starting the SFTPGo server please ensure that the configured data provider is properly initialized/updated.
For PostgreSQL, MySQL and CockroachDB providers, you need to create the configured database. For SQLite, the configured database will be automatically created at startup. Memory and bolt data providers do not require an initialization but they could require an update to the existing data after upgrading SFTPGo.
SFTPGo will attempt to automatically detect if the data provider is initialized/updated and if not, will attempt to initialize/ update it on startup as needed.
Alternately, you can create/update the required data provider structures yourself using the
For example, you can simply execute the following command from the configuration directory:
Take a look at the CLI usage to learn how to specify a different configuration file:
sftpgo initprovider --help
You can disable automatic data provider checks/updates at startup by setting the
update_mode configuration key to
Create the first admin
To start using SFTPGo you need to create an admin user, you can do it in several ways:
- by using the web admin interface. The default URL is http://127.0.0.1:8080/web/admin
- by loading initial data
- by enabling
create_default_adminin your configuration file. In this case the credentials are
SFTPGo supports upgrading from the previous release branch to the current one. Some examples for supported upgrade paths are:
- from 1.2.x to 2.0.x
- from 2.0.x to 2.1.x and so on.
For supported upgrade paths, the data and schema are migrated automatically, alternately you can use the
So if, for example, you want to upgrade from a version before 1.2.x to 2.0.x, you must first install version 1.2.x, update the data provider and finally install the version 2.0.x. It is recommended to always install the latest available minor version, ie do not install 1.2.0 if 1.2.2 is available.
Loading data from a provider independent JSON dump is supported from the previous release branch to the current one too. After upgrading SFTPGo it is advisable to regenerate the JSON dump from the new version.
If for some reason you want to downgrade SFTPGo, you may need to downgrade your data provider schema and data as well. You can use the
revertprovider command for this task.
As for upgrading, SFTPGo supports downgrading from the previous release branch to the current one.
So, if you plan to downgrade from 2.0.x to 1.2.x, before uninstalling 2.0.x version, you can prepare your data provider executing the following command from the configuration directory:
sftpgo revertprovider --to-version 4
Take a look at the CLI usage to see the supported parameter for the
--to-version argument and to learn how to specify a different configuration file:
sftpgo revertprovider --help
revertprovider command is not supported for the memory provider.
Please note that we only support the current release branch and the current main branch, if you find a bug it is better to report it rather than downgrading to an older unsupported version.
Users and folders management
After starting SFTPGo you can manage users and folders using:
- the [web based administration interface](./docs/web-admin.md)
- the [REST API](./docs/rest-api.md)
To support embedded data providers like
SQLite we can't have a CLI that directly write users and folders to the data provider, we always have to use the REST API.
Some step-to-step tutorials can be found inside the source tree [howto](./docs/howto "How-to") directory.
Custom authentication methods can easily be added. SFTPGo supports external authentication modules, and writing a new backend can be as simple as a few lines of shell script. More information can be found [here](./docs/external-auth.md).
Keyboard Interactive Authentication
Keyboard interactive authentication is, in general, a series of questions asked by the server with responses provided by the client. This authentication method is typically used for multi-factor authentication.
More information can be found [here](./docs/keyboard-interactive.md).
Dynamic user creation or modification
A user can be created or modified by an external program just before the login. More information about this can be found [here](./docs/dynamic-user-mod.md).
SFTPGo allows you to configure custom commands and/or HTTP hooks to receive notifications about file uploads, deletions and several other events.
More information about custom actions can be found [here](./docs/custom-actions.md).
Directories outside the user home directory or based on a different storage provider can be exposed as virtual folders, more information [here](./docs/virtual-folders.md).
You can get notified as soon as a new connection is established using the [Post-connect hook](./docs/post-connect-hook.md) and after each login using the [Post-login hook](./docs/post-login-hook.md). You can use your own hook to [check passwords](./docs/check-password-hook.md).
S3 Compatible Object Storage backends
Each user can be mapped to the whole bucket or to a bucket virtual folder. This way, the mapped bucket/virtual folder is exposed over SFTP/SCP/FTP/WebDAV. More information about S3 integration can be found [here](./docs/s3.md).
Google Cloud Storage backend
Each user can be mapped with a Google Cloud Storage bucket or a bucket virtual folder. This way, the mapped bucket/virtual folder is exposed over SFTP/SCP/FTP/WebDAV. More information about Google Cloud Storage integration can be found [here](./docs/google-cloud-storage.md).
Azure Blob Storage backend
Each user can be mapped with an Azure Blob Storage container or a container virtual folder. This way, the mapped container/virtual folder is exposed over SFTP/SCP/FTP/WebDAV. More information about Azure Blob Storage integration can be found [here](./docs/azure-blob-storage.md).
Each user can be mapped to another SFTP server account or a subfolder of it. More information can be found [here](./docs/sftpfs.md).
Data at-rest encryption is supported via the [cryptfs backend](./docs/dare.md).
Other Storage backends
Adding new storage backends is quite easy:
- implement the [Fs interface](./vfs/vfs.go#L28 "interface for filesystem backends").
- update the user method
GetFilesystemto return the new backend
- update the web interface and the REST API CLI
- add the flags for the new storage backed to the
Anyway, some backends require a pay per use account (or they offer free account for a limited time period only). To be able to add support for such backends or to review pull requests, please provide a test account. The test account must be available for enough time to be able to maintain the backend and do basic tests before each new release.
Brute force protection
The [connection failed logs](./docs/logs.md) can be used for integration in tools such as Fail2ban. Example of [jails](./fail2ban/jails) and [filters](./fail2ban/filters) working with
journald are available in fail2ban directory.
You can also use the built-in [defender](./docs/defender.md).
Account's configuration properties
Details information about account configuration properties can be found [here](./docs/account.md).
SFTPGo can easily saturate a Gigabit connection on low end hardware with no special configuration, this is generally enough for most use cases.
More in-depth analysis of performance can be found [here](./docs/performance.md).
SFTPGo releases are feature-driven, we don't have a fixed time based schedule. As a rough estimate, you can expect 1 or 2 new releases per year.
SFTPGo makes use of the third party libraries listed inside [go.mod](./go.mod).
We are very grateful to all the people who contributed with ideas and/or pull requests.
Thank you ysura for granting me stable access to a test AWS S3 account.
I'd like to make SFTPGo into a sustainable long term project and your sponsorship will really help :heart:
Thank you to our sponsors!
*Note that all licence references and agreements mentioned in the SFTPGo README section above are relevant to that project's source code only.