Native file access
Choose local files or folders through the desktop application instead of exposing machine paths to a browser page.
RIPTON Desktop
Move demanding local workloads through a native transfer path.
RIPTON Desktop is the primary data path for demanding local workloads. The browser prepares and authorizes the package; the native application selects local files, moves the data, and reports progress into the same governed workflow.
RIPTON CLOUD / RIPTON Desktop
01
entry
Local files
02
control
Browser authorization
03
transfer
RIPTON Desktop
04
evidence
Progress + recovery
Why it matters
A product capability tied to an operational outcome.
One governed package
Keep recipients, policy, authorization, progress, and completion tied to the package prepared in RIPTON CLOUD.
Operational recovery
Preserve completed progress and focus supported recovery on missing work after an interruption.
How it works
From entry point to evidence.
The workflow stays understandable at every stage, with the control plane coordinating policy and the data plane moving supported workloads.
- STEP 01
Prepare in the browser
Create the package, add recipients, and apply supported package controls in the control plane.
- STEP 02
Open Desktop
Use the authorized handoff to open RIPTON Desktop and choose the local workload.
- STEP 03
Move the package
Desktop runs the local transfer session and reports measured throughput, progress, and state.
- STEP 04
Verify the result
Review completion, transfer history, and diagnostics in the product surfaces available to the user or operator.
Capability detail
What your team can inspect and use.
macOS, Windows, and Linux
RIPTON Desktop is supported across the three desktop operating-system families used by production and technical teams.
Local path privacy
The native picker and transfer process keep local filesystem paths outside the browser page.
Progress and state
Active transfer state, measured throughput, queue context, and completion remain visible during the handoff.
Resume and diagnostics
Supported recovery preserves completed work, while history and diagnostics help explain interruptions and retries.
Operational evidence
A native transfer client connected to the same control plane.
Desktop is not a separate unmanaged utility. It receives an authorized package setup and reports the transfer result back to RIPTON CLOUD.
- Desktop readiness and version state
- Active and queued transfers
- Measured throughput and progress
- History, recovery, and diagnostics
Continue exploring
Related platform and solution pages.
Browser workspace
Prepare and authorize the package before Desktop moves it.
Explore →Web Edge
Use an eligible browser transfer path when installing Desktop is not practical.
Explore →Move large files faster
See the business problem this native path is built to address.
Explore →Send with RIPTON Desktop
Install, hand off from the browser, pick files natively, follow throughput.
Explore →Why transfers slow down over distance
The latency and loss arithmetic that the accelerated path is built for.
Explore →Compared with IBM Aspera
Deployment, pricing model and evidence, from Aspera's own published pages.
Explore →Frequently asked questions
Technical questions, answered plainly.
Which operating systems does RIPTON Desktop support?
RIPTON Desktop supports macOS, Windows, and Linux.
Is Desktop independent from the browser workspace?
No. The browser prepares and authorizes the package, and Desktop handles eligible local file selection and transfer while reporting state back into the same workflow.
What happens after an interruption?
Supported recovery focuses on missing work while preserving completed progress. Transfer history and diagnostics help the technical team review what happened.
Evaluate the workflow
Evaluate Desktop on the workload and route that matter.
Use representative files, endpoints, and network conditions. We will record the setup, compare the current baseline, and review the result with your technical team.