Lower-friction access
Support an eligible upload or download when installing a native application is not practical for the participant.
Web Edge
Provide an eligible browser path without abandoning transfer policy.
Web Edge gives eligible external or occasional users a controlled browser-based transfer path. RIPTON CLOUD checks the package, user or external access, and node policy before setting up the session through an eligible edge node.
RIPTON CLOUD / Web Edge
01
entry
Eligible browser
02
control
Policy check
03
transfer
Web Edge node
04
evidence
Package status
Why it matters
A product capability tied to an operational outcome.
Same package policy
Keep browser transfer setup behind the same package, recipient, external-access, and node eligibility checks.
Visible fallback state
Expose the selected Web Edge path, transfer state, node context, and completion inside the product workflow.
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
Open the approved flow
Begin from a signed-in package or supported public upload or download experience.
- STEP 02
Check eligibility
RIPTON applies current package policy, access scope, fallback permission, and node eligibility.
- STEP 03
Issue the session
A short-lived setup connects the browser operation to the selected eligible Web Edge node.
- STEP 04
Track the transfer
Progress and final state return to the package workflow for the participant and authorized operators.
Capability detail
What your team can inspect and use.
Eligible browser transfer
Provide upload or download through the browser for supported workflows and policy conditions.
Preferred edge selection
Administrators can identify eligible nodes and configure a preferred Web Edge path in the current node model.
External-flow support
Web Edge can support eligible public package and shared-inbox experiences after external access is approved.
Unified status
Browser-path transfers remain connected to the same package state, activity, and operator visibility.
Operational evidence
Browser convenience with an explicit transfer-node boundary.
Web Edge is a data path, not an unrestricted public upload endpoint. A supported session depends on package state, access scope, node configuration, and current policy.
- Eligible and preferred node state
- Selected browser transfer path
- Progress and transfer status
- Fallback and node diagnostics
Continue exploring
Related platform and solution pages.
RIPTON Desktop
Use the primary native path for demanding local workloads.
Explore →Public links
See how external access is scoped before a browser transfer begins.
Explore →Administration and nodes
Configure and observe eligible transfer nodes.
Explore →Large directory transfer
Hundreds of thousands of files as one package, from a browser or Desktop.
Explore →Send a folder from a browser
The guide for the Web Edge upload path.
Explore →What happens when you send a folder from a browser
Workers, batches and where the time goes, with our measurements.
Explore →Frequently asked questions
Technical questions, answered plainly.
Is Web Edge available for every transfer?
No. The browser path depends on current package policy, external-access scope where applicable, node eligibility, and fallback configuration.
Does Web Edge bypass RIPTON policy?
No. The supported setup is issued only after RIPTON applies the relevant package, access, and node checks.
When should a team use Desktop instead?
RIPTON Desktop remains the primary path for demanding local workloads. Web Edge is intended for eligible situations where installing or opening the native application is not practical.
Evaluate the workflow
Test the browser path with the external workflow you expect to support.
We will review the participant, package policy, node configuration, fallback eligibility, transfer setup, and operator evidence together.