How Blober Works, and Why It Runs on Your Machine

Blober is a desktop app that moves files between cloud storage providers and your own drives. It runs on your computer and talks directly to each provider with your own credentials, and no Blober server sits in the path. You sign in to your clouds inside Blober, pick what to move and where it should go, and press start. Nothing about the transfer depends on a Blober account.

When you move files between two providers, or between two accounts, Blober reads them from the source and writes them to the destination, streaming them through your computer:

Source cloud  ->  your computer (Blober)  ->  Destination cloud

The bytes pass through your machine and nowhere else. They also travel over your own internet connection, so a transfer like this counts against your bandwidth and any data cap your ISP sets.

Many browser-based and hosted transfer tools take a longer path:

Source cloud  ->  a company's servers  ->  Destination cloud

In that model your files, and often your stored credentials, sit on infrastructure you do not control and cannot audit. Blober leaves that hop out.

A copy or move within one account (the same bucket or storage account, and the same region for S3) first tries the provider's own server-side copy, which moves no data through your computer, and falls back to streaming if that fails. A Mutate action such as an Azure tier change also runs on the provider's side.

Every job has three parts:

1. Source: where the files come from, given as a provider, a path and your credentials.
2. Destination: where they go, either another provider or a local drive, with an optional path template to organize them.
3. Action: Copy, Move, Delete, or Mutate, which changes a property of existing files in place, such as the access tier of Azure blobs.

A saved combination of these is a workflow, and each run of a workflow is a task you can watch, pause, and resume. See Concepts for the full model.

Blober stores your provider keys and tokens on your computer. It uses them to talk to your providers and never uploads them to a Blober service. The concepts guide lists the credential types Blober stores locally.

A storage key or access token opens your whole account, with permission to read, write, list, and delete. When a hosted tool keeps that key on its servers, a breach of that company becomes a breach of your storage. Blober has no shared vault of keys to breach.

Between providers, Blober does mechanically what you could do by hand: download a file from one place and upload it to another, the same operation your browser performs. Blober runs it in parallel and keeps track of what has finished, so an interrupted job continues where it stopped.

For anyone who has to answer for their data, that simplicity helps. Blober adds no transfer provider to your data path, so it fits inside the controls you already have. In a security review (SOC 2, ISO 27001, or a GDPR data-processing assessment) the question gets narrower: apart from the source provider, the destination provider, and the machine running Blober, there is no relay service in the middle.

Because the work happens on your computer, Blober does not need a service of its own to stay online. There is no meter, no seat count, and no subscription renewal that could strand your files behind a paywall. Blober is a lifetime licence with lifetime updates, so the copy on your machine keeps working and keeps improving.

It also copes when the network does not. Blober retries a flaky connection or an interrupted job, and a resumed task continues from its completed files without starting over. Your saved workflows stay on your machine for the next run.

Some services, especially consumer ones like GoPro Cloud and Google Photos, were never designed to let you move a whole library out at once. They expect you to use their own app, one screen at a time.

Blober connects to those services the way their own apps do: through your own login, on your own machine, acting on your behalf. Because it runs locally, it can handle each provider's quirks, including services with no formal export tool, without handing your session to anyone else. A GoPro library of several thousand clips can be queued in one workflow and moved into storage you control. Google Photos works as a download-only source; the Google Photos provider guide lists its current limits.

A tool on a central server has a much harder time here. It has to reach each consumer service on behalf of every user at once, and the provider sees that traffic arrive in bulk from one company's servers, a pattern that can attract rate limits, geofencing, or blocks. Blober connects from your own IP address, so there is no shared relay address that a provider could block for every Blober user at once. Provider account limits still apply, tied to your own login and your own connection.

• People leaving one cloud for another who want a clean, direct migration
• Photographers, videographers, and creators moving large media libraries between providers
• GoPro and Google Photos users who want their footage and photos somewhere they control
• Teams and individuals who would prefer not to add another company to the list of services that can see their data
• Anyone who would prefer a tool on their own machine to a service they rent by the month

Command-line tools like rclone can also move data directly between clouds, and they are excellent in the right hands. What they cost is your time: configuration files, credential management, and provider-specific flags, all from a terminal.

Blober takes the same direct, local approach without the manual work. You connect a provider by signing in, browse your files visually, pick a destination, and run, with no config file to maintain and nothing to debug at a command prompt. If you enjoy the terminal, a script is a fine choice. If you would prefer to see your storage and click, Blober is built for that.

• If you are new, start with Getting Started.
• For the full list of supported services, see Providers.
• Download the app from blober.io.