Throughput collapses with distance
A single TCP stream slows as latency and packet loss rise; the gigabit link you pay for carries a fraction of that to a far site.
FTP and SFTP replacement
Replace the FTP server without replacing how your partners work.
Most FTP servers are still running because replacing them looked like a project: accounts to recreate, partners to retrain, scripts to rewrite. RIPTON CLOUD replaces the part that hurts, large files and outside parties, one route at a time, and leaves SFTP where a partner insists on it.
Benchmark figures come from RIPTON CLOUD's published EC2 test at roughly 150 ms latency and 3% packet loss. Your route decides your result.
Evaluated transfer path
01
Your storage
02
RIPTON node
03
Browser or RIPTON Desktop
04
Partner or team
Why the FTP server is still there
It works, until the file is large, the link is long, or the auditor asks.
FTP and SFTP move bytes over one TCP stream, per file, to accounts you administer by hand. That is fine for small files between two servers on a good link. It is the wrong tool for a 200 GB delivery to a partner across an ocean.
Accounts for every outsider
Each partner is a server account with credentials to issue, rotate and eventually forget. Plain FTP also sends them in clear text.
No record anyone can use
Server logs say a login happened. They do not say which package a partner downloaded, when it expired, or who approved it.
Workflows
Where the transfer path matters most.
Deliverables · masters · signed exports
Partner deliveries
Send a package to named recipients who download from a scoped, expiring link in a browser. No server account, no client to install.
Vendor submissions · returns · intake
Partner uploads
Replace the inbound FTP drop with a Shared Inbox or a public upload link: approved senders, access requests you review, and a durable destination your team owns.
Nightly exports · archive seeds · mirrors of prepared data
Scheduled site-to-site moves
Move what a cron job and a script used to move, with schedules, run history, retries and webhooks that operators can inspect.
RIPTON CLOUD in the workflow
What replaces the server
The product earns its place by moving prepared data between endpoints—not by claiming ownership of every system around it.
Links, not accounts
External recipients and uploaders use short-lived, scoped credentials issued for one package or one inbox; they never consume a seat and never get a login to your infrastructure.
Accelerated over distance
RIPTON Desktop and node-to-node transfers use the RIPT protocol rather than a single TCP stream. In the published test at 150 ms latency and 3% loss, a 1 GB file finished in 4 minutes against 30 for the TCP baseline.
Encryption you cannot switch off
Every packet is encrypted and authenticated with a forward-secret key per session. There is no plaintext mode to misconfigure.
Records and lifecycle
Per-package transfer records, recipient download events, expiry, revocation on state change, and structured audit logs.
Automation without scripts
Reusable schedules with time zones, pipelines with checksum and validation steps, retries, run history, scoped API credentials and webhooks.
No generic speed promise
Whether the accelerated path pays off depends on your route. A side-by-side against your current SFTP transfer on that route is the first step of every evaluation.
Product boundary
A replacement for the workflow, not a protocol emulator.
RIPTON CLOUD does not speak FTP or SFTP. It replaces what those servers were used for. Where a partner's system can only talk SFTP, keep that endpoint for that partner.
What it covers
- Person-to-person and partner package delivery
- Inbound uploads through Shared Inboxes and public links
- Scheduled and event-driven transfer pipelines
- Expiry, revocation, records and audit
What stays with your stack
- FTP, SFTP or FTPS wire compatibility
- AS2 or EDI trading-partner protocols
- A general-purpose file server or shared drive
- Arbitrary script execution on the node
Evaluation path
Retire the server one route at a time
Nobody replaces FTP in a day. Pick the route that hurts most, move it, measure, and repeat.
- 01
List the routes
Which partners, sites and jobs use the server, how large the files are, and which of them still require SFTP on the far end.
- 02
Move the painful one
Set up the recipients or the Shared Inbox for that route and run one real delivery alongside the existing transfer.
- 03
Compare elapsed time and effort
Time to deliver, retries, and how many people were involved on both ends. Write it down.
- 04
Retire and repeat
Remove the accounts for that route, keep the records, and take the next one.
FAQ
Questions technical buyers ask.
Can my partners keep using their SFTP client?
Not against RIPTON CLOUD; it is a different protocol. Partners receive a browser link, which needs no client, or use RIPTON Desktop for the accelerated path. If a partner's automated system can only speak SFTP, keep that endpoint for them.
What happens to my existing scripts?
Scheduled transfers become schedules and pipelines in the product, with run history and retries. Anything that called the FTP server from code moves to the REST API or CLI, available from the Professional plan.
Is the free plan enough to try this?
For a single route with files up to 10 GB and 25 GB a month, yes. Larger routes are what the guided evaluation is for.
Does replacing FTP make transfers faster?
On a short, clean link, not much. On a long or lossy link the difference can be large; the published benchmark and the calculator show the effect, and the evaluation measures it on your route.
Technical evaluation
Move the route that hurts off the FTP server.
Bring the partner or site that waits longest. We will help you run one delivery each way and compare it with the transfer you have today.