I have no support/technical question and have seen the support category. (Be aware that direct support questions will be deleted.)
on
Which general topic do you have
Looking for some general advice: can two nextclouds federate with each other? Like if I already have an account on one nextcloud, can I use it to login to a 2nd one, given the proper configuration?
Or does that path lead to madness?
The reason I ask is because I have nextcloudpi set up just the way I like it, but I don’t trust it to add more users or heavier web applications
atomik (~atomik@user/atomik) has joined nextcloud
I have a mac mini sitting around that I would like to install the AIO image and configure it for use with my family
but I don’t know how it would be to have two nextcloud installs connected to the same desktop / phone client apps.
So any general advice is appreciated.
Hi @treesMcGees — these are my thoughts based on how federation in Nextcloud works today (plus a few caveats).
What federation does allow
Nextcloud federation means that you can share files or folders from one instance with a user on another Nextcloud instance, and that remote folder/group will then “mount” inside your own instance.
If you add both servers as “trusted servers” to each other (Admin > Sharing / Trusted servers), federation becomes more seamless — including user autocomplete when sharing.
Besides files/folders, federation in Nextcloud (within Nextcloud Talk and other “Hub” components) also enables cross-instance chat and calls.
The main benefit: you can have multiple separate installations (for example one for yourself, one for family) — without shared DB, users, or passwords — and still connect them only through sharing, preserving isolation while enabling cooperation where needed.
What federation is not — what you should NOT expect
It’s important not to overestimate federation: in Nextcloud federation is not the same as “cloning” or “mirroring” servers. Specifically:
Files will not be automatically replicated or synchronized between installations. The remote content always stays physically on the host server. If that server goes down, the federated folder becomes inaccessible.
This means that if your goal is to have content available locally and synchronized on both servers, federation alone is not enough — it is not designed as a replication or fail-over mechanism.
Many features (calendars, contacts, third-party apps) are not federated — federation is primarily focused on files and, within Hub, communication.
If you plan to use one desktop/mobile client connected to two separate installations, that’s possible (the client supports multiple accounts). But they will not appear as a single unified cloud — they remain fully separate.
When it does make sense to have two installations + federation
For example, if you want:
one installation for yourself / experiments / technical stuff,
and another separate one for family or people you trust less,
— and you only want to occasionally share certain folders or files between them, then federation is perfectly reasonable. You get isolation + optional collaboration without mixing everything together.
So federation is ideal for collaboration between isolated instances, not for creating “one cloud with two servers”.
My recommendation regarding your original question
If your intention is: to have two Nextcloud installations — one “main/family” and one “for yourself/experiments/premium use” — and sometimes share some folders with the family or yourself across them, yes, federation is a sensible solution. It’s not “madness” — but you must be aware of its limits: federation ≠replication, and there is no unified global login across servers.
If, however, you expect full synchronization (mirroring of data, resilience, fallback, etc.), federation will disappoint you — in that case you need another approach (shared storage, RAID, rsync + scan, clustering, or other sync mechanisms).
My main problem with federation is: When one of the linked federated servers has a problem (e.g. is offline) your own instance too does not work (long running page loads running into timeouts - at least when I tried the last time).
Based on all the posts so far, it seems like federation is an advanced feature, and that keeping things simple would entail having separate logins for each Nextcloud Server, which the desktop and mobile clients support natively.
Here is a follow up question:
Are there any common pitfalls to be aware of when using desktop/mobile clients with multiple servers?
I have 2 Nextcloud instances from the office synced through my desktop client plus 5 private instances where 4 are accounts at servers offering a little bit of free space and the 5th instance is my main self hosted one (on raspberrry pi). That one is synced nightly with another instance on another raspberry in physical distance over WAN for backup using rclone. This is a one-way-sync as the 2-way-sync is beta only (or at least was when I set it up). The pitfalls for me are/were:
There is to think about how to setup the rclone. There are multiple options with their pros and cons. I use one sync job for each user syncing their folder(s) without considering shared folders and I use push (sync from local to remote, rclone can do also pull from remote to local as far as I remember).
rclone can only sync files, respectively only the application data from apps in your Nextcloud that works file-based. Apps that use extra tables cannot be synced. If somebody knows a good solution for syncing app data from apps that use extra tables, I would also be interested.
I did not find so far a good solution for hot switch in case of major instance being offline to use the other and sync back to main when main is online again and finally switch back. But have to say that that I did not invest much research and time to test. If somebody has solved this problem, I would be interested.
The sync folders on my local machine are in encrypted areas of my hard drive (not encrypting the whole drive/system). Once there are was a problem with the drive not being available in time when the desktop client autostarted and then the next time it came up, it started to sync all folders for all my instances. Instead some instances should not sync everything as I do not have enough space for that. - Fortunately I noticed in time before my SSD got filled up.
When you have older Operating system with older versions of the NextCloud desktop client you might experience problems with errors or slow sync. So you should use a recent version.
When you use the flatpak version consider the limited access to folders on your local drives.
On mobile devices* system permissions might limit the access to folders you might want to autosync.
On mobile devices* make sure that Nextcloud client may run in the background and is not locked down in permissions when you do not use it for a while - autosync stops then either.
*) Regarding mobile devices I can only talk about Android, don’t have IPhones.
If you have, let’s say 2 offices at different locations where most files are produced either at location one or location two, but you want to share/sync the files, rclone can the better solution than using federated servers. At least it is the more reliable solution - and the more performant solution.
It is not really clear what you try to achieve. Large setups (with >> 100 users), they have usually multi-server setups, with storage backend servers, database servers, and to connect to them you have load-balancers that redirect you to different front-end servers that gather all the information. This provides you more stability even if a single server fails or has to undergo maintenance.
In order to avoid such large setups, you can split in several smaller ones and interconnect with federation. But there is no failover, if your server or the server of the person that shares files is not available, you won’t be able to access the file. But you have maximum flexibility, you can start with two federated setups on the same hardware, if needed, you can move one to a different hardware or put it later in a different location. But the idea is that you share files with people on the federated setup and that you don’t need accounts on both setups.
In your case, if you are afraid if the RPi is not powerful enough, I’d perhaps consider starting with this device and then move your setup on a more powerful setup over time. Could be a mac-mini, intel nuc, … that will be much easier than trying to split everything between multiple raspberry pis.
I had two separate instances, an internal family-only server and a public facing community server, with both on a common Samba AD for family users. Having the same username and password on both was really useful.
I had a play with federation a couple of years ago but it didn’t really offer any practical benefit as things like Collectives, and Calendar don’t federate.
In the end I built a new instance (clearing away several years of legacy cruft in the process) and merged all the content to it. I’m using a combination of groups to control who gets which applications (and also who can see each other) and HAproxy rules to block certain apps from any public access (paranoia? maybe…) and so far this is working better for me. I’ve only got my stuff in one place, the other communities are only aware they had to use a different URL and reset passwords. I could have redirected the URL too if I wanted but preferred a clean break with the past.
At some point I’ll finish off writing up a how-to on the admin side of things.
What federation does allow
What federation is not — what you should NOT expect
When it does make sense to have two installations + federation