Who this is for
- You don’t want anyone else’s infrastructure in the path your files take.
- You handle sensitive material — legal archives, financial records, regulated content — that shouldn’t pass through someone else’s servers.
- You already keep an always-on server, NAS, or VPS running for jobs like this.
- You move enough volume that bringing your own bandwidth costs less than renting throughput.
How it’ll work
- Install the runner on hardware you control — a NAS, a VPS, an always-on Linux box, or a Raspberry Pi that stays on.
- Pair it with your Syncologic account using a one-time enrolment code.
- Connect your source and destination providers from the dashboard.
- When you start a job, pick the runner you just paired instead of the hosted option.
- The runner pulls the work, transfers the files between provider APIs, and reports back when it’s done.
The hero diagram up top shows the path. Files flow direct from the source API to your runner, then to the destination. We see what the job is and when it ran — never the file contents.
No firewall changes on your side
Works behind home NAT, behind a corporate proxy, behind anything that allows outbound HTTPS. You don’t open a port. The runner makes an outbound connection to us and waits for work; when a job is dispatched, it pulls a short-lived run lease, runs the transfer, and posts progress back.
No inbound firewall rules. No public IP. No reverse proxy. No tunnel.
Where you’d run it
The runner is small enough to live next to other lightweight services on hardware you already own — a Synology, QNAP, or TrueNAS box that’s already on 24/7, a homelab Linux server or mini-PC, a small VPS (Hetzner, Fly, DigitalOcean, OVH), an always-on workstation acting as a small home server, or a Raspberry Pi class device for slower, low-throughput backups.
It cares about reliable network and enough disk for staging buffers; it doesn’t care which distro or hardware you picked.
Your credentials stay with you
Provider OAuth tokens will be bound to the runner — encrypted at rest with a key derived from your enrolment, never leaving the runner. We see provider identifiers, scopes, and run metadata; never refresh tokens, never file contents.
Decommission the runner and revoke its enrolment from the dashboard — the tokens it held become useless.
Hosted versus your own server
Both modes use the same dashboard, the same job definitions, the same preview, and the same completion reports. The only difference is where the bytes flow — and what that means for cost and trust.
On our servers (Cloud Runner)
- Where bytes flow: source → our infrastructure → destination.
- Where credentials live: encrypted in our infrastructure, short-lived.
- Setup effort: none — pick it from the dropdown.
- Best for: convenience, very large jobs you don’t want to host yourself.
- Pricing model: usage-based on our infrastructure.
- Network requirements: none.
On your own server (Private Runner)
- Where bytes flow: source → your server → destination.
- Where credentials live: on your runner, never leaves.
- Setup effort: install and pair once.
- Best for: privacy, sensitive data, homelabs, high-volume users.
- Pricing model: pay for software; you bring bandwidth.
- Network requirements: outbound HTTPS from the runner.
Source-visible code
You can audit how the runner moves files before installing it — the code is published for anyone to read. We plan to keep that property as we grow.
Where would you run your Private Runner — NAS, homelab server, VPS, or workstation? Tell us on the waitlist below — it’s the first question we’ll ask after your email.