Existing SFTP servers
Keep your SFTP server. Take it off the internet.
Put SFTP.cloud in front of the server you already run, close the inbound port that leads to it, and secure it in one move.
Your server keeps its files, its scripts and its integrations. It just stops being reachable by everyone else on the internet, including whoever finds the next zero-day in it.
14 days. No credit card. No feature locks.
Inbound ports open to your server0
01The exposure
An internet-facing SFTP server is a full-time job.
Replacing a working server is rarely the hard part. Keeping it safe while it faces the internet is, and the work never ends.
- 01
It is found within minutes.
Anything listening on port 22 is scanned, fingerprinted and tried with stolen passwords around the clock, by automated tools that never sleep.
- 02
Zero-days arrive faster than patch windows.
Even mature SSH software has critical flaws: regreSSHion in OpenSSH in 2024, Terrapin in the SSH protocol itself in 2023. Exploits often follow disclosure within days, and your change window may be weeks away.
- 03
Some servers can't be patched at all.
An end-of-life product, an OS pinned by a vendor, an appliance nobody may touch. They still sit in the DMZ, still answering anyone who connects.
- 04
One breach reaches everything behind it.
The server holds partner credentials and files, and it sits on your network. Whoever gets in starts from there.
02How it works
Change the front. Leave the back exactly as it is.
- 01
Deploy a Storage Connector inside your network.
On a server in your datacenter, as a container in Kubernetes, or on the same machine as your SFTP server.
- 02
Point it at your existing server.
The Connector reaches it over your internal network as an ordinary SFTP client. Nothing on the server is reinstalled or reconfigured.
- 03
Close the inbound port.
Partners connect to SFTP.cloud instead. Your server can move out of the DMZ into a subnet nothing on the internet can reach.
- Your server
- Any standards-compliant SFTP server: OpenSSH, a commercial MFT product, or an appliance.
- Network
- The Connector makes outbound connections only. No inbound rule, no VPN, no port forwarding.
- Files
- Land on your server as they always have, so its folders, scripts and downstream jobs keep working.
- Partners
- Keep your existing hostname by pointing its DNS record at SFTP.cloud. Partners get a new host key and credentials, and move one at a time, when it suits you.
Before
After
03What you gain
Modern security in front of a server that may support none of it.
All of this applies from the day you close the port, without upgrading, replacing or even restarting your server.
- 0Inbound ports open to your server
- 0Changes to the server itself
- 0Partners forced to move on your schedule
- 01
A public endpoint we patch.
Keeping the internet-facing side current and defended becomes our job, not your change window.
- 02
Zero-days stop being emergencies.
A new flaw in your server's SSH stack can't be reached from the internet. You still patch it, on your schedule instead of overnight.
- 03
Post-quantum cryptography.
Post-quantum cipher suites on every protocol, and mutual TLS on every path we operate, whatever your server negotiates.
- 04
SSO, MFA and geo-fencing.
Single sign-on, MFA, geo-fencing and automatic blocking of attacking addresses, in front of a server that has never heard of them.
- 05
Audit across both sides.
Dual signed audit trails covering every connection, which you verify yourself. How we're built
- 06
FTPS and a browser client.
Offer FTPS, FTPES and an HTTPS web client to partners who need them, even if your server only speaks SFTP.
04Use cases
Where this tends to be used.
- 01
Move the server out of the DMZ.
Into an internal subnet with no inbound firewall rules at all.
- 02
Retire an internet-facing server without a migration project.
Close the port now. Decide what happens to the server later.
- 03
Add modern authentication to a legacy system.
SSO and MFA for a product that will never support either.
- 04
Onboard new partners on modern infrastructure.
While an old integration carries on undisturbed.
- 05
Buy time during a migration.
Make the old server safe while you scope the move properly.
- 06
Protect a server you can’t patch.
End-of-life software, a pinned OS, or a vendor appliance, taken off the internet.
05FAQ
Before you close the port.
Do I have to change anything on my existing SFTP server?
No. The Storage Connector connects to it as an ordinary SFTP client over your internal network. The server keeps its configuration, folders and scripts.
Do my partners have to change anything?
They can keep the hostname they already use. Point your existing DNS name, such as sftp.yourcompany.com, at SFTP.cloud and partners connect to the same address as before. They do get a new host key and new credentials, so you can move them one at a time, when it suits you and them. Partners you haven’t moved keep using the old server until you close its port.
Can the Connector run on the same machine as my SFTP server?
Yes. It can also run on another server in your network, or as a container in Kubernetes. It only needs to reach your SFTP server and make outbound connections to SFTP.cloud.
Do I still need to patch my server?
Yes, but on your own schedule. Once the inbound port is closed, a new flaw in the server can’t be reached from the internet, so a critical disclosure becomes routine maintenance instead of an emergency.
Does SFTP.cloud keep copies of my files?
No. Files stream through the Connector straight to your server. They are never written to a disk we own.
What does it cost?
From $2,400 a year on the Shared plan, with 15 transfer accounts and 3 Storage Connectors included, and no per-gigabyte charge.
Close the port this week.
Deploy a Connector next to your server, move one partner across and see it work. Fourteen days, no credit card, and nothing to cancel if it is not for you.
Want to see the moving parts first? See how it works or talk to an engineer. The person who answers builds the product.