Multiple Payload projects from 1 MongoDB instance

[bjorntheart]

First off, thank you so much for releasing Payload to the public. I can see there has been a ton of work and thought that have gone into the project. Keep up the good work! 😄 🧨

Having looked at payload.init({...}) this looks quite possible to do.
I've added some examples below supporting

Since each Payload project can point to it's own MongoDB databse, and a MongoDB instance can consist of multiple databases, it seems quite possible to having many Payload projects from 1 MongoDB instance....but is it wise to do so ❓

Here follows some examples configs and .env setups to support this idea

Examples

Project 1 .env

MONGO_URL=mongodb://localhost:27017/project1-db
MONGODB_USER=dbuser1
MONGODB_PASSWORD=supersecret

Project 2 .env

MONGO_URL=mongodb://localhost:27017/project2-db
MONGODB_USER=dbuser2
MONGODB_PASSWORD=supersecret

payload.init set in both projects

payload.init({
  license: process.env.PAYLOAD_LICENSE,
  secret: process.env.PAYLOAD_SECRET_KEY,
  mongoURL: process.env.MONGO_URL,
  mongoOptions: {
    user: process.env.MONGODB_USER,
    pass: process.env.MONGODB_PASSWORD,
  },
  express: server,
});

From what I understand about Payload's pricing each project would have it's own license, right?

What are your thoughts about this, and would you consider a full multitenancy setup for Payload in the future?

[DanRibbens]

Thanks for your appreciation of the project!

As long as you are running each project in a separate node processes then this should work. It is a good idea to keep the databases separate as you showed to keep from having conflicts. Doing it this way, should be fine, MongoDB can run many DBs on one instance and Payload shouldn't have any issue here.

From what I understand about Payload's pricing each project would have it's own license, right?

Yes, each domain in production needs to have a license.

What are your thoughts about this, and would you consider a full multitenancy setup for Payload in the future?

What are you looking for specifically for "multitenancy"? From a technical standpoint, you're only limited by having to run more node processes to achieve this.

Are there other features you'd like to see to help you along?

I'm happy to help if you run in to anything or have more questions. Let us know how it goes.

[bjorntheart]

@DanRibbens Thanks for the response.

I haven't thought about running multipe Payload projects in each own node process 😅 , and I don't exactly know how to do this; how would I go about doing that?

[DanRibbens]

It is probably easiest to run each from its own server, but if you want to run two projects on one host server you'll need to run multiple instances of node and configure the webserver like nginx to route requests to the correct app. The MongoDB instance can either run locally or on a separate host.

Another option would be to use Docker containers and run one app per container or possibly share one container having each app as a different service, though I'm not an expert on docker.

[bjorntheart]

An yes, that makes sense. Thanks Dan

[Ontopic]

I use Docker to achieve running multiple Node instances and one MongDB instance, which works like a charm. Without experience with Docker probably not a quick solution though.

If you feel like you just want multiple MongoDB databases from different local test repos I'd like to recommend monogodb-memory-server used by Payload internally as well, see https://github.com/payloadcms/payload/blob/master/src/mongoose/connect.ts. This is very useful when exploring different approaches to structure your models and want to restart often. I'd recommend this combined with a seed script that fills the temporary MonogDB on boot. Something like below

  payload.init({
    secret: payloadSecret,
    mongoURL: mongodbURI,
    local: true,
  })

  const admin = await payload.create({
    collection: 'admins',
    data: {
      email: 'test@test.test',
      password: 'pass',
      roles: ['admin'],
    }
  })
  
  const site = await payload.updateGlobal({
    slug: 'site',
    data: {
      title: 'SiteTitle',
      domain: 'domain.com',
      slogan: 'Look at things running',
    }
  })

You'll be restarting a lot, but with a fresh quick start to see the effects of changing things in the Payload structure quickly.

[bjorntheart]

What are you looking for specifically for "multitenancy"? From a technical standpoint, you're only limited by having to run more node processes to achieve this.

@DanRibbens to your question: What would be useful is to manage multiple projects from one admin dashboard. Possible one or more admin accounts to rule them all, and then being able to scope users and the roles they have to a project. For example: An editor on 1 project should not necessarily be able to edit content from another project. The one(or, more) admin accounts are typically users who can manage stuff in the dashboard at the 'root' level and assign users, and roles to users, for projects.

I hope that makes sense :-)

[Ontopic]

Dan has a nice example about auth, https://github.com/DanRibbens/payload-authentication

What you want is for sure possible, but I think you're gonna have to think out the structure for your use-case specifically. A model with a collection for Users with a relation to Projects with a (custom) permission field should be a nice start. Perhaps the upcoming feature in Payload's next release - "user preference" - will be of help as well

[DanRibbens]

Oh! I'm surprised to see you link that repo that considering I haven't finished the post I created it for! I am glad you found it useful.

Sounds like @Ontopic is definitely on the right track. In addition to relating projects to users I would add a role for admins and create an access function so that a user can either be a member of that role or have a relationship to the project. You can see an example of this in the repo as part of the demo. Have a look at the access function and roles field: https://github.com/payloadcms/payload/blob/master/demo/collections/Admin.ts.

We just released user preferences today 😄. It has some enhancements to the admin experience, though nothing specific to multitenancy.
One feature that is coming soon that could be especially helpful here is the ability to save filters on collection lists. You can filter lists by related data now, but you can't save the filter or get back to it with a URL—stay tuned!