Features

Automation that runs
on your side.

SyncJS automation Runs on your side
The SyncJS automation pipeline A partner delivers a file over SFTP, FTPS or HTTPS. Inside your infrastructure, SyncJS before-handlers inspect the operation and can refuse it before it begins. The file is written to your storage, and after-handlers run: PGP, scanning, checksums, renaming, content routing, and calls to your own API. Everything executes next to your data. SFTP.cloud never gets the file. YOUR INFRASTRUCTURE · SCRIPTS RUN NEXT TO YOUR DATA blocked before it begins A partner delivers SFTP · FTPS · HTTPS Before handlers inspect the operation and can call BlockOperation() Your storage written where it lives After handlers PGP · scan · checksum · rename route by content · call your API You get the automation. We never get the file.

Your Storage Connector runs SyncJS, a full ECMA 5.1 JavaScript environment extended with a substantial standard library of 200+ custom functions specific to your SFTP.cloud environment. Your scripts execute inside your network, next to your data, on infrastructure you control.

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

SyncJS

A policy engine as well as an automation engine.

  • Fifteen event handlers

    Before and after each operation that matters: file uploads, downloads and deletions; folder creation, deletion and listing; renames and moves; folder listing filters; and tunnel disconnection. 

  • The "before" handlers can refuse.

    A script running before an upload can inspect it and call BlockOperation() to stop it. That makes SyncJS a policy engine as well as an automation engine, because you can enforce a rule at the moment of the operation instead of reacting after it has already happened. 

  • A real standard library.

    HTTP and HTTPS requests. SQL against your own databases. AMQP message queues. PGP encryption, decryption and signing. Hashing, HMAC, Base64, CSV and XML. Zip and gzip. Image resampling and metadata. External process execution. Slack, Teams, Telegram, Twilio and SMTP. Remote SFTP, FTP, S3, Azure, GCS clients. And a lot more.

  • Filter a folder listing.

    What a user sees in a directory can be decided by your logic rather than by whatever happens to be on disk.

  • Secrets stay out of your code

    Scripts pull credentials from managed secret storage rather than having them pasted into the source.

  • Written in the editor you already use.

    A VS Code extension gives you IntelliSense, and MCP servers are available if you want AI assistance while authoring. 

Everywhere else, this logic runs on the vendor's servers, which is why those vendors have to be able to read your files.
With SFTP.cloud it runs on your Storage Connector, which is why we do not.

Everywhere else, this logic runs on the vendor's servers, which is why those vendors have to be able to read your files. Here it runs on yours, which is why we do not.

Protocols

Protocols your partners already use

SFTP, FTPS and FTPES

For the systems and scripts your partners already have, including the ones written a decade ago that nobody is willing to touch.

HTTPS web client

For people who will not install anything, with secure sharing links for one-off exchanges. 

Standard clients, standard ports.

Nothing proprietary for your partners to install. 

The WebClient

Every file, from any browser.
No software to install.

Upload, move, rename and share from a clean web interface that runs anywhere. Switch between list, grid and preview views, watch transfers in real time, and hand off long operations to the server so they keep running after you close the tab.

Screenshot SFTP.cloud WebClient browser-based file manager showing several items, including folders and two image files (with optional thumbnails).

Protocols

The storage you already own.

Local and network storage, including SMB/CIFS and NFS shares, DFS, or your NAS/SAN.

Upstream SFTP servers, so an existing server can sit behind SFTP.cloud without being replaced. Amazon S3 and S3-compatible storage, including MinIO. Azure Blob Storage. Google Cloud Storage.

Connect several at once, across different clouds and different networks, with a Connector in each. Your files stay in the account, region and jurisdiction you already chose. 

And optionally encrypted, with a key we never have. Every backend can hold your files in plain form or encrypted, using a key that lives on your Storage Connector. Bring your own key, keep your own key, and anyone who reaches your storage by another route only finds encrypted stuff.

Defense

Defense that acts before an administrator can.

Automatic blocking of attacking addresses.

Repeated failed authentication from an address gets it banned automatically, with no administrator involvement. Abuse attempts or protocol errors are deterministically identified (no guesswork) and also trigger the auto-ban. 

Geo-fencing.

Restrict an account to the countries it should ever be used from. 

Connection allow-lists and safe-lists.

Authored by you, on Dedicated environments. 

Post-quantum cipher suites.

On every protocol, and mutual TLS (mTLS) between every internal component. 

Audit

Audit you can verify

  • Two independent, signed audit chains for every session.

    One written by us and one written by your Connector, each hash-chained line by line and signed with a different key.

  • Every session, every file, every administrative change.

    on both sides. Yours is signed with a key that never leaves your Connector.

  • And a verification tool you run yourself.

    Download it, point it at your logs, and check them on your own machine. No account, no upload, no involvement from us at any stage. 

A console for everything.
An API for everything else.

Fourteen days on a shared environment, with your own storage connected. No credit card, and nothing to cancel if you decide it is not for you.

A web console for the whole configuration, and a REST API for everything you would rather automate. Accounts, permissions, Connectors, policies and automation are all scriptable.