Transfers have many entry points
People, partner workflows, shared inboxes, public access, schedules, pipelines, and applications all initiate different kinds of work.
MFT Platforms
Operate file movement as a controlled platform—not a collection of one-off transfers.
Ripton Cloud combines accelerated transfer with the control-plane surfaces platform teams need to administer users, endpoints, external flows, automation, and transfer operations inside one organization boundary per installation.
Current tenancy boundary: one organization per Control installation.
How your files move
- Users / applications
- Ripton Control
- Ripton nodes
- Storage / partners
Platform operations
A fast transport alone does not create a manageable transfer service.
Platform teams also need identity boundaries, reusable destinations, external access, automation, event delivery, operational history, and an API contract that can be reviewed before integration.
Operations need one view
Administrators need to manage users, nodes, jobs, package state, webhooks, retention, and failures without stitching together unrelated tools.
Integrations need stable contracts
Scoped credentials, documented endpoints, idempotent worker behavior, and inspectable events matter more than an undocumented automation promise.
Workflows
Where the transfer path matters most.
Users · workgroups · external guests
Managed user and partner flows
Coordinate named users, workgroups, shared inboxes, external recipients, and guest upload entry points.
OpenAPI · scopes · webhooks
API and event integration
Use a published OpenAPI contract, scoped service credentials, webhooks, and application events to connect surrounding systems.
Schedules · pipelines · retries
Automated operations
Use release schedules and durable pipelines for recurring calendars and event-driven package processing.
Ripton Cloud in the workflow
A control plane around the transfer path.
The platform separates human access, machine credentials, external access, endpoint operations, and workflow automation while keeping the deployment boundary explicit.
Published API surface
The control plane publishes REST operations through an OpenAPI contract for supported product, administrative, and service workflows.
Scoped machine access
Service principals and short-lived bearer tokens can be restricted to read or write scopes for nodes, transfers, users, jobs, and general API areas.
Durable automation
Schedules, DAG-based pipelines, leased work items, retry limits, run history, and idempotency controls support inspectable automation.
Operational evidence
Package state, transfer records, webhook histories, and an append-only audit log of transfer, download, sign-in, and administrative activity support day-to-day operations, compliance review, and forensic analysis. Audit events cannot be edited and can be exported to your SIEM.
MFT requirements
How Ripton Cloud covers what an MFT platform must do.
Buyers and analysts evaluate managed file transfer against a common set of capabilities. Each one below is part of the product today and runs inside your own deployment.
01
Secure, encrypted transfer
Every transfer is encrypted in transit. Browser and API traffic uses HTTPS, and Ripton's accelerated transfer protocol always encrypts with AES-256-GCM or ChaCha20-Poly1305, using a new forward-secret key for each session. There is no unencrypted mode.
Details →02
Multiple protocols and APIs
HTTPS for the browser workspace and browser transfers, Ripton's UDP-based accelerated protocol for Ripton Desktop and node-to-node transfers, a REST API published as an OpenAPI contract, and a command-line client for scripts and other systems.
03
Automation
Watch folders start transfers when files arrive, reusable release schedules time deliveries, and pipelines of up to 50 steps run on manual or package-event triggers with dependencies and conditions. Webhooks, the REST API and the CLI connect other systems.
04
Real-time monitoring and failure alerts
Ripton Desktop and the admin console show live throughput, active and queued transfers, and package status. Failed transfers, packages and deliveries raise events that are delivered to your webhook endpoints and SIEM, and service health checks report node and service problems.
05
Detailed, immutable audit log
Sends, views, downloads, transfer starts, completions and failures, sign-ins and administrative changes are recorded with actor, subject and timestamp. The log is append-only: recorded events cannot be edited, and removal happens only through an administrator retention policy that is itself audited. Events export to your SIEM.
Details →06
Enterprise identity and access control
SAML single sign-on with your identity provider, SCIM user provisioning, multi-factor authentication, roles and workgroups, resource-level grants, and scoped credentials for systems and scripts.
Details →07
Support for compliance programmes
Built-in controls support customers' GDPR, HIPAA, PCI-DSS and SOX programmes: mandatory encryption in transit, role-based access with MFA and SSO, the append-only audit log, file integrity verification, retention and expiry controls, recipient domain restrictions, and deployment on your own infrastructure so files never pass through a third party.
Details →08
Self-service for users, central control for administrators
Users create and send packages from the browser or Ripton Desktop; recipients download without an account; partners upload through Shared Inboxes and request access themselves. Administrators manage users, nodes, policies, webhooks, retention and branding from one console.
09
Resilience and automatic recovery
Interrupted transfers resume from the missing data instead of restarting. Failed webhook deliveries are retried automatically, and pipeline steps retry within configured limits. High-availability groups pair primary and standby nodes, and a healthy standby takes over new work when the active node fails its readiness check. Encrypted configuration backup and restore supports recovery.
Ripton Cloud does not itself hold compliance certifications such as SOC 2 or ISO 27001. Your compliance team decides how these controls fit your obligations. High availability covers the transfer service; replication of stored data stays with your storage platform.
Product boundary
One organization boundary per Ripton Control installation.
Ripton currently isolates one organization within each Control installation. It should not be represented as a shared-database multi-tenant SaaS control plane or as a drop-in protocol-compatible replacement for every legacy MFT integration.
What it covers
- Users, roles, workgroups, and shared inboxes
- REST API and scoped service credentials
- Schedules, pipelines, webhooks, and events
- Node, package, and transfer operations
What stays with your stack
- Multi-tenant partitions inside one Control database
- An SDK claim beyond the published REST/OpenAPI surface
- Universal FTP/SFTP protocol compatibility
- Automatic migration of every legacy MFT workflow
Evaluation path
Validate the platform surface—not only transfer speed.
A platform evaluation should verify identities, APIs, workflows, operations, upgrades, failure recovery, and support boundaries alongside the data path.
- 01
Inventory entry points
List human, partner, public, scheduled, event-driven, and application-initiated transfer workflows.
- 02
Map control boundaries
Review organization scope, roles, API scopes, endpoint ownership, external access, and administrative separation.
- 03
Exercise automation
Test schedules, pipelines, webhook delivery, retry behavior, idempotency, interruption, and observable run history.
- 04
Review operability
Confirm deployment, backups, upgrades, monitoring, audit retention, incident response, and support expectations.
FAQ
Questions technical buyers ask.
Is Ripton Cloud a multi-tenant SaaS MFT platform?
The current Control architecture uses one organization boundary per installation. It does not provide multiple tenant partitions inside one Control database.
Does Ripton provide an API?
Yes. Supported control-plane operations are documented through a REST/OpenAPI contract, with scoped machine credentials for integrations. Exact endpoint suitability should be reviewed against the intended workflow.
Does Ripton Cloud help with GDPR, HIPAA, PCI-DSS or SOX?
Its built-in controls support those programmes: mandatory encryption in transit, role-based access with MFA and SSO, an append-only audit log with SIEM export, integrity verification, retention controls, and deployment on your own infrastructure. Ripton Cloud does not itself hold compliance certifications; your compliance team decides how the controls fit your obligations.
What happens when a transfer, webhook or node fails?
Interrupted transfers resume from the missing data. Failed transfers, packages and deliveries raise events for your webhooks and SIEM, failed webhook deliveries are retried automatically, and in a high-availability group a healthy standby node takes over new work when the active node fails its readiness check.
Is it wire-compatible with every FTP or SFTP workflow?
No universal compatibility claim is made. Ripton is an alternative managed transfer workflow; existing scripts, partner protocols, and integrations must be mapped during evaluation.
Technical evaluation
Review your transfer service as a complete operating model.
Bring the user flows, partner entry points, integrations, automation, deployment requirements, and operational responsibilities your platform must support.