Models and scans in the tens of gigabytes
Federated BIM models, laser-scan point clouds and photogrammetry are large and updated often. Emailing links to a drive is how versions get mixed up.
Architecture, engineering & construction
A federated model, a scan of the existing building and the current drawing set are gigabytes to terabytes, held by different firms on different networks and needed on site with a poor connection. RIPTON CLOUD moves those project folders between the organisations on a job as single packages.
Plan limits are those published on the pricing page. Benchmark figures come from RIPTON CLOUD's published EC2 test at roughly 150 ms latency and 3% packet loss. Results on your route depend on your network, endpoints and storage. RIPTON CLOUD does not claim any industry certification on this page.
Project server or site laptop
RIPTON Desktop or browser
RIPTON node at the other firm
Their project folder
Between firms and sites
Project data is exchanged between separate companies at every stage, from design coordination to handover, and site connectivity is often the worst link in the chain.
Federated BIM models, laser-scan point clouds and photogrammetry are large and updated often. Emailing links to a drive is how versions get mixed up.
Issue sets, specifications and photo logs are many files. Tools that handle each one separately spend the day on overhead.
Site offices and field laptops are on cellular or shared links where ordinary transfers stall.
Workflows
BIM · CAD · point clouds
Send a model or scan package to named contacts at the other firm. Each gets a scoped link; the download is recorded so the issue is traceable.
Issue sets · specifications · handover
Send drawing and specification sets as packages with expiry you set. Recipients download from a browser with no account.
Scans · progress photos · reports
Give site teams and surveyors a Shared Inbox so scans, photos and reports come back as folders, not attachments.
RIPTON CLOUD in the workflow
The product earns its place by moving prepared data between endpoints—not by claiming ownership of every system around it.
Any number of files travel and are stored as a single package with the folder structure kept.
A record of who received which issue and when they downloaded it, for the project record.
The RIPT protocol is built for high-latency, lossy connections, and interrupted packages resume rather than restart.
AES-256-GCM or ChaCha20-Poly1305 with a forward-secret key per session and replay protection. There is no plaintext mode to misconfigure.
Throughput depends on your route, endpoints, and storage. The published benchmark (a 1 GB file 7.5x faster than the TCP baseline at 150 ms and 3% loss) tells you where the difference appears; your own route tells you how much.
Product boundary
RIPTON CLOUD moves project files between organisations and records the movement. It does not replace your CDE, model-checking or document control.
Evaluation path
Bring one real handoff, usually to the firm or site that always waits longest, and measure both tools.
Office to office, office to site or site to office. One route.
The real federated model or scan with each tool, elapsed time and restarts recorded.
The full drawing set, so file-count overhead is measured.
Hours from issue to receipt, and courier costs avoided, written down.
FAQ
No. It moves files between organisations and sites. Publish to the CDE as you do now; use RIPTON CLOUD where the CDE's own transfer is the bottleneck or where the other party is not on it.
Yes. Recipients download from a browser with a scoped link. They do not use a named seat and are not charged.
10 GB per file on Free, 100 GB on Starter, and no file-size limit from Professional up.
The protocol is designed for high-latency, lossy links and resumes interrupted packages. How much faster it is than your current tool depends on the site connection; the evaluation measures it.
Technical evaluation
Start a free workspace, or bring one handoff between firms and we will help you measure it.