I've recently analysed pricing of various storage providers when thinking of building a side project, and I was surprised at how costly the services were.
S3, Drive, Dropbox, Spaces, B2, Box, several Object Storage solutions. Some cases storage was cheap, but the transfer was costly. Everything seemed costly for the simple use case of providing an end user 10GB monthly upload + ~50GB bandwidth at low cost.
A vps with additional storage seemed to be the ~better~ most feasible solution to me.
This sounds like a terrific thing to host on a vps.
I previously considered the idea of creating a cloud storage solution where customers are only billed for what they use. This was spurred by looking at dropbox's $10/mo plan for 1TB of storage. But I decided against it.
Storage is already free for the average user. 15GB with Google is enough. If you want more, the option is there and not that expensive. $2/mo for 100GB. I see no reason why a consumer would switch to my lesser-known service to save $1/mo. $1 is nothing. So my market would be users that store a lot of data. In that case, $10/mo for 1TB doesn't seem all that bad. Anymore than 1TB, customers probably have a bit of technical knowledge and may aswell store it themselves.
This market is already extremely saturated. Every single big tech name has a part of it.
Nightly backups still mean you can lose up to ~24 hours of data.
This is in stark contrast to, for example, AWS S3. From the FAQ [0]:
> Amazon S3 [is] designed to provide 99.999999999% durability of objects over a given year. This durability level corresponds to an average annual expected loss of 0.000000001% of objects. For example, if you store 10,000,000 objects with Amazon S3, you can on average expect to incur a loss of a single object once every 10,000 years.
> Amazon S3 ... storage classes redundantly store your objects on multiple devices across a minimum of three Availability Zones (AZs) in an Amazon S3 Region before returning SUCCESS.
In AWS parlance, an AZ is a physical data center, and they're built far enough apart so a fire, flood or tornado will not affect all of them.
There's a reason S3 (and similar) cost so much more than "hard drive attached to a server" storage. If you don't need the durability than of course it is overpriced -- but on the other hand, if you try to provide that level of durability yourself you'll quickly see it's a bargain.
Well, you are comparing apples and oranges here. The equivalent AWS service would be EC2 and not S3. I know that you didn't start with that (as gprasanth put them in the same race), but it should be clear those two have different redundancy levels.
In fact, I don't know where AWS nor Hetzner stores the 'disk' of the VPS or even the backups. And while those are undoubtedly essential attributes for enterprise-level services, I think especially for side projects the usability of the service is quite relevant.
Thanks, hadn't heard of Wasabi before. The storage pricing is comparable with B2, but no egress charges is nice. Any have experience with this provider?
So after reading their pricing FAQ, it looks like you are billed for a minimum of 1TB, and every file is billed for 90 days minimum.
Based on their calculations, if you plan on storing files for more 16 days, it will be marginally cheaper than S3, but if you plan on keeping files around longer than 90 days, it is ~5x cheaper than S3.
I only recently learned of wasabi (I think it was Leo Laporte's Twit podcast)...and beyond the nicer price points, seems to be compatible with AWS...so, if i read things right, one could somewhat/more easily switch between aws and wasabi - avoiding the dreaded vendor lock. If that's true, that's pretty neat.
Disclaimer: i have no direct experience with wasabi, nor am i affiliated with them at all.
I am working on an android app as a side project and I have some 3 gb size of audio files to share with clients. I am exploring different storage services, any pointers to share regarding that?
It says "Big Files" but I don't see an explicit size. Whereas send.firefox.com is 1GiB. Self hosted I imagine you're only limited by filesystem max file size.
One thing I like about send.firefox.com is it's a one time download, and then the URL is denied to have ever existed. CryptSend sounds like you could share the URL with multiple destinations; multiple downloads.
Tempted to make a version of this myself because it's simple. Single file executable, with statically linked Tor, that starts a v3 onion service (with or without client auth), hosts web server with file at URL, gives onion address URL (and client auth if any, could include the as part of URL or URL fragment or whatever depending upon approach desired). Client can use exe or Tor Browser to download it. Could add any features you want such as killing the server after first download, deadlines, etc.
Pro: doesn't upload to server and preserves anonymity. Con: slower than non-anonymous.
Seems like a bit of an oversight that they are including third party tracking scripts like googletagmanager.com in the same context as the javascript doing encryption. If you need user tracking, at least put the tracking scripts in an iframe sandbox or something that can't accidentally grab the keys from the URL fragment and send them off to google.
Also they do call out that URL fragments get stored in browser history which is a big risk, but they should also mention that many browsers automatically "sync" history across devices (so keys will get sent to a cloud if you aren't using incognito/private browsing).
Cryptsend was created as a result of my company having to share large amounts of medical data with our clients. We couldn't find an easy and secure solution, so we sat down and created cryptsend. Our codebase is currently in alpha stages so any audits/improvements/security vulns you find would be really appreciated!
Yeah, the best solution I've found was Sharelock[0], but I couldn't for the life of me self-host the app without weird errors cropping up. It's also not free if you want more than one social sign-in via Auth0.
The first thing I thought of when I saw the url is that it's some kind of cryptocurrency transfer service. It's pretty crazy how much cryptocurrency has hijacked the word "crypto".
There are JavaScript files in the GitHub repository, so I'm going to assume they mean third-party dependencies, but some more clarification would be nice.
Confirmed. The intent is anyone can audit our whole codebase in one GitHub repo for vulnerabilities and not scripts spread across many CDNS and projects which may change over time.
Hmm, it's working for me on Chrome. What browser are you using? Do you see any javascript errors in your dev tools console (provided you know what that is)?
S3, Drive, Dropbox, Spaces, B2, Box, several Object Storage solutions. Some cases storage was cheap, but the transfer was costly. Everything seemed costly for the simple use case of providing an end user 10GB monthly upload + ~50GB bandwidth at low cost.
A vps with additional storage seemed to be the ~better~ most feasible solution to me.
This sounds like a terrific thing to host on a vps.