Use a single or multiple Nextcloud instances for a multi-domain setup?

Summarized Question

Assume I have multiple domains which are all CNAMEs to the same server. Each domain shall serve Nextcloud with LDAP user management. Should I use an individual Nextcloud instance and an individual LDAP Root DIT for each domain or a single Nextcloud instance and a single LDAP Root DIT for all domains?

Are there any technical limitations with one approach, but not with the other? Maybe some use cases which are not supported if one decides for the “wrong” approach?

Detailed Description of Scenario

Background

There is a single virtual root server with a single, global IPv4 and IPV6 address. There is one A/AAAA record for the “internal” host name determined by my provider, and several CNAME records for my user-friendly domains. In order to be future-proof, I use different aliased host names for each service.

The setup looks something like this:

  • serial-number.my-provider.com: A/AAAA record to IP
  • my-domain.tld: all CNAME records
    • cloud.my-domain.tld → Apache with NextCloud
    • directory.my-domain.tld → OpenLDAP
    • mail.my-domain.tld → Postfix and Dovecot
  • some-other-domain.tld: all CNAME records
    • cloud.some-other-domain.tld → Apache with NextCloud
    • directory.some-other-domain.tld → OpenLDAP
    • mail.some-other-domain.tld → Postfix and Dovecot

Detailed Question

I wonder

  • whether Apache should serve the same Nextcloud instance for cloud.my-domain.tld and cloud.some-other-domain.tld or two different instances, and
  • whether OpenLDAP should provide a single root DIT, e.g. dc=serial-number, dc=my-provider, dc=com and separate user/group accounts on a deeper level, e.g. by an attribute, or whether OpenLDAP should provide two different root DITs, e.g. dc=my-domain, dc=tld and dc=some-other-domain, dc=tld right from the top.
  1. Option 1: Same NextCloud instance and same LDAP tree

    • Apache: serve cloud.my-domain.tld and cloud.some-other-domain.tld from the same web root, e.g. /var/www/nextcloud.
    • OpenLDAP: Single root DIT and separation of (user) by dedicated attribute, e.g.
      dc=serial-number, dc=my-provider, dc=com
         |
         +-- ou=users
                |
                +-- uid=john.doe
                |      uid: john.doe
                |      givenName: John
                |      surname: Doe
                |      associatedDomain: my-domain.tld  // separation by attribute
                |
                +-- uid=diane.miller
                       uid: diane.miller
                       givenName: Diane
                       surname: Miller
                       associatedDomain: some-other-domain.tld  // separation by attribute
      
  2. Option 2: Different NextCloud instances and different LDAP trees

    • Apache: serve
      • cloud.my-domain.tld from /var/www/my-nextcloud and,
      • cloud.some-other-domain.tld from /var/www/other-nextcloud.
    • OpenLDAP: Different root DITs, e.g.
      dc=my-domain, dc=tld
         |
         +-- ou=users
                |
                +-- uid=john.doe
                       uid: john.doe
                       givenName: John
                       surname: Doe
      dc=some-other-domain, dc=tld
         |
         +-- ou=users
                |
                +-- uid=diane.miller
                       uid: diane.miller
                       givenName: Diane
                       surname: Miller
      
  3. Option 3: Different NextCloud instances with shared LDAP tree

    • Apache: serve different web roots for each domain, as in option 2
    • OpenLDAP: use the same tree and separate by attribute, as in option 1
  4. Option 4: Same NextCloud instance with multiple LDAP trees

    • Apache: serve the same Nextcloud instance from a single web root, as in option 1
    • OpenLDAP: use different trees for each domain

    Assumingly, this option won’t be possible due to technical constraints within NextCloud itself which only allows to configure a single base DN.

Own Thoughts

  • If I want to be able to share files/calenders/… with users across domains, a single NextCloud instance is probably preferable. If the instances were kept seperately, each instance only knows its “own” users. I am aware that there is something called “federation”, which in my understanding allows to share objects with other NextCloud instances and “foreign” user accounts, but I have never looked into that.
  • If there is the chance that I will need to transfer control of the other instance to someone else in the future (i.e. move it away from my own infrastructure), it is probably good to keep it separate right from the beginning.

For the apache part, both methods are possible. If you want one setup in the background, you just use the other domains in the ServerAlias:
https://httpd.apache.org/docs/2.4/vhosts/name-based.html

For the sharing, you can share over different server setups with federated sharing. Calendars however seem not to be supported yet (Federated calendar and contacts sharing [$360.00] · Issue #1440 · nextcloud/server · GitHub). If you plan only for a few users, I wouldn’t bother to run different setups, especially if the configuration will be very similar.

If you have many users, the different sub-domains require different environments (different set of apps), they are in different locations and you want each server to run at their location for better performance, … then a multiple server setup can be of advantage (though you can start on a single hardware).

Depending on the size, it might be interesting to consider enterprise support (some case studies: Nextcloud whitepapers, case studies & more):
Nextcloud Enterprise pricing

Thanks, but I knew that. I already use that approach for the “technical” domain provided my hoster serialnumber.my-hoster.com and a lot of sub-domains on my “actual” domain cloud.my-domain.tld (NextCloud), jitsi.my-domain.tld, photos.my-domain.tld(Lychee). That’s nothing new to me, but thanks anyway.

I knew that. The question was rather how complex it would become. But if I am not mistaken it should be fairly easy, just mutually add each domain of the other instance to trustedDomains to the opposite instance. Right? Are there any difficulties I am unaware of?

Well, the main point is that I really want two different domains. At the moment I self-host one Nextcloud instance for me and my housemate at something like my-first-name-my-last-name-in-my-town.tld. So the domain is specific to my person.

In the future, my uncle’s family (my uncle, his wife, their three kids) also plan to use a cloud solution for backup reasons and file synchronization across their PCs. Of course, also for privacy reasons they want to get away from Google Calender, Contacts, etc, and I am going to move their mail accounts to my Postfix/Dovecot installation.

Yes, I could simply add 5 more users to my NextCloud instance which then would serve 7 users instead of currently 2. However, it would look a little bit funny, if they had mail accounts like joe.miller@doe-family-boston.com, if Joe Miller is neither a “Doe” nor living in Boston.

So, my uncle’s family get their own domain. That is settled. The actual technical question was: Do I have to expect any technical problems if the same NextCloud instance serves two different domains, e.g. cloud.my-family-in-my-town.tld and cloud.my-uncles-family-in-their-town.tld? In either case I use Apache’s virtual hosting functionality, the question is wether their will be any problems, if both domains point to the same web root. Somewhere I read that certain NextCloud apps cache/store the domain by which they were initially reached after the first installation and that those apps show funny/buggy behavior if they are contacted via a different domain. Is that correct? Basically, it was something due to same-origin CSFP mechanisms which do not play well with changing domains.

That’s not the point. I only have 2 + future 5 users and I am the family’s system admin. Only having one NextCloud instance would make my life a little bit easier, because I only have to maintain/update/troubleshoot etc. one instance, but this is of course a no-go if a single instance cannot server two different domains properly.

The decision is not between one-instance-one-domain-setup vs two-instances-two-domains-setup, but but between two-domains-with-one-instance-setup vs. two-domains-with-two-instances-setup. Having two different domains is a must.

Not going to happen for only 2+5 users and a private family project.