How it works

Your files move.
Yet we never own them. 

The architecture Active path
SFTP.cloud architecture Partners and staff reach you over standard SFTP, FTPS or HTTPS. SFTP.cloud terminates the protocol, authenticates the user and enforces your rules. The Storage Connector runs next to your storage and opens an outbound, mutually authenticated connection to SFTP.cloud. Data moves between your storage and your user across the Connector's own channel and is never written to a disk SFTP.cloud owns. SFTP · FTPS · HTTPS OUTBOUND, MUTUALLY AUTHENTICATED Your files are never stored in SFTP.cloud Partners and staff the client they already use SFTP.cloud terminates the protocol · authenticates the user enforces your rules Storage Connector you install it · you hold its keys Your storage S3 · Azure · MinIO

SFTP.cloud is a managed file transfer service built on an unusual premise: that the company running your file transfer should never host your files, and should never possess the credentials to access them, reach your storage, or alter the record of what happened. 

That premise is a direct consequence of how the system is designed, and this page explains exactly how that works.

No credit card. No feature locks. Walk away by doing nothing.

The components

Three parts. Only one of them is near your files.

Architecture is why you would trust it. This is why you would use it. 

  • Your Storage Connector

    A small service you deploy next to your storage: in your datacenter, in your VPC, or in your cloud account, installed as a service or running in a docker container. It reads and writes your files using credentials that never leave your network, and it runs any automation you configure.

  • The SFTP.cloud Head

    The public endpoint your partners and users connect to, sometimes also referred to as the “Protocol Head”. It terminates SFTP, FTPS, FTPES and HTTPS, authenticates the user, and applies the first set of your access rules. It holds no files and no storage credentials.

  • The control plane

    Where you configure everything: accounts, permissions, automation, policies. Your Connector and your administrators both reach it outbound. There is never an inbound rule to be allowed through your firewall.

The mechanism

A file transfer, start to finish.

The architecture Step 1 of 6
A file transfer, on the architecture Users connect to the SFTP.cloud Head over standard protocols. The control plane issues a signed session voucher to both the Head and your Storage Connector. The Connector, inside your infrastructure, dials out to the Head over mutual TLS and streams files between your storage and your users. Automation and one of the two signed audit chains run on the Connector. SFTP · FTPS · FTPES · HTTPS signed session voucher signed session voucher Outbound · mTLS port 7600 · outbound only Your infrastructure Partners & staff their usual clients SFTP.cloud Head terminates the protocol · applies your rules audit chain · our key no files · no storage credentials Control plane accounts · policies · vouchers Storage Connector SyncJS automation · audit chain (your key) you install it · you hold its keys Your storage Local · SMB · NFS · upstream SFTP S3 · MinIO · Azure Blob · GCS optionally encrypted · the key stays on the Connector

Automation

Automation that runs
under your control

Most managed file transfer platforms run automation on their own infrastructure. If you want a file decrypted, scanned, renamed, split, or routed by content, their servers have to read it. 

SFTP.cloud runs automation on your Connector instead, in a full JavaScript environment called SyncJS. PGP decryption, malware scanning, checksums, renaming, content-based routing, a call to your internal API when a partner delivers: all of it executes inside your network, on infrastructure you control, using tools you chose. 

And because event-handlers can run before an operation as well as after it, a script can block a transfer before it begins. Block an upload before it starts, selectively censor a directory list, you name it. 

You get the automation. We never get the file. 

HTTPS access

The same storage,
through the browser.

Not every user has an SFTP client. The WebClient gives them the same virtual file systems, permissions and audit trail over HTTPS, with server-side transfers that finish even when the browser doesn't stay open.

Screenshot of SFTP.cloud WebClient sharing window, showing options for name, description, set expiration, permissions, and security for a shared folder.

Failure modes

What happens when things go wrong?

If your Connector goes offline

Transfers to that storage stop. Users receive a clean error rather than a hang. The Connector reconnects on its own when it comes back, and nothing needs to be reconfigured.

If your network drops mid-transfer

The transfer fails. It is not silently committed, and both audit chains record the failure.

If the Head has a problem

Your storage is untouched and your data is unaffected. You lose the ability to accept new connections until we are back. Your files were never here to begin with.

If someone compromises our infrastructure

They find no customer files, no storage credentials, no way to dial down into your network, and no ability to forge your audit trail.

Deployment

Deploying the Connector.

1

Run it wherever your storage lives.

On a server in your datacenter, as a container in Kubernetes, or as a small instance in the same cloud account and region as your bucket. Deploy more than one for redundancy or to reach storage in different networks.

2

One outbound rule, nothing else.

It needs to connect outbound-only to the SFTP.cloud Portal, and to your SFTP.cloud Head on port 7600. Nothing else. Those are the only firewall rules you'll need, and they’re outbound, no one can get in through them.

3

The storage you already own.

Connect local storage, SMB/NAS/SAN, an upstream SFTP server, Amazon S3 or an S3-compatible store, Azure Blob Storage, or Google Cloud Storage. Hold the files in plain form, or encrypted with a key that stays on the Connector.