There are two types of file-transfer operators: those who can afford to plan downtime windows every now and then to install updates and upgrades, and those who can’t afford to have their SFTP server offline even for those 45 seconds.
And here’s the interesting part: neither of them gets away scot free.
In fact, those who can plan for update windows get annoyed with “rolling release” vendors, because they add too many items to their already busy docket.
And the second type… well… they’re the reason why we still find customers on V4 when the current release is V8. It works just fine, and they can’t afford the downtime to upgrade. To be fair this type often splits into two sub-types: those who do not update, and those who deploy HA clusters behind load-balancers to be able to upgrade their nodes one by one without interrupting the service as a whole.
Up until now we’ve never felt this could be, at least in part, our responsibility. But, oh boy, were we wrong! Having spent the past year and a half developing all the SFTP.cloud components threw us head-first directly into those operators’ shoes. We quickly realized we had to come up with a better approach.
So, how do SFTP.cloud components update with zero downtime?
As it often happens there are two sides to this story:
The Protocol Heads, the machines serving SFTP, FTP(E/S) and HTTPS, accepting incoming client connections, are the ones we operate. On top of load-balancing and clustering, each one of these nodes is also designed to hand over the listening socket to the incoming (upgraded) process, so connections survive the changeover without ever being rejected by a closed port.
The Storage Connector, sitting in your data center, does something different. The new version starts up alongside the old one, dials the Head over its own reverse tunnel, and gradually takes over new work. The old binary keeps the transfers it already had, carries every one of them through to completion, and exits only once it has gone idle. At no point in the chain is there a gap where a transfer is dropped or interrupted.
The Head side updates/upgrades are orchestrated by an automation process that staggers the updates and delivers them in tiers, verifying each tier before moving on to the next. Any error during the process is an automatic zero-downtime rollback.
The Storage Connector side is capable of fully automatic self-updates, but it can be configured to wait until an operator decides to do the rollout. And still there’s nothing to keep an eye on, download, type in the command line… it’s just one button in the Connector’s Admin UI. One click. A few seconds of wait time. Walk away with a smile on your face.
Syncplify Server! and R2FS! come next
We decided to take it one step further. Now that we’ve developed the technology, we believe the same approach would also benefit our Syncplify Server! and R2FS! customers. After all, they are the ones who operate our self-hosted software, so it seems fitting to offer them the same convenience.
We have, therefore, begun a two-pronged effort to integrate the same zero-downtime update/upgrade features into those pieces of software as well.
Because it’s all about security
We don’t release updates for the fun of it, or to annoy our customers with yet another upgrade task to plan around. We release them because the threat landscape keeps shifting. And now, with the advent of AI, that shift is faster than ever before.
If you’re still running an old V4 or V5, you’re simply not safe. It works, yes, it works really well. But it’s vulnerable to attacks that didn’t even exist when that version was released. Keeping your software up to date is the one shield that protects you more than anything else.
Now, with SFTP.cloud that’s also easier than ever. And soon it will be, too, for Syncplify Server! and R2FS!