TL;DR: I'm on to something, but it's not quite there yet.

I'm all for leaving big tech ecosystems, so Nextcloud presenting itself as a self-hosted alternative to Google Drive seemed like a great opportunity to remove Google from my personal cloud storage.

But I'm also a hypocrite who likes needlessly complicated infrastructure, so my next thought was to see if I can make Nextcloud as cheap as possible using AWS Serverless technologies.

My main concern was that I don't really access Google Drive all that often. Only a couple times per week, maybe more if I have a school project on the go. Ideally the setup would consist of me hitting my Nextcloud URL, spinning up a docker image, and have it turn itself off after about 15 minutes of inactivity.

The Plan Nextcloud already has an official Docker image, so we'll be using that. We'll set it up using AWS ECS fargate so we don't have to worry about managing any servers. The next issue to tackle is data persistance. This is cloud storage, after all. After some research, I found that Nextcloud supports object storage as primary storage! Great, we can configure Nextcloud to use S3 as its storage medium. There might be some network overhead in retrieving the files, but that really isn't an issue for me. I think. Next up is the database. Using a typical 24/7 running database didn't really feel like it fit the spirit of the project. I suppose we could use ECS to spin up a mysql container, but AWS recently launched something a little cooler. RDS Serverless fits the bill perfectly. It'll start up when our container makes a connection, and shut down when we no longer need it. RDS Serverless is much more expensive as a 24/7 instance, so our use case is really a perfect match in its on-demand nature.

Setting Up the Container Since the object store requires some configuration via a config file, we need to build a custom docker image and upload it to ECR. An inconvenience, but what can ya do? <?php $CONFIG = [ 'objectstore' => [ 'class' => '\\OC\\Files\\ObjectStore\\S3', 'arguments' => [ 'bucket' => 'your-bucket', 'autocreate' => true, 'key' => getenv("AWS_KEY"), 'secret' => getenv("AWS_SECRET"), 'hostname' => getenv("S3_HOST"), 'port' => getenv("S3_PORT"), ], ], ]; config/config.php FROM nextcloud:latest COPY config/* /usr/src/nextcloud/config Dockerfile I won't go through the steps of firing up an ECS task, as this isn't really a guide as much as a warning. Here's some documentation though, if you're truly interested in doing this. I should note here that if you enable encryption on your S3 bucket, it'll all go to hell. You can still use Nextcloud encryption, though. See more: Decryption (symmetric) of content fails using s3 · Issue #10767 · nextcloud/server Steps to reproduce Update to 14 beta 4 using update enable external storage enabled default encryption without home encryption add s3 external storage (for everyone) with previews, ssl and encrypti... nextcloud GitHub

The First Hiccup The Nextcloud docker container allows you to set the MySQL connection info (host, user, password, database) through environment variables. This is very convenient for the initial install. However, when you add the config.php file above to use S3, something weird happens and the MySQL environment variables are disregarded. You're met with this screen: Not the biggest deal to manually enter the database information, but this quickly becomes very annoying when you're trying to debug the S3 connection. Which I had to do a lot. Much time was spent debugging the S3 connection, mainly because of how long it took to determine the issues, restart the ECS task, re-enter the MySQL information, etc.

Roadblock: High S3 Utilization After a few hours of getting the S3 as primary storage to work, I came across this issue: S3 utilization extremely high, even for few files, resulting in significant charges · Issue #3673 · nextcloud/server Steps to reproduce Set up S3 back-end Put a few files in S3 Get your bill Move back to EBS very quickly Expected behaviour I'm not sure if there's an existing cache of file attributes (e.g.... nextcloud GitHub Basically, the gist is that Nextcloud frequently makes S3 requests, resulting in very high charges on your AWS bill. No good, and from what I could find there is no real solution to this issue. There is a fix if you're using S3 as an external storage point, but not if you are using it as the primary storage point. However, it can't be too bad, since we're being serverless here. Those frequent requests will only be while we're accessing nextcloud. We're seeing a pattern here: not ideal, but fine I guess.

Roadblock: Starting & Stopping Nextcloud Before I went down this rabbit hole, I didn't really consider how I was going to spin up the Nextcloud container, and stop it after a time. I decided to just figure out all of the other stuff first and hope that part would come to me. ECS tasks don't have a static IP, so how will we hook up a domain to our Nextcloud instance? Option 1: A load balancer? We could use a load balancer that directs traffic to the fargate instance, but the 24/7 load balancer is both expensive and against the serverless spirit of this project. Option 2: A lambda? We could write a lambda to both spin up an ECS task if one doesn't exist, and handle passing the traffic back and forth from the user to the ECS task. I don't really like the idea of having to hit the lambda on every request to Nextcloud. What's that we've been saying? Not ideal, but fine I guess. How are we going to stop the ECS task after 15 minutes of inactivity? Great question. Maybe some kind of deadman switch that the lambda can reset on every request. Maybe going through the lambda every time isn't so bad. Maybe we can have the lambda write something to CloudWatch, and take advantage of CloudWatch Events. Have it reduce the number of ECS Tasks to 0 after 15 minutes after the last signal from our lambda. This could work, it might not.

At this point it got too convoluted even for me. I'm all for over engineering things just for the fun, but a man has his limits.

I still think I'd like to revisit this some day. But this was more about the fun than the actual utility of serverless Nextcloud.

If you have any ideas about how this set up could be improved, or how you would handle the starting/stopping I'd really love to hear them. Feel free to let me know.