Recommendation on NixOS Nextcloud packages, vs all-in-one container from Nextcloud

I am looking to run Nextcloud on NixOS. There are several ways to do this and I’m looking for some recommendations on which way to go…

  1. I could use the NixOS packages and follow the guide on the NixOS wiki. I could optionally put this into a NixOS container. This feels like the more “native NixOS” approach.
  2. Alternatively, I could use the all-in-one container direct from Nextcloud (link), and not any of the NixOS packages. This is feels like it might give me a better Nextcloud experience, to be running the version distributed directly from the vendor.

I’m wondering if anyone has experience with both, and could share a recommendation here?

I’m running the Nextcloud all-in-one container somewhere. I made a small patch, and now I’m sad I didn’t go the NixOS route so I could apply that patch to my deployment and get the change immediately, instead of waiting for the next release (or mucking about with their container building processes).

Since I don’t have Nextcloud deployed as a NixOS package, I don’t know how it would actually have worked out that way, though :).

1 Like

Thanks - that’s an interesting point. Much harder to patch or tweak containers than NixOS packages.

Can I ask, the all-in-one Nextcloud container, are you running that on NixOS? I’m asking, because I see now that their setup instructions ask you to pass through the docker socket, which sounds potentially troublesome.

Not currently, unfortunately

I’ve found maintaining containers more troublesome than maintaining modules. Obviously, given the modules will keep step with actual NixOS updates, are maintained by someone who maintains NixOS modules, and integrate more cleanly in general.

In fact, I specifically switched from the nextcloud (not the AIO, the php-fpm one) container to the NixOS module because I got annoyed at 1) having to constantly manually update docker containers, so it didn’t fit in with the rest of my maintenance flow and 2) how poorly integrated the container itself was; the container folks, despite being “closer” to upstream, don’t seem to communicate much with them.

I’ve also found the NixOS configuration defaults to be more thoughtful, it disables the webfinger plugin by default, for example.

That said, some of the extra services this AIO container seems to set up may be a little more work for you upfront.

I think personally I would recommend the NixOS module if you’re maintaining a personal instance, and have even the slightest suspicion you might get lazy with maintenance. Using the container might be more appropriate if you have a dedicated maintenance budget and do this professionally, but I don’t really think there’s any reason to use the container over the module if you have time to set up the services by hand.

In either case, consider if you really need all of the services the AIO configures, whether the security implications of using stuff bundled into a container (and therefore not updated/recompiled with the rest of your system, so next time there’s an openssl vulnerability you’re screwed for a while) is worth it, and whether setting up the services downstream is worth the additional continuous maintenance effort and lack of integration you’re burdening yourself with.

2 Likes

Do you still use the Nextcloud module now ? How was transferring the data base when switching from container to the module ?
Do you happen to use nextcloud talk and run a turn server for it ?
I’m considering switching from podman container setup on my server to NixOS packages .

I do to this day, but I’m slowly considering switching to seafile (mildly annoyed at nextcloud’s sync performance and I’d enjoy proper E2EE). I might if they add postgresql support or the fork gains traction.

This migration is a few years ago now, so I don’t remember that well, but my lack of recollection probably means this went as you’d expect. It shouldn’t be problematic to dump a database if you’re just migrating to another instance of the same nextcloud/database major version.

If things go wrong, you can always roll back, just make sure not to actually delete the container until you’ve confirmed the deployment is working as expected. Test in a staging env.

No, but I do run a conduit (matrix) instance. I’m using coturn to manage p2p connections for voice/video chat through it. Probably not set up the same way, but here’s my config if you’re interested: tlaternet-server/conduit.nix at master - tlaternet-server - Forgejo: Beyond coding. We Forge.

1 Like

I just switched my Nextcloud from podman to the Nix module a couple of weeks ago. Here is my config. There were some pain points figuring it out. I still don’t have the office suite working. The default Collabra would have to be run in a container because it’s not packaged for Nix yet. I couldn’t get Onlyoffice to work at all.

The migration was pretty ok if you follow the Nextcloud migration guide pretty closely and pay attention to the permissions. I don’t run talk so I can’t speak (hah) to that. But you can see how I had to add some dependencies for Memories.

1 Like

Thank you both for your configs , this is seriously helpful.
I’m hoping to make the switch to NixOS for my server early next year after a bit of testing on some other hardware, so I get it right.

@firecat53 what made you switch from a container to the module ?
Ive been considering switching from container myself but worried that I would lose the benefits of a container like packages not available yet on Nix, or a newer version available , but mainly it was that it provided a layer of isolation from my system. I’m very new to Nix still, so I’m not entirely sure if this is even a problem because of the way it works.
But a poll I ran on mastodon is currently showing majority of people running NixOS on a server use, packages and modules not containers, so I’m keen to get insights.

Isolation for services from NixOS modules is largely provided by systemd’s fancy “hardening” features, which use cgroups (i.e. the same kernel features that podman & co. are built on) to limit each service into its own container-like structure.

Systemd’s hardening features are more granular and opt-in, which means packagers need to be thorough and describe more explicitly what each service is allowed to do, but generally I find NixOS modules have gotten pretty good at providing adequate isolation.

For nextcloud specifically, it’s a bit complicated, because it’s composed of a variety of services. Most of it boils down to the db, web server and php server.

The various databases are managed pretty well, and so is nginx. I am less sure about php-fpm, it also has some of the most important settings enabled (ProtectSystem mainly), but its configuration seems less strict overall.

The nextcloud setup services are not isolated at all, but they only run once at boot/for every reconfiguration.

1 Like

Wow thank you so much for this, really appreciate the advice, this has sold me on going the module route now.
The only hurdle I have left now, is whether to setup and use coturn for use with nextcloud talk, or setup a VPN (probably the route I will go ) and use talk with the local stun server integrated with nextcloud (I’m not 100% sure this will work, but my limited knowledge and understanding of VPNs suggests it should ).

Thanks again for your help

I can’t particularly comment on nextcloud talk, but if you’re setting up a VPN wirenix may be of interest: Implementation Notes - man.sr.ht

1 Like