Ramblings of an aging IT geek
← Ramblings of an aging IT geek
homelab

nextcloud, again, properly this time

A second attempt at self-hosting Nextcloud, this time with a real database, Redis, and a reverse proxy instead of the all-in-one image that fell over.

A small server rack with blinking status lights

My first go at Nextcloud was the all-in-one container, and it was fine right up until it wasn't. It got slow, the admin panel filled with warnings I didn't understand, and a routine upgrade left it in a half-broken state that I eventually fixed by deleting everything. So I'm doing it again, properly, with the bits separated out so each one can be reasoned about on its own.

The new layout is unglamorous and that's the point:

  • Nextcloud (the official fpm image) for the application itself.
  • MariaDB for the database, not the bundled SQLite. SQLite is the source of half the "Nextcloud is slow" stories.
  • Redis for file locking and caching, which is the piece that quietly makes everything feel responsive.
  • A separate Nginx reverse proxy out front handling TLS.

A homelab shelf with cables and a small server

The thing I got wrong last time was treating the database as an implementation detail. With everything in one image you never think about it, and then you can't back it up sensibly because you don't know where it lives. Now the data directory and the database are explicit named volumes, and my backup job is just two boring commands: a mysqldump and an rsync of the data directory to the NAS. If the application container catches fire I can rebuild it from the compose file in minutes and point it back at the volumes that actually matter.

Two warnings worth passing on. First, the admin overview page is your friend; clear every warning it raises, because they're almost always telling you something real about caching headers or missing PHP modules that will bite later. Second, set the right cron mode. The AJAX default means background jobs only run when someone has the web UI open, which on a personal instance is approximately never, so things like file scans silently stop happening. Switch it to the system cron via a small container that calls cron.php every five minutes and the whole thing behaves.

It's been up for a few days now and it feels different to last time. Not because the software changed, but because I can see the seams. When something goes wrong I'll know which box to poke, and I'll have a backup that I actually trust. That trust is the entire reason to self-host this rather than pay for the hosted version, so it was worth doing slowly.