I built a desktop app to move files between cloud providers without subscriptions or CLI
I started working on this about a year ago because I needed to backup my GoPro footage to Backblaze B2. GoPro Cloud has no API, no bulk download, and no third-party tool support. The web app lets you grab 25 files at a time in zip bundles.
That turned into Blober, a desktop app that connects to 11 cloud storage providers and lets you transfer files between any two of them. AWS S3, Azure Blob, Google Drive, Dropbox, Backblaze B2, Cloudflare R2, DigitalOcean Spaces, Wasabi, Google Photos, GoPro Cloud, and local storage.
Why local-first
Every other cloud transfer tool I found was either a SaaS that routes your data through their servers or a CLI such as rclone that requires config files. I used custom scripts because I wanted my files to have a specific format:
backup/
├── 2025-12-24/
│ ├── 2025-12-24_08-24-02:DSC08007.jpg
│ └── 2025-12-24_09-15-45:IMG_1234.mp4
└── 2025-12-25/
├── 2025-12-25_10-05-30:HolidayPic.png
└── 2025-12-25_11-20-10:FamilyVideo.avi
Blober runs entirely on your machine. Files stream directly between provider APIs. Your credentials never leave your computer. No subscription, no transfer fees and definitely no transfer limits.
This matters for two reasons:
- Privacy. SaaS tools decrypt your data on their servers to relay it. Your credentials sit in their database.
- Cost. SaaS tools charge per-GB or monthly subscriptions. Blober is a one-time purchase. Transfer 100 GB or 100 TB, same price.
The hard parts
Google Photos changed their API policy in March 2025. Third-party apps can now only download photos they uploaded themselves. rclone broke overnight. Google's official answer is Takeout, which takes hours and gives you fragmented zips with no folder structure. I had to find a different approach to make it work in Blober.
GoPro Cloud has never had a public API. Building support for it was the most challenging integration because there's no documentation, no SDK, and no community resources.
Azure Blob mutations were an interesting addition. Beyond just moving files, Blober can change Azure storage tiers (Hot, Cool, Cold, Archive) and container access levels in bulk.
One-time purchase model means every sale is permanent revenue. No churn. But it also means no recurring revenue, so growth has to come from volume.
Currently supports Mac, Windows, and Linux.
As a developer with a very tiny online presence, marketing is the hard part. If you've built a utility tool and struggled with the marketing side, I'd love to hear what worked for you.
One question I'd love to ask: with the one-time purchase model (no recurring revenue), how are you thinking about sustainability and ongoing maintenance? Do you plan to release paid major versions over time, or is there another angle you're exploring?
The one-time price covers what's there today, and as the platform grows with more providers and features, the price goes up - so early users get a good deal.
Beyond that, am not overthinking it yet. Blober doesn't have heavy server costs since everything runs locally, so the pressure to find recurring revenue isn't as urgent as it would be for a SaaS. Focus right now is just making the tool genuinely useful enough that people genuinely prefer it and recommend it to others.
that's great!
thank you @cena5529
This is exactly the kind of tool that wins by solving one painful problem really well. The 'no subscriptions' angle is smart — that's the #1 complaint we hear about cloud tools. Have you thought about targeting developers who need to migrate large datasets between providers? That's a use case where people would pay a one-time fee without hesitation.
That's actually one of the stronger use cases already. The 100M+ files migration article gets decent traffic from people looking at exactly that scenario. With good internet speeds, Blober can move large dataset easily, and paying per-GB to a SaaS doesn't make sense.
Good to know the no-subscription angle resonates. Appreciate the feedback.
I do feel privacy first would be the way forward. I am a big believer of local desktop apps which only interact with cloud when needed. Wanted to understand how are you managing the costs or being able to have same cost for 100GB vs 100 Tb
Blober runs entirely on your machine. No data passes through our servers. Your files go straight from your computer to whatever cloud provider you're using.
On costs: since we don't proxy or store anything, our infrastructure costs are basically flat regardless of how much data you move. That's why the one-time pricing works, we're not scaling server costs with your usage.
yeah agree
Local-first + no subscription is the right call for a tool whose primary use case is bursty — "move my GoPro backup," "migrate Dropbox," then maybe nothing for 3 months. Subscriptions force users to either keep paying for a tool they aren't actively using, or churn and hit friction next time they need it. As a solo dev shipping a small iOS memo app (a Captio replacement), I've been making the same bet: utility apps with a bounded job feel better priced as a one-time unlock than a $4/mo subscription that triggers a "why am I still paying for this?" moment at month two.
Curious about the actual pricing decision — did you land on a single one-time license, tiered by provider count, or per-transfer credits? And how are you handling the discoverability problem desktop apps face without the SaaS-style trial funnel?
one-time payment is what I personally prefer from other products, so I'm more inclined to offer the same, especially for utility apps you don't use daily and that don't cost server loads. Otherwise you end up forcing a SaaS model and architecture onto something that doesn't need it. Single license, no tiers or credits. Didn't want people doing mental math about which plan covers their providers.
Right now Blober has a discounted price. As we keep adding features and providers, cost goes up as the platform grows, but early users lock in the lower price.
Discoverability is honestly the hard part. Mostly SEO. We publish articles around the specific pain points people search for (such as how to move GoPro Cloud media to Dropbox, backing up GoPro footage, backup Google Photos without google takeout, etc).
Good luck with the Captio replacement
Local-first + no subscription is the right call for a tool whose primary use case is bursty — "move my GoPro backup," "migrate Dropbox," then maybe nothing for 3 months. Subscriptions force users to either keep paying for a tool they aren't actively using, or churn and hit friction next time they need it. As a solo dev shipping a small iOS memo app (a Captio replacement), I've been making the same bet: utility apps with a bounded job feel better priced as a one-time unlock than a $4/mo subscription that triggers a "why am I still paying for this?" moment at month two.
Curious about the actual pricing decision — did you land on a single one-time license, tiered by provider count, or per-transfer credits? And how are you handling the discoverability problem desktop apps face without the SaaS-style trial funnel?
commented above: https://www.indiehackers.com/post/i-built-a-desktop-app-to-move-files-between-cloud-providers-without-subscriptions-or-cli-9f55ba396a?commentId=-Os_SDSWrcFEJDz3y9AO
thank you for your feedback.
The egress fee point is one that most teams underestimate. AWS, Azure, and GCP all quietly print money on free cross-region replication, and the bill compounds with every backup nobody looks at.
The Azure tier-change feature is honestly the part I'd use most. In my experience watching cloud bills, idle storage stuck in the Hot tier is one of the most common waste patterns. Most teams set it up once and never go back to clean it.
Curious, do users actually use the tier-change flow as much as the file transfer, or is it more of a "they discover it later" feature?
Azure tier changes came from my own need first. I had containers on Cold that should have been on Archive. I had custom Python scripts that I had to fine-tune for each task.
A few users who bought Blober for transfers then asked for exactly this, so it became a proper feature. It's a mix of people discovering it after buying and people who specifically wanted bulk tier management without scripting.
I'm planning to add more mutations, like AWS move to Glacier storage to save cost.
People set up a container, pick a tier, and never revisit it. Being able to select blobs visually and move them in one click makes it simpler to manage.
Really impressive build. Supporting GoPro Cloud and Google Photos is no small feat.
I’d focus on SEO for keywords like “transfer Google Photos to Backblaze B2” since that’s exactly what users search for.
Great product solving a real problem.
Thank you. SEO with those long-tail queries is my current focus actually. I've been publishing targeted articles at https://blober.io/kb/articles/ and they're starting to bring in organic traffic. Appreciate the suggestion.
The positioning I’d lean into is not “file transfer between cloud providers,” but non-custodial cloud portability.
The provider list is useful, but the sharper pain is: “I want to move or back up my cloud data without routing everything through another SaaS, storing credentials elsewhere, or paying per-GB transfer fees.”
For marketing, I’d test concrete migration stories: GoPro Cloud → Backblaze B2, Google Photos export alternative, S3 → R2/Wasabi without transfer fees, etc. Those feel much more searchable and urgent than the generic 11-provider message.
Curious how you handle resumability and verification for long-running transfers. For this kind of tool, “it won’t silently fail halfway through” might become one of the strongest trust signals.
"non-custodial cloud portability" is a good one, I might steal that...
You're right about the migration pain too. Articles like GoPro Cloud to Backblaze or Google Photos without Takeout perform way better than articles for other providers.
On resumability: transfers stream data in parallel, and if a stream fails, Blober retries it automatically a few times. It checks internet connectivity between retries so it's not just hammering a dead connection. If a file genuinely can't complete after retries, the task still finishes and users can see exactly which files failed. They can restart just the failed files without re-running the whole task. So it won't silently fail. You always know what made it and what didn't.
Local-first + one-time purchase is genuinely the right call for a file transfer tool — nobody wants a subscription for something that should just work. The Google Photos API change killing third-party access overnight is a perfect example of why routing through your own machine matters.
The marketing side you mentioned — I've been in the same boat as a solo builder. What's worked slightly better for me is posting the problem story (like this post) rather than the feature list. You're already doing it here. Keep that format.
Really appreciate the feedback. It's really good to see a personal problem can scale to other people with similar problem...
I'll keep posting and finding the right forums. Other than Indie Hackers, do you know any communities that are welcoming to solo builders sharing what they're working on? Reddit has been tough for me.
This is stronger than just a “file transfer app.” The local-first angle is the real wedge: no server relay, no credential storage, no transfer limits, and no subscription tax. That is a much sharper position than competing with generic cloud-sync tools.
I’d probably make the privacy/control story more central than the provider list. The list proves utility, but the trust claim is what makes Blober different: your files move between clouds without the product becoming the middleman.
One thing I’d think about early is whether the name Blober will age well if this becomes a broader local-first cloud operations tool. For a more serious cloud workflow/platform direction, Xevoa.com would carry the product cleaner than a name that sounds tied to “blob” storage only.
Thank you for the perspective on leading with the privacy/control angle over the provider list. That's something I've been shifting toward and it's good to hear it validated...
On the name, all good names are taken, including
Xevoa.com. But honestly I like the blob connotation. Blobs are essentially what files are in the cloud, so the name fits what the tool does.The name Blober has stuck with users. Renaming at this stage would cost more in brand recognition than it would gain. But thanks for the suggestion.
That’s fair.
If users already connect Blober with cloud files and the blob meaning is intentional, then keeping the name makes sense. No reason to force a rename if recognition is already forming.
I’d still lean hard into the privacy/control wedge in the messaging though. “Move files between clouds without your data passing through someone else’s servers” is much stronger than just “supports 11 providers.”
That trust angle is probably what separates Blober from generic sync tools and CLI alternatives.