Cloud storage should not require hyperscaler complexity
Published 2026-05-08 08:00:39.070669 by Carsten Blum
This blog post will deviate from my usual no nonsense bulletpoints how-to's, why's or what's. I'm sitting here drinking my morning coffee and reflecting on why ftpGrid is a success. The reason we build ftpGrid in the first place was actually a combination of simplicity, ease of use, pricing, availability and scalability. I got this sentence in my head "The problem with modern cloud infrastructure isn’t technology — it’s complexity".
I personally have a very long career in IT, spanning back to my very first Pascal program at 13, moving in to infrastructure, cloud, project management, management and finally strategy as senior manager at a very large fin-tech company. At the last company we relied heavily on FTP to transfer files between banks, stock exchanges etc. The last FTP cluster we purchased from a supplier cost in excess of €200,000 to establish, and around €5000/month to run.

To the point now - one day we got an old Axis camera at home which we wanted to use for surveillance in the courtyard. The camera was ud and running in 5min, but I needed storage. Being a certified AWS dev and architect, the route was easy... as in not easy:
Here is my path roughly:
Create an AWS account
Spin up an EC2 instance
Allocate EBS storage
Create security groups
Install Proftpd, configure Proftpd
Find a way to leverage Let's Encrypt certificates for FTPS
Setup fail2ban because FTP servers get hammered by bots
Boom - success. Axis camera surveillance on FTP Cloud storage
Wife wanted to see surveillance - oh damn!
Install FileZilla on Wife MacBook
Give up on efficiently sharing video storage with wife
Realize I now need HTTPS file sharing as well, and I'm essentially building infrastructure
...
You get the picture - I just wanted cloud based secure FTP storage where I could share files using either direct links, a file browser online or share whole directories. Obviously I also needed something like fail2ban automated and specialized for the FTP/SFTP use case. Hence - ftpGrid was born. And actually it was born as ftpvault in 2019, and restructured in 2025 as ftpGrid, but that's besides the point. Companies need FTP, but it is either hard to manage or expensive.
So the point of this rather wordy introduction to the why is, well, it got me thinking, why is ftpGrid really a success? Obviously it solves a problem, the problem in reality being complexity using FTP in 2026.
Independence
The first and primary reason ftpGrid is slowly and steadily beating most other B2B cloud storage providers is independence. We're currently hosted at Hetzner in Germany, with some services running with Scaleway in France. All the secondary services like CDN, DNS, SMTP etc. we buy from either independent European or Australian providers. This means if your company wants to use cloud infrastructure - because why not, but feel very strongly about controlling every moving part of you infrastructure, ftpGrid actually provides that independence from the large hyperscaler ecosystems. We're not owned in secret, or just 45%, but a Russian, American og Chinese company. We're completely independent, and therefore your company retains that independence when using ftpGrid.
Of course this "independence" spills over into other concepts such at "data sovereignty", "reduce vendor lock in" and "trust and transparency", which for some companies in especially Europe is very very important.
Simplicity
The next major point is simplicity. Honestly, there is nothing about ftpGrid you couldn't build in your own company. Just ask the infrastructure or DevOps department to walk through the 13... steps in the introduction and maintain and support that setup forever. Simple as that.
Most companies understandably don’t want to maintain that forever.. At some point, down the line, somebody in the company will say "When we export data from the ERP system to the FTP cloud storage, could you provide a webhook to tell service XYZ that the uploade is completed?". And now it is escalating and moving away from your core business. Are you a FTP service provider, a manufacturing company or ad agency?
Comparing to the 13... odd bullets in the introduction, to getting up and running with ftpGrid you simply do:
Go to signup age
Enter email and password
Spend 30 seconds on the onboarding guide
Boom - success.
But not just the fast onboarding, it is all the features you'll need at some point, like ftpGrid easy auto cleanup rules. You are for instance using ftpGrid as a transient storage to provides files to clients, all files should expire after 14 days.
Operational ownership
This is not just the trust that you still own you data, but the more human aspect of "taking ownership of your solutions". With massive cloud ecosystems like AWS or Google Cloud, there is often such a huge complexity, so many moving parts, that no one person can fully comprehend the complete setup. Someone somewhere in you company might remember somebody did something with AWS Cloud Watch starting a Lambda function, but now you can't figure out which region it was done in. Sigh.
Using ftpGrid as cloud storage provider makes it easy to comprehend and have a complete mental overview. It's one provider, one problem and one solution.
It just makes it very, very easy to work with, because now you cloud storage isn't a S3 bucket with this complex retention rule that Johnny created in ap-south-1 (that's Mumbai by the way), in 2016. Using independent service providers might make it harder to combine services in some ways, but much, much easier to understand your individual building blocks.
Infrastructure transparency
While you might not know exactly how ftpGrid is build internally, you do know exactly which server cluster your account is attached to.
If you log into the web ui, go to Settings -> Account -> Storage host/server you might see server13.ftpgrid.com. This mean you are using edge 13 cluster, the latest cluster. You have one ip adresse which can be looked up to get the exact geo location.
Additionally ftpGrid provides full storage transparency through web ui file browser, FTP access, REST API etc - nothing is hidden and nothing is unavailable to you.
From a more bureaucratic point of view, ftpGrid also provides full legal Data Processing Addendum, privacy policy and terms of usage which tells you company exactly who and what you are dealing with.
No vendor lock in
The most important reason why customers love ftpGrid, at least what I hear from the feedback we get, it that companies in Europe hate vendor lock in. Some major companies as "no vendor lock in" as a formal strategy.
Using ftpGrid, or really most independent IT service providers, you don't get vendor lock in.
Gotten tired of ftpGrid? Want to move to a new provider?
Alright:
Download all you data using FTP
Point your FTP client to the new provider
Upload all you data
That's the complete and utter definition of no vendor locking. Try and do that with a complete system build with hard integration to the Azure Blob Storage API. Everything has to be rewritten to support the new vendor API.
Final thoughts
ftpGrid is probably not the most feature rich, when compared to AWS og Google Cloud, we're not as easy to use at Dropbox, we're probably more expensive than some.
We're specialized in what we do, and we provide our customers with european hosted fully GDPR compliant storage with no third countries data transfer, full independence from large centralized cloud platforms, new levels of simplicity in using FTP cloud storage, you get operational ownership of you data and your infrastructure, and finally you get all this, with absolutely no vendor locking.
If you want to read more on the specific services we provide:
Checkout our features section.
Need more use cases for cloud FTP.
When you are ready, read our getting started guide
ftpGrid menu