"Payload has transformed the way our clients manage content. It's an indispensable tool for any modern agency."
Get the resources you need to start building today
Microsoft chose Payload to tell the world about AI.
App architecture with PayloadCMS
I want to make a website using Next.js. I also need some kind of CMS and I planned to use PayloadCMS.
On my frontend there will be aricles. User can make an account and comment on aricles, make also threads and view their account settings. Also later on I want to add Stripe.
On CMS side, it needs to be hidden so only VPN users can access the CMS. Admins can add articles.
But I can't decide if I should implement the user logic to PayloadCMS or keep it separate. As I read tutorials and watched videos about PayloadCMS, most will integrate the frontend part into (frontend) folder, instead of using Payload as Headless option. I have three options on architecture side and maybe communtity could help me to decide the better option.
Option 1 - FE and CMS separately
* Publicly available for everyone
* Will have a separate database for application users and comments (later on stripe subscriptions)
* Will use better-auth for auth, better-auth will communcate with postgresql
* Will get data from server side components and from PayloadCMS api
* CMS will be in a separate domain, behind VPN
* CMS will hold articles and categories
* PayloadCMS users collection will be only for admins
With this option admins cannot manage users and comments and payments. Because comments and users are in separate database.
Option 2 - FE and CMS hosted separately, all data in PayloadCMS
Second option is that I can make a custom better-auth adapter that will communicate with PayloadCMS API. This way I will keep frontend and CMS separately, but admins can see users and manage comments etc.
Option 3 - All frontend inside (frontend) logic and using PayloadCMS
I understand the benefits of this option, quick to develop, same types, users are in same database, managed by PayloadCMS. But I dont know how big will my application because and i thing with this option its hard to implement Stripe and scale this applicaiton. It will be like a big monolith and I am not sure if this is a good option.
I hope that someone will have a strong option, what would be the way to go because I have searched for 2 days for the answer 😄 I really want to use PayloadCMS
Hi!
Having built a couple of quite large NextJS apps with payload both as a CMS and ecommerce site I would probably never go with anything but option 3. Having payload in your app does not mean that you're app is in any way limited to how payload works. It's just one part of your NextJS app. If you want a separate DB aswell there is nothing stopping you. If you need to read stuff super fast for some reason (and want to skip hooks and auth controll) you can bypass payload and read straight from the db.
Implementing stripe and scaling would have nothing to do with payload other than you possibly using payload as an ORM or Admin UI.
The upside of being able to use the local api. having types and getting a free admin UI for everything i store in the DB is a huge upside for me.
I'd also recommend option 3 and don't think you'll have significant issues at scale. Go for it!
Thank you very much for the help!
I will try to implement my app using the option 3.
@332241126150897674When using the option3. As I understand that PayloadCMS will create rest api automaticly. I can put /admin path behind Cloudflare Zero Trust Access and protect it. But how can I make so that Payload api will not be acessible to public?
On frontend folder i can use Loacal api that communicates with data, but I would like that api is not available to public
The enpoints will be protected by the access control by default. You could pretty much put the /api directory behind the zero trust also but you would have to have some exceptions. The upload collections (think media and docs) that you want to allow anonymous access to would by default be accessed though those apis. But you could probably whitelist those specific enpoints
Thanks for the info! I will give it a try
Go with option 3. Its best.
I have few nextjs apps which are in turborepo. One app is plain nextjs but using payload api on server side and using next-auth.
One payload with nextjs with multi tenant which is configured to host multiple domains and working great with no issues. Am using nextjs middleware to route domains to it's tenant based route.
Scaling is not an issue with payload. I also have tauri app in same turborepo where its using payload api's. All using same types and working great.
You can either use single collection for users and admin. But am keeping them separated. My ecommers payload multi tenant nextjs app have two separate collections where am having customers and managers for users, I could've used single collection with roles, but just wanted to keep separate table because my (frontend)/[tenant] routes using next-auth which is not linked with admin user collections, so it's just a nextjs app with next-auth setup with no payload link, but server functions connects with payload to get ecommerce data.
U can either merge or keep complete separation between payload and front-end if u want to. Payload is flexible to plan most of the projects as per need.
Thanks for the info. I currently setup my auth with Better-auth, using the role plugin and the same table. Currently looks that everything works
Do you have a single user collection with working better auth implementation?
Yes, i have default users collection
option 3, anything else is over thinking and waste of time. Don't solve imaginary scaling problems.
Star
Discord
online
Get dedicated engineering support directly from the Payload team.