How it works

Your files move. We never hold them.

SFTP.cloud is managed file transfer built so that the company running it never hosts your files, never holds the credentials to your storage, and cannot change the record of what happened.

None of that rests on a policy. It follows from how the system is put together, and this page walks you through each part.

Start your free trial See the security architecture

14 days. No credit card. No feature locks.

The architectureData path
SFTP · FTPS · HTTPS OUTBOUND · mTLS Your files are never stored in SFTP.cloud Partners and staffthe client they already use SFTP.cloudterminates the protocol · authenticates the userenforces your rules Storage Connectoryou install it · you hold its keys Your storageS3 · Azure · GCS · MinIO

01The components

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

You run the part that touches your data. We run the two parts your users and administrators connect to.

Runs in your network

Your Storage Connector

A small service you deploy next to your storage: in your datacenter, your VPC or your cloud account, as a system service or a Docker container. It reads and writes your files with credentials that never leave your network, and it runs the automation you configure.

Your files
Read/write, inside your network
Storage credentials
They never leave your network

Run by SFTP.cloud

The SFTP.cloud Head

The public endpoint your partners and users connect to, also called the Protocol Head. It terminates SFTP, FTPS, FTPES and HTTPS, authenticates the user and applies the first layer of your access rules.

Your files
In transit only, never written to disk
Storage credentials
None

Run by SFTP.cloud

The control plane

Where you configure accounts, permissions, automation and policies. Your Connector and your administrators both reach it outbound, so you never add an inbound firewall rule.

Your files
Never
Storage credentials
None

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

02The mechanism

A file transfer, start to finish.

The architectureStep 1 of 6
YOUR INFRASTRUCTURE SFTP · FTPS · FTPES · HTTPS VOUCHER VOUCHER OUTBOUND · mTLS PORT 7600 · PARALLEL Partners and stafftheir usual client SFTP.cloud Headterminates the protocolapplies your rulesaudit chain · our key Control planeaccounts · policiessession vouchers Storage Connectoryou install it · you hold its keysSyncJS automationaudit chain · your key Your storageS3 · Azure Blob · GCSMinIO · SMB · NFS · localupstream SFTP

03Automation

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 its content, their servers have to read it.

SFTP.cloud runs your automation on your Connector instead, in a full JavaScript environment called SyncJS. Every script executes inside your network, on infrastructure you control, with the tools you choose.

Event handlers can run before an operation as well as after it, so a script can stop a transfer before it begins.

Runs on your Connector

  • PGP decryption
  • Malware scanning
  • Checksums
  • Renaming and splitting
  • Routing by content
  • A call to your internal API when a partner delivers

Before an operation

Block an upload before it starts, or filter what a directory listing shows.

After an operation

Decrypt, scan, rename and route the file, then notify your own systems.

You get the automation. We never get the file.

04HTTPS 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.

Transfers run server-side, so they finish even if the browser is closed.

You can also share a file or folder with people outside your organization. Each share carries its own rules: a name and description, an expiration date, the permissions the recipient gets, and the security they have to pass to open it. Every access lands in the same audit trail.

Creating a shared folder in the WebClient. Expiration, permissions and security are set on the share itself.
Creating a shared folder in the WebClient. Expiration, permissions and security are set on the share itself.

05Failure modes

What happens when things go wrong?

01

If your Connector goes offline

Transfers to that storage stop, and users get a clear error instead of a hang. The Connector reconnects by itself when it comes back, with nothing to reconfigure.

02

If your network drops mid-transfer

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

03

If the Head has a problem

Your storage and your data are unaffected. New connections can’t be accepted until the Head is back. Your files were never on it.

04

If someone compromises our infrastructure

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

06Deployment

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 to reach storage in different networks.

  2. Outbound rules only.

    The Connector needs to reach the SFTP.cloud Portal and your SFTP.cloud Head on port 7600. Those are the only firewall rules you add, and both are outbound, so nobody can reach your network through them.

  3. Connect the storage you already own.

    Local disks, SMB, NAS or SAN, an upstream SFTP server, Amazon S3 or any S3-compatible store, Azure Blob Storage, or Google Cloud Storage. Keep your files as they are, or encrypted with a key that stays on the Connector.

See it work on your own storage.

Deploy a Connector, connect your storage and run a transfer end to end. Fourteen days, no credit card, and nothing to cancel if it is not for you.

Start your free trial

Want more detail first? Read the security architecture or talk to an engineer. The person who answers builds the product.