(An Tran/Unsplash)
Maybe it was the Dropbox drama around Apple Silicon from a couple of months ago that forced me to look for alternatives. Maybe it was the fact that Google Drive has a bizarre tendency to delete files in the midst of a sync process, leading to lost work.
But the net effect of it is that I’m finally doing something that I technically should have done a long time ago: I’m trying my hand at putting together my own cloud-based infrastructure, in hopes that I can come up with something cheaper, more secure, and more efficient for my needs.
At the center of this is NextCloud, a popular sync tool with the Linux community that can often be hosted on devices as small as a Raspberry Pi, though it also works with more traditional hardware as well.
An example of NextCloud’s dashboard interface; in recent versions, the app has gained more office-suite capabilities.
I looked at my options, including the potential of hosting it locally on my Xeon, and ultimately decided on this mix:
- A small-scale Vultr instance, with 1 GB of RAM and 35GB of internal storage. Even though I have a lot of data, I went as small as possible with this setup because I wanted to lean on object storage, rather than internal data. The reason for this is, ultimately, price: Hosting on the same server you run your operations from can get very expensive for the amount of data a sync approach would require.
- An Amazon S3-compatible build using Wasabi. If you’re not familiar with Wasabi, the up-and-coming platform is essentially one of the cheapest hosts on the entire internet, with costs hovering around $0.0059 (or three-fifths of a cent) per gigabyte hosted, per month. By comparison, S3 itself charges $0.023 per gigabyte, or more than twice as much.
This combination seems like it has the potential to be really slow, but honestly, I’ve found the speed more than robust enough to manage whatever I can throw at it. (I did try to send it to a fairly inexpensive host based in Germany that has a dedicated service for this offering, Hetzner, but it was too slow shoving a bunch of data across an ocean. Hetzner is starting to build out its server array in North America; maybe they’ll do Nextcloud hosting here.)
You can add apps to NextCloud—in this case, a Markdown editor that actually works pretty well. (And yes, you can white-label your instance, too.)
Now, there are imperfections with this approach, as far as I can tell from the perspective of an end user. First off, I will be on the hook to manage updates to the server, just as I am with a web host. It has problems with large files, such as my Quixotic attempts to upscale Santa Claus Conquers the Martians to 4K60. (But it works great with more standard-sized files, as well as with text documents and graphics.) And iOS seems to be extremely wonky in terms of handling the sync process, something MacOS and Android don’t seem to have a problem with. And of course, the big one: If something breaks, I won’t really have anyone to complain to.
But I can see some clear benefits across browsers and platforms. NextCloud’s interface comes with the ability to install apps, many of which are fairly robust and make decent replacements for desktop tools. For example, there is a Markdown editor that is directly baked into NextCloud, helping to allow for editing no matter where I am, as long as I have my login info handy. It means that I can have a little custom suite handy whenever I need it.
And by paying for object storage, I theoretically can avoid paying some of the additional fees that might come with buying more cloud resources than I actually need. After all, why pay for two terabytes of storage when my use case only really needs half a terabyte?
Finally, I have found that NextCloud rarely takes up more than, say, 5 percent of CPU resources at any given time on Apple Silicon, meaning that it is the rare mix of lightweight and performant that everyone looks for when trying to use cloud-based tools.
Sure, there are ways I could improve this. I was thinking that it might make sense to run this on a local cloud share, but power outages happen often enough in my neck of the woods that it sort of felt like a risk of relying on a cloud server located in my own home.
Of course, all of this threatens to get comically close to the infamous comment left on the Hacker News thread that introduced Dropbox way back in 2007. And I quote:
For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.
Yes, you can do this all yourself, but Dropbox, like its cloud successors, is designed to make it easy. But I feel like Dropbox genuinely broke the contract by choosing not to update to Apple Silicon in short order, so you know what? If I want this to work for my needs, maybe I need to take some of that work into my own hands.
Wish me luck. I’ll keep you posted on how it goes.
Time limit given ⏲: 30 minutes
Time left on clock ⏲: 1 minute, 18 seconds
