Have to say, I just wasted two hours trying to get this running...again.
The first time I went through the tutorial I had it up and running in less than five minutes (Windows 11, node 22). A while later I tried the same thing on two work laptops: a M1 and another Windows 11 machine.
It fails complaining that cross-env isn't found. Was not able to find a resolution after hours of trying.
Eventually realized that a dependency was unavailable and I had to provide a mirror for it. Really caught me off guard. Payload CMS is looking really clean and solid. I have it deployed successfully to an Azure App Service via BitBucket, leveraging Cosmos.
Thanks, this looks promising. Upgrades, if problematic as some have mentioned, are not really a concern for me. That's on the next poor fool. I just need to get something out the door to score a bonus.
Maybe just one feedback item for the site: "Visual Editing" shows up at the top of a few use case pages, and in other spots around the site. When you click on it, it's not very obvious you've been brought to the "enterprise" site. Just a clearly different nav bar on the enterprise pages, or callout badge on Enterprise features would be good.
I feel like a few people could be convinced that visual editing is part of the open source base product, not the enterprise plugins.
Performance problems are usually something related to maybe missing indexes in your database for fields that you query on often, or similar. Payload itself is super thin. Can you give me an example of where you're seeing slowdowns? Maybe I can point you in the right direction.
Also I would love to hear about where Payload is not flexible enough. Extensibility is one of our priorities so if there is something you'd like to accomplish, but can't, I will see what I can do about it!
Hey there - small to medium orgs can use one of the available community, open source SSO plugins, with the only caveat that they are not officially supported by Payload. Or you could build your own!
Question - does the word "enterprise" make you think that the amount we charge would make it unfeasible for your org to pay to use Payload?
I don't think it's ideal that we hide all our "premium" features behind the word "enterprise" and have been thinking of alternative words / messaging to describe that.
Hey, in my opinion it is fair to have some features behind a paywall for an open core model (although I am not a fan of it, but I really understand the reasons).
But personally, I think having core security features (which I believe SSO is, e.g. also for small orgs) behind such paywall is not really helping the product.
Using a free plugin developed independently from the core product does incur other issues e.g. during updates etc. Also, it does present an additional hurdle for all non-enterprise users to make use of the, typically, more secure SSO solution they might already use leading to - in my opinion - more unsafe deployments of Payload (or any other product). It is also not helping to overcome the cybersecurity poverty line anytime soon.
When I am deciding whether to buy the enterprise version of a product, for me a main concern is whether I would also be able to use the product with its core features without any subscription (preventing vendor lock-in, in worst case I would be able to run the product on my own for a specified period of time). This wouldn't be the case if no user can login any more ^^
One last aspect: We as an organization also provided and extended SSO implementations in various products in the last years. But we only do this if the SSO code is free software. In our experience SSO implementations are way better if they can be improved by the community.
I think server components have been very badly marketed. They're totally opt-in, so I don't see how this would make React instantly a terrible framework. I for one think they represent a lot of value.
If you don't use them, then React is quite literally no different to you.
Hey! I'm CEO of Payload and want to make sure we resolve any bugs you found. Pretty much the whole team is focused on closing issues right now as we work toward 3.0 stable so depending on when you were trying out Payload, I'd imagine you might see lots of the bugs you faced as already resolved.
Keystone would be my other vote though, if I were looking for a CMS and Payload didn't exist. I think that is a solid crew.
We have a package that allows you to deploy Payload in a NextJS app serverlessly, and it works great. I actually tried bundling as one endpoint early on while exploring with the NextJS approach and it seemed to work perfectly. But honestly I can’t remember the pros and cons.
I’d say give it a shot, and if you need anything, let us know!
https://payloadcms.com
I built it because I was in the same situation as you.