Run everything on your own server.
Files will never pass through our infrastructure. You'll install a small program, connect your clouds to it, and run transfers inside your own network. Not at launch day, but high on the post-launch roadmap.
By joining, you agree to our Privacy notice.
For homelab operators, privacy-conscious users, and businesses that want their file transfers running on infrastructure they control.
Self-hosting won't ship on launch day — and that's intentional
Early access is about proving the core engine. Self-hosting is a different kind of product layered on top, and we'd rather wait than ship it half-right.
-
The engine has to be right first
Cloud-to-cloud transfers need to be reliable, fast, and predictable before we bolt self-hosted runtime on top.
-
Self-hosting is a product, not a flag
It's a two-plane product (control and data) running on hardware we don't control, with updates you trust us to ship. Security is our top priority, and on self-hosted infra it has to live inside the product itself.
-
It's a top post-launch priority
Once the core is stable, self-hosting moves to the front of the roadmap.
How it works under the hood
Architecture, the self-host levels, and why code stays public — for the technical user.
Control plane vs data plane
Two layers. The control plane (auth, jobs, schedules, reports) stores metadata about your transfers.
The data plane (the runner) is where bytes flow from source → destination.
- auth
- jobs
- schedules
- logs
Why code stays public
Security comes from what you can verify, not what we promise. Every runner — Cloud Runner, Browser Runner, Local Helper, Private Runner — ships with source visible on GitHub, alongside the transfer logic and provider adapters. Read it, audit how credentials are handled, see how bytes move between providers, and decide whether to trust the system before a single file gets touched.
