This allows for cross-VFS and even cross-Connector MFT. Copy and move your files freely, they will land on your actual storage in your own facilities (Disk, NAS, SAN, SMB/CIFS, NFS, DFS, whatever you have connected from that office to SFTP.cloud).

These cross-VFS/cross-Connector transfers are fully managed, you can start them and logout, leave, come back the next day, and your files will be safe in their intended destination.

And all transfers are verified twice: in flight (using per-buffer rolling hash) and then again after they land (using a full-file hash).

And the icing on the cake: you don’t need to initiate these transfers via the web-based file manager. SFTP.cloud has built-in support for SyncJS scripting, event handling, and scheduling, so you can automate them however you like.

If you are among the 100 early-adopters who signed up via the SFTP.cloud placeholder website, first of all THANK YOU.

You will receive instructions on how to enroll (and how to redeem your well-deserved credit) within the next 10 days. Yes, we’re not doing this with a mailing-list, we’ll actually be emailing each and every one of you personally. Manually.

Of course we were hoping for SFTP.cloud to arouse some interest, but the initial reception has gone beyond our expectations, and for that we’re immensely grateful.

More to come. Soon. 😉

What’s changed?

• The “automatic linking” upon first login used to be limited to the principal’s subject as defined in the remote directory, this new release adds the ability to specify a custom claim to be used for auto-linking (upon first successful login); read more here: https://docs.syncplify.com/v8/docs/general/sso.html

• Usual small set of little bug-fixes and quality of life improvements

As always, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Improved named-pipe compatibility with impersonated worker system services when running on the Windows operating system (Linux never had that problem in the first place); Also added an “escape hatch” via system-wide environment variable (documented in the manual) in case everything else fails, to switch from named-pipes back to the old TCP-loopback method.

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

But words are just words… until someone tests them. So we had it tested.

Yep, that’s our very first site running on SFTP.cloud (rather obviously, it’s our own).

But we can already hear you all: “security goes much deeper than just a good TLS implementation”. True. Very true. And that’s why we hired a penetration testing company to red-team and blue-team the heck out of our solution, so that once it finally gets into your hands it will be green-lighted by the best independent security testers out there.

Would you like 2 FREE MONTHS of service when it launches? There are still a few spots left. Head over to SFTP.cloud and reserve yours.

What’s changed?

• Added the ability to backup/restore the configuration, and/or migrate the entire R2FS! node to a new machine/VM

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

The core itself (the Portal, Customer UI, Protocol Heads, Storage Connectors, …) is ready, and in the past couple of weeks we focused on monitoring and observability. And, in typical Syncplify fashion, we didn’t do it just for us, we did it for you as well.

First and foremost, our intercontinental distributed monitoring system: 5 probes in 5 different data-centers, operated by 4 different ISPs, in 3 different continents.

The service is degraded, or “down”, when 3 or more probes agree it is. And the whole purpose of this complex distributed system is to give you this:

That’s the public-view of our service’s health. The transfer service is currently not measured because we haven’t released it to anyone yet. Once we do, it will be.

In addition to that, each customer has a per-protocol view of their individual sites’ health inside of their own Customer Portal. Something that looks like this:

And this is not all we did recently to ensure service observability and uptime. Read on, it only gets more interesting.

Two tamper-evident, digitally signed, verifiable logs

All file access and transfer events in SFTP.cloud are logged on two sides:

• on the Head that serves the protocol (that we control)

• on the Storage Connector that’s in your hands (and we cannot reach)

In your Customer UI you can see the Head’s log integrity, and download a digitally signed evidence file:

In your Storage Connector UI, you can check the integrity of the logs acquired on your own infrastructure, outside of our control:

And to keep everyone honest, so that none of the parties has to “operate on trust”, we open-sourced the log verifier. Anyone can read the source code, verify it’s honest, download it, compile it, and run it against their own SFTP.cloud Storage Connector logs with one simple command line:

logverify verify -dir /opt/Syncplify/sc-conn/audit -identity /opt/Syncplify/sc-conn

The source code is on GitHub here: https://github.com/syncplify/logverify

All that… for what?

Reason #1: addressing the hidden logical fallacy

The one thing that often goes unsaid in the zero-trust SaaS world is that, in most cases, you still have at least one party you must trust: the vendor itself.

And… one is not zero.

We don’t want you to “just trust us”. We’re giving you the tools to verify our claims. And we’re open-sourcing the verifier, so you can audit its honesty and reliability yourself.

Reason #2: treating customers with fairness

There’s this little thing called Service Level Agreement (or SLA, for short). It says that if the service degrades below certain levels, you get some sort of compensation (typically in the form of credits).

The problem is that with most competitors the whole burden of proof is on you. You have to detect the failure, you have to develop the evidence, you have to report it, and you better do it within 60 days or your claim is invalid.

Enough with that! Who wants that anyway?

With SFTP.cloud we monitor the platform, detect degraded services and outages, attribute them to the correct side, digital sign the evidence, give you all the tools to verify our claims, and then we automatically give you the service credits you deserve.

Because we believe that when you buy a service, measuring its reliability and acting on those signals should be part of the service you pay for. It’s that simple.

So… how do you sign up for your 2 FREE MONTHS?

Just go to https://sftp.cloud, scroll to the bottom, and fill in the form.

What’s changed?

• This is the last of 9-step process that completes the transformation of our HA (high-availability) subsystem, which we begun a few months ago; this step added 25 massive scale tests to our CI/CD pipeline, covering edge cases like millions of users/VFSs and hundreds of virtual sites on dozens of cluster nodes

• The above test suite allowed us to find and fix one latent bug that only affected large scale HA deployments (the fix is confirmed live, in production, by large customers who were given early access to v8.1.4)

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Fixed a UI bug which prevented the R2FS! node identity key from being displayed if you created/edited an admin account before creating your first VFS configuration

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Fixed a bug in the worker process that prevented proper propagation of “shared object links” to the other nodes of an HA cluster

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• This is a PERFORMANCE RELEASE, designed to take full advantage of the stream multiplexing and buffer auto-tuning in R2FS! v2.2.1.
  If you use an R2FS! backend and are used to “capping it out” at around ~1 Gbps, this version unleashes transfer speeds up to 90x better, provided your network and back-end storage can keep up with it 😉

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• We call this our PERFORMANCE RELEASE. We added stream multiplexing and auto-tuning of memory buffers (configurable individually per-VFS). The results are mind-blowing: we went from a maximum throughput of ~1.08 Gbps (no matter how fast your network and storage were) to saturating a 10 Gbps network without even pushing it on real hardware here at our offices (and our estimates show that ~88 Gbps over a 100 Gbps network should be easily attainable).
  NOTE: requires Syncplify Server! v8.1.2 or newer.

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Added 6 new bounds-checkers and 2 more “panic recovery” paths ◀ this is the key improvement in v8.1.1 which make this version far more stable than any version before it

• Hardened a few code paths to better deal with Windows-specific inability to include stderr output in its Event Log (our Linux version was never affected by this bug because it’s OS-specific)

• Fixed a problem with VFS quota-updater that could occasionally blank-out remote/cloud VFS credentials upon saving the VFS configuration

• Fixed a WebClient! UI problem with the shared-object password field relying on the browser’s credential storage for auto-fill

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Added an optional checkbox to the Admin UI to enable mandatory strict key-pinned TLS negotiation with R2FS! v2.2+; enabling this option will require R2FS! v2.2 or newer (just released today) and fail when the R2FS! version you’re running is below that release number

• Fixed the shared-object link sent in notification emails which mistakenly did not contain the protocol, host and port

• Fixed semantics of “same IP on PASV” which was interpreted backwards

• Added an auto-recoverer and improved channel-open correctness tests in the SSH (SFTP) listener

• Dropped reliance on the system’s shell (sh, bash, cmd, powershell, …) and implemented a fully self-contained (and jail-rooted) minimal shell focused entirely and exclusively on a small set of file-related commands (after all this is a file-transfer server, it was never meant to be a replacement of OpenSSH for complete remote system management); in this v-shell type help to see a list of available commands

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Added a stricter pinned-key TLS mode, designed to work in conjunction with Syncplify Server! v8.1+ (which is itself scheduled to be released later today); when enabled R2FS! will refuse to connect to Server! versions prior to v8.1 to prevent the possible adoption of a more relaxed TLS enforcement
  NOTE: even with this setting disables, when R2FS! v2.2+ connects to a Server! v8.1+ the stricter TLS mode is always guaranteed to be enforced

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

Up till now, we simply didn’t need one. We sold software you downloaded and ran yourself. Your files sat on your servers. Your users lived in your directory. Your logs stayed on your disk. We had nothing of yours to protect, so there was very little for an auditor to look at, and a report confirming that we held no customer data would have been an expensive way to state the obvious.

But we’re about to launch SFTP.cloud now, and that makes everything more interesting. It is a service we operate, which means we now have uptime to be responsible for, access to our own systems to control, people to vet, and changes to manage. Those are fair questions and customers must be given the answers without having to ask them.

Here’s the wrinkle, and we rather like it: we still don’t have your files. SFTP.cloud is built so that customer data stays in customer storage, and so that we never hold the credentials to reach it. A good portion of what a SOC 2 report usually existsfor still doesn’t apply to us. What’s left is how we run the service, and that is exactly the part we want examined.

Now the part we’re less polite about

We have a low opinion of compliance as an idea. It shares more than a first syllable with complacency. A framework is an easy thing to perform rather than practice, and a certificate has never once stopped a vulnerability from shipping.

We started this because the work has value on its own. Writing down how you actually do things, and then finding all the places where you don’t, is useful whether or not somebody checks afterwards. Access reviews you can’t quietly skip. Change management that leaves a trail. Onboarding and offboarding that run the same way every time instead of the way whoever was free that afternoon remembered it.

We have done most of this for years. Doing it in a standardized form that a third party can inspect is a different beat altogether, and it can make us better.

If the certificate turns out to be the least interesting thing we get out of this, that will be the right outcome.

What happens next

The Type 2 observation window runs for months. We’ll publish the report when we have it, and we’ll write about what we learned, including the parts that were uncomfortable (if any).

Until then, nothing about how SFTP.cloud is built depends on any of this. Your files are still yours, still in your storage, still reachable only with credentials we never see.

“Zero trust” appears on almost every MFT website nowadays. Usually right next to a padlock icon, a compliance badge, and a sentence about encryption in-transit and at-rest.

Then you read the architecture page, and realize the files live on their servers, or they require the credentials and an in-path to access your storage. LOL! 😂

Both things cannot be simultaneously true: Zero Trust is not a “feature”, it’s an architectural property of the system, it’s either built-in by design, or it doesn’t exist.

What zero trust actually asks of an architecture

Strip away all the marketing blah-blah, and the requirement becomes clear: never grant standing trust + verify every request + assume any component can be compromised. Bottom line: design the entire platform so that when one of its parts falls, the damage stops there (aka, minimize the blast radius).

That last part is the one this industry keeps pretending it doesn’t exist. Zero trust is not primarily about how strong your authentication is, it’s about what an attacker gets when an attacker skips through a crack anyway. If the answer is “your files”, the model has failed, no matter how many authentication factors guarded the door.

So the honest test for any managed cloud SFTP service is a single question: if someone (a hacker, a rogue AI agent, you name it!) fully compromised the vendor’s platform tomorrow, what would they walk away with?

Where the trust actually sits in most of this category

There are two common answers today, and neither one survives the question.

The vendor holds your files. They sit on the vendor’s infrastructure, sometimes only during a transfer, often for much (much!) longer. Everything about your security posture now depends on that vendor’s operational discipline being perfect, permanently. You have granted a standing trust relationship to an environment you cannot inspect, patch, monitor, or contain. That is an implicit trust zone. It is precisely the thing zero trust was designed to eliminate.

The vendor holds your storage credentials. This one somehow manages to “feel safer” (the mighty power of marketing?) but that’s precisely why it’s worth being extra careful about it. Your files stay in your own S3, GCS, or Azure Blob storage. The vendor simply holds an access key, an IAM role, or a service account so the platform can reach in and fetch them… Hum, wait, what? 🤔

Look at what was actually granted! A credential that can read your storage is functionally the same as holding the storage, only with a minuscule built-in delay. Compromise the platform, extract the credential (often already held in RAM, unencrypted and trusted, for speed) and the outcome is identically catastrophic.

Both models come to the same place: they ask you to extend permanent trust to an environment outside your control, and they call the result “zero trust” because the traffic is encrypted.

Encryption is not the same as zero trust

Encryption protects data from parties who are not holding the keys, it stops nothing against a party who does.

This is why “encrypted in transit and at-rest” is a weak claim in this category and always has been. A secret held by an endpoint cannot defend against that endpoint’s own compromise.

So, a service can be fully encrypted, competently run, compliant with several frameworks and regulations, and still fail every meaningful zero trust test.

What passing the test would look like

If the standard is “compromising the vendor yields nothing”, then the architecture has to satisfy way stricter conditions than the ones described above.

• Customer files must never reside on the vendor’s infrastructure. Not in transit staging, not in a cache, not briefly, not ever.

• The vendor must never hold a credential set that grants access to customer storage. Not scoped, not rotated, not vaulted. It simply has to be not-held.

The path to storage must be opened from the customer side, outwards to the SaaS MFT side, so nothing in the vendor’s platform can initiate a reach inward even if it wanted to.

Storage is wherever the customer already keeps it, cloud or on-premises, because a design that only works when the customer’s data is in someone else’s cloud has the exact problem we are trying to avoid built into its design.

Those conditions are demanding. They also rule out most of what is currently sold as zero trust managed file transfer. And that is the whole point.

Why we keep coming back to this

This level of True Zero Trust is the design goal we set for SFTP.cloud before we even wrote its first line of code, and it is the reason the architecture looks so unusual. We do not hold your files. We do not hold keys into your storage. We never needed a way to reach into your network, so we did not build one.

So, when you evaluate your next MFT solution, ask yourself what an attacker gets when the platform falls. Then decide whether the words on the homepage matched the answer.

We are building SFTP.cloud to give a boring answer to that question. Early access is open to the first 100 people who want in: reserve your spot at sftp.cloud. Not ready yet? Subscribe to this blog and we will keep you posted.

What’s changed?

• Identity verification during HA-JOIN is now mutual and bidirectional

• Increased password hashing rounds to the levels required for full FIPS 140-3 compliance (and all existing hashes are automatically upgraded at next login with zero administrative burden)

• Fixed a bug that allowed a SuperAdmin to create a password-less SuperAdmin account (the password-less SA would be dead-on-arrival though, as password-less SuperAdmin logins are always forbidden by the API, so this does not constitute a widening of the software’s security posture)

• Strengthened TOTP replay prevention in all 2FA/MFA paths, now even cross-node when the software runs in high-availability (HA) deployments

• Improved the TOTP general user experience (UX), now featuring recovery codes (shown only once during enrollment)

• Added the ability for each individual user to revoke “trusted devices” (specifically for the TOTP authentication path)

• WebClient! now properly honors the “force change password” and “force enroll in MFA” settings when an Admin sets them for a specific user account

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

Today, less talk. We want to show you something.

These are the first screenshots of SFTP.cloud we share publicly. It’s early. This is an alpha, closer to a minimum viable product than a finished one, and plenty will change before launch. But it’s real, it runs, and the pieces you’ve been reading about are on screen and working.

The Portal: your site, at a glance

This is where you’ll manage a site. Connection addresses for every protocol your people might use (SFTP, FTPS, web), users, storage, billing, all in one place. There’s even a bring-your-own-domain option.

And look at the “Service status” panel for a second. Notice it’s split in two. On one side, our platform, the parts we run and stand behind with an SLA. On the other, your connectors, running on your network, on your terms. That split isn’t a UI accident. It’s the whole idea, showing up in the interface: the parts we operate and the parts that stay entirely yours are, and always will be, separate things.

The Connector: where your storage stays yours

This is the other half. The connector runs next to your storage, wherever that happens to be, behind your own firewall with no open inbound ports, and links up to your site.

The panel at the top says “Uplink to your site,” and the word uplink is doing real work there. The connection goes one direction: from your storage, outward. We’ll have a lot more to say about why that matters closer to launch. For now, we’ll just let it sit there, connected, quietly not requiring a single thing to reach in.

This is the part where we ask you to be patient

There’s a real product behind these screens now, and it’s improving every week. We’re not putting a date on the table yet, and we’re deliberately not walking through some of the finest details of the architecture (for now).

What we can tell you is that everything we’ve been claiming in these posts (files that never live in our cloud, storage that stays entirely under your control, nothing reaching inward through your firewall) isn’t a roadmap wish or a marketing claim. It’s what you’re looking at.

Want to see it for real before anyone else? We’re opening early access to the first 100 people who reserve a spot now and get 2 months completely free when the platform launches: claim your spot at SFTP.cloud. Not ready yet? Subscribe to this blog and we’ll bring the next news straight to you.

What’s changed?

• Fixed a bug that only affected R2FS!-type Virtual File Systems (VFSs) and prevented the Content-Disposition header from being properly formatted upon downloading files from the WebClient! UI. Special thanks to our friend Jeff, not only for finding and reporting this, but also for helping us reproduce the issue in our own systems, which ultimately made the fix nearly trivial.

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!