Existing SFTP servers
Keep the SFTP server you already have.
Stop exposing it to the internet.
Replacing a working file transfer server is rarely a technical problem. It is a partner problem: dozens of external organisations, each with a hostname, a credential and a script somebody wrote years ago, and each of whom must be persuaded to change all three.
There is a way to modernize and secure the front without touching the back.
No credit card. No feature locks. Walk away by doing nothing.
How it works
Put SFTP.cloud in front of it
1
Deploy a Storage Connector inside your network.
On a server in your datacenter, as a container in Kubernetes, or even on the same machine where your old SFTP server lives.
2
The server no longer has to face the internet.
What changes is the front. Nothing about the back does.
3
New partners connect to SFTP.cloud.
.
Existing ones can be migrated when it suits you, one at a time, or left where they are while you decide. Nobody has to move on a schedule set by your infrastructure.
Features
What you gain immediately
-
A managed, secure public endpoint that is our job to patch and keep up
-
No inbound rule to your own server
-
Post-quantum cipher suites on all protocols, plus mutual TLS on every path we operate
-
Single sign-on, MFA and geo-fencing in front of a server that may support none of those.
-
Dual signed audit trails across both sides of the connection
Use cases
Where this tends to be used
-
Moving your SFTP server from your DMZ to a safer subnet with no inbound firewall rules.
-
Retiring an internet-facing server without a migration project.
-
Adding modern authentication to a legacy system that will never support it.
-
Serving new partners on modern infrastructure while an old integration continues undisturbed.
-
Buying time during a migration you have not finished scoping.