Moving off Cerberus FTP Server
Stop patching your Cerberus server. Keep everything your partners rely on.
Cerberus FTP Server runs on a Windows server you patch, license and expose to the internet yourself. SFTP.cloud runs that part for you. Your hostname, accounts, keys and storage stay as they are, and the inbound port on your network closes.
Cerberus details checked against Redwood, Cerberus and NVD sources on 18 October 2026.
Who patches the server
You: Cerberus and Windows Server
We do
Inbound ports on your network
Open to the internet
None. The Connector only dials out
Hostname, accounts and storage
Yours
Still yours, unchanged
01Why teams move
Four security releases in six months. Each one was yours to install.
Running Cerberus yourself means you own its exposure: the open port, the patch window and the Windows server that holds your files and partner credentials.
February to July 20264 security releases
Patch now, on every server you run.
Cerberus shipped security fixes on 3 February (an OpenSSL hotfix covering eight CVEs), 31 March, 26 May and 15 July, when a libssh2 flaw, CVE-2026-55200, came with the advice to upgrade immediately. Until your team installed each one, your server ran the vulnerable version.
April 2026CVE-2026-6265
A regular user could become local administrator.
In versions up to 2025.4.2, any local user could write to the folder where Cerberus downloads its own updates and plant a file under the installer’s predictable name. The fix arrived in 2026.1, so the update process itself had to be updated first.
Every dayInbound port
Your server answers anyone who connects.
Partners reach Cerberus through a port open to the internet, so does every scanner and botnet. Each login attempt lands on a Windows machine inside your network, next to your files, and that machine needs its own monthly patches too.
On SFTP.cloud, partners connect to us. Your network has no inbound port left to find.
How we secure it02What you keep
Your partners keep connecting the way they do today. One thing changes.
Most migrations stall on the partners: nobody wants to ask a hundred companies to change their scripts. You only need to tell them about one thing.
What stays the same
Hostname, accounts, files.
Export users from the Cerberus User Manager and import the CSV as it is. How the import reads it
- Keep your hostname, such as sftp.yourcompany.com, with a DNS record
- Carry usernames and passwords as Cerberus stores them, so nobody resets a password
- Bring directories, permissions, protocols and allow lists across with each account
- Point your Storage Connector at the disk, share or bucket Cerberus uses today, including S3 and Azure Blob. No files move
What changes
The server’s host key.
SFTP clients check a server’s host key on every connection. SFTP.cloud has its own, so partners see a new fingerprint the first time they connect.
- Send partners the new fingerprint before you switch DNS
- Partners who pin host keys in scripts update one value
- Interactive clients ask once, then connect as before
Same address, same login, same files. A new key, announced in advance.
03Migration steps
Six steps, with Cerberus running until the last one.
You run the migration yourself, following our documentation. Nothing is switched off until your partners are already working on SFTP.cloud.
- 01
Start a trial and connect your storage.
Install a Storage Connector next to the disk, share or bucket Cerberus writes to today. It only makes outbound connections.
- 02
Import your accounts.
Export users from the Cerberus User Manager and import the CSV. Enter the PBKDF2 round count from the server’s settings.xml so passwords verify. Add SSH public keys from a CSV file or through the API.
- 03
Test with one partner.
Run both side by side. Ask a friendly partner to connect to SFTP.cloud directly and confirm uploads land where they did before.
- 04
Announce the new host key.
Send partners the SFTP.cloud host key fingerprint and the date of the switch, so pinned keys are updated in time.
- 05
Switch DNS.
Point your hostname at SFTP.cloud. Partners keep the address and credentials they already use.
- 06
Retire the Cerberus server.
Once traffic has moved, close the inbound port, shut the Windows server down and let the subscription lapse at renewal.
Your partners change one key. You stop running a server.
Not ready to retire Cerberus?
Keep it, and close its inbound port anyway. SFTP.cloud can sit in front of your existing SFTP server as its storage, so partners connect to us and your Cerberus server is no longer reachable from the internet.
04Before you decide
What Cerberus does that SFTP.cloud does not.
SFTP.cloud covers SFTP, FTPS, FTPES and HTTPS. If you use Cerberus for more than that, or are weighing Redwood’s other options, check these first. Each comes with a trade-off worth weighing.
- 01
Partners on plain FTP or SCP.
SFTP.cloud does not accept unencrypted FTP, and from the SSH family it offers SFTP only, by design: no SCP, shell, SSH commands or tunnels. Partners on plain FTP move to FTPS or FTPES, and SCP scripts move to SFTP, which the same tools already speak. The trade-off is one setting per partner, in exchange for no passwords sent in clear text.
- 02
Moving up to JSCAPE, Redwood’s MFT server.
Redwood owns both products and lists migration support to JSCAPE MFT in Cerberus Enterprise Plus. The trade-off is that JSCAPE is self-hosted too, so you change platform and keep the server, the port and the patching. Moving off JSCAPE
- 03
Cerberus on an AWS or Azure VM.
Cerberus has no hosted edition. Redwood documents installing it on a cloud virtual machine instead. The trade-off is that you stop owning hardware but still patch Cerberus and Windows, and the open port moves to a VM you run.
You do not need the Cerberus Gateway either. With no inbound port, there is no DMZ to proxy.
05FAQ
Moving off Cerberus, common questions.
Can I keep my current SFTP hostname?
Yes. Point your existing hostname, such as sftp.yourcompany.com, at SFTP.cloud with a DNS record. Partners keep the address they already use.
Will my partners have to change anything?
Only the host key. SFTP.cloud cannot reuse your Cerberus server’s host key, so partners see a new fingerprint the first time they connect. Send it to them before you switch DNS.
Do partners need new passwords or SSH keys?
No. Import the user export from the Cerberus User Manager: usernames, passwords as Cerberus stores them, protocols, allow lists and directory permissions carry across. Add SSH public keys from a CSV file or through the API.
Do my files have to move?
No. Your Storage Connector can point at the same disk, network share or S3 or Azure Blob bucket Cerberus uses today, and files keep landing there.
Does SFTP.cloud store my files?
No. Files stream through the Storage Connector you run next to your storage and are never written to a disk we own. The Connector only makes outbound connections, so there is no inbound rule to your network.
Does SFTP.cloud support plain FTP or SCP?
No. SFTP.cloud supports SFTP, FTPS, FTPES and an HTTPS web client. From the SSH family it offers SFTP only, by design: no SCP, shell, SSH commands or tunnels. Partners on plain FTP move to FTPS or FTPES, and SCP scripts move to SFTP.
Do you migrate it for me?
Migration is self-service and documented step by step. You can run SFTP.cloud alongside Cerberus for as long as you need before switching.
Can I keep Cerberus and just close the inbound port?
Yes. SFTP.cloud can use your existing SFTP server as its storage. Partners connect to SFTP.cloud, which passes files to your Cerberus server over an outbound connection, so the server is no longer exposed to the internet.
Run it next to Cerberus for fourteen days.
Connect the storage Cerberus uses, import a few accounts and test with one partner before anything changes. No credit card, and nothing to cancel if it is not for you.
Want the details first? Read about security or SFTP for on-premises storage.