Launch HN: Payload (YC S22) – Headless CMS for Developers
138 comments
Nice job getting to launch. However I'm really confused about the value prop.
> There's no point competing in that noisy market, so we're undercutting it instead, by treating developers as first-class citizens.
Who is the target market for this? who are the users and what is the job function in their company?
The vast majority of CMS use is by Marketing departments building the public web presence of their company. Marketing doesn't care about building or maintaining their own CMS, or making it easy for developers. In fact, those are costs they want to minimize and externalize.
Speed of creating, editing, reviewing, and publishing content is the most important thing. Integrating the site into the hundreds of mar-tech tools is also important (e.g. gating content for sales leads, funnel analytics, mailing list signup and validation, A/B testing, etc)
Large CMSs are pretty optimized for the create-review-publish flow, and I don't see you explain any advantage you provide here. Mar-tech companies live or die on adoption, so they invest heavily in making plugins for CMSs. Something they are not going to do for Payload. Why would marketing pay for internal developers to do this integration (regardless of how easy it is) when they get that for free with plugins to existing systems, written by the engineers of those systems?
In short, none of the benefits you cite at all align with the KPIs of a marketing department using a CMS (typical engagement numbers like time-on-site or page views, but also marketing-generated or marketing-influenced leads and opportunities)
And as an engineer who has built multiple SaaS apps, I've never needed CMS capabilities built into those apps. The closest need would be the help/documentation/API spec, which we've traditionally addressed using another site or SaaS app (e.g. a third party helpdesk or knowledge base SaaS).
Hence why I'm a little confused, but do want to be positive. Who is your ideal customer, why, what business problems do they have, and why is Payload the best option to those problems?
> There's no point competing in that noisy market, so we're undercutting it instead, by treating developers as first-class citizens.
Who is the target market for this? who are the users and what is the job function in their company?
The vast majority of CMS use is by Marketing departments building the public web presence of their company. Marketing doesn't care about building or maintaining their own CMS, or making it easy for developers. In fact, those are costs they want to minimize and externalize.
Speed of creating, editing, reviewing, and publishing content is the most important thing. Integrating the site into the hundreds of mar-tech tools is also important (e.g. gating content for sales leads, funnel analytics, mailing list signup and validation, A/B testing, etc)
Large CMSs are pretty optimized for the create-review-publish flow, and I don't see you explain any advantage you provide here. Mar-tech companies live or die on adoption, so they invest heavily in making plugins for CMSs. Something they are not going to do for Payload. Why would marketing pay for internal developers to do this integration (regardless of how easy it is) when they get that for free with plugins to existing systems, written by the engineers of those systems?
In short, none of the benefits you cite at all align with the KPIs of a marketing department using a CMS (typical engagement numbers like time-on-site or page views, but also marketing-generated or marketing-influenced leads and opportunities)
And as an engineer who has built multiple SaaS apps, I've never needed CMS capabilities built into those apps. The closest need would be the help/documentation/API spec, which we've traditionally addressed using another site or SaaS app (e.g. a third party helpdesk or knowledge base SaaS).
Hence why I'm a little confused, but do want to be positive. Who is your ideal customer, why, what business problems do they have, and why is Payload the best option to those problems?
Hey, great question. Our target market is enterprise uses of Payload, where we can power critical content-based infrastructure, but that does not solely mean marketing websites.
I think that your comment is pointing at one of the areas that traditional CMS -do not successfully address- in that CMS is typically only thought of as a means to manage website content. But content is much more broad. Think of Spotify (managing album art, playlists, artist descriptions) but using that content through native apps, smart TV apps, web apps, etc.
For example, some of our current enterprise clients are using Payload to deliver _their_ clients with a customized copy of Payload to manage their own virtual events (attendees, webinar links, landing page content, post-webinar video recordings, etc). Or to manage a "broadcast platform" where their client can publish their own Roku channel (episodes, series, seasons, playlists, etc). This is all content, yet it's not marketing page content.
One of the bigger uses of Payload so far has actually been to power the entire backend for an Uber-like snow plow service, where the business side can log in and provide customer support, manage requests, approve service providers, and more. The devs were able to leverage Payload's auth, access control, hooks for Stripe integration, and last but not least - the entirety of its admin UI.
That's not to say that we -can't- power marketing websites. Of course Payload can do that in spades. But that is only one small aspect of our target market and we make the most sense for enterprise content needs, where dev teams may need to manage more than just marketing pages. Maybe they also need to manage customer support resources or more intense content needs (like Klarna).
In my experience implementing enterprise websites for large companies, the buying process usually goes like this:
- Director or VP of Marketing says we need to modernize and move to a better web stack, let's go headless
- They start to evaluate options, but need engineering backup because headless CMS is a tech decision
- They tell their engineering team to go find the best headless CMS
- Devs do the recon, then report upward
Our strategy is to appeal straight to devs, and by being a solid product that they can advocate for, they will. This is actually how Klarna found my agency when we were hired to build their enterprise site - by the engineers. Decision to go headless came from the top, but then engineers found me and selected tech. Same with a few of Payload's bigger inbound enterprise opportunities in the pipeline right now.
Long story short, I fully understand your question and in all reality our messaging is nowhere near sharp / completed. We've seen a lot of growth over the past few months and are about to the point where we can take a breath, revisit some of this, and razor-sharpen our positioning!
I think that your comment is pointing at one of the areas that traditional CMS -do not successfully address- in that CMS is typically only thought of as a means to manage website content. But content is much more broad. Think of Spotify (managing album art, playlists, artist descriptions) but using that content through native apps, smart TV apps, web apps, etc.
For example, some of our current enterprise clients are using Payload to deliver _their_ clients with a customized copy of Payload to manage their own virtual events (attendees, webinar links, landing page content, post-webinar video recordings, etc). Or to manage a "broadcast platform" where their client can publish their own Roku channel (episodes, series, seasons, playlists, etc). This is all content, yet it's not marketing page content.
One of the bigger uses of Payload so far has actually been to power the entire backend for an Uber-like snow plow service, where the business side can log in and provide customer support, manage requests, approve service providers, and more. The devs were able to leverage Payload's auth, access control, hooks for Stripe integration, and last but not least - the entirety of its admin UI.
That's not to say that we -can't- power marketing websites. Of course Payload can do that in spades. But that is only one small aspect of our target market and we make the most sense for enterprise content needs, where dev teams may need to manage more than just marketing pages. Maybe they also need to manage customer support resources or more intense content needs (like Klarna).
In my experience implementing enterprise websites for large companies, the buying process usually goes like this:
- Director or VP of Marketing says we need to modernize and move to a better web stack, let's go headless
- They start to evaluate options, but need engineering backup because headless CMS is a tech decision
- They tell their engineering team to go find the best headless CMS
- Devs do the recon, then report upward
Our strategy is to appeal straight to devs, and by being a solid product that they can advocate for, they will. This is actually how Klarna found my agency when we were hired to build their enterprise site - by the engineers. Decision to go headless came from the top, but then engineers found me and selected tech. Same with a few of Payload's bigger inbound enterprise opportunities in the pipeline right now.
Long story short, I fully understand your question and in all reality our messaging is nowhere near sharp / completed. We've seen a lot of growth over the past few months and are about to the point where we can take a breath, revisit some of this, and razor-sharpen our positioning!
This guy CMSes.
I worked in consulting for many years doing a lot of CMS projects for Fortune 500s. They always bought their CMS products based on the marketing pitch to marketers. It was mostly bs, but the pitch was always focussed on engagement, testing, analytics, funnels, acquisition. I always came with the perspective that your CMS need not and usually should not be responsible for any of that and you can manage all of that in the application tier via a tag manager product or the like. The current kind of this space is Adobe. They built up their "Marketing Cloud" vis a series of acquisitions and sell it as a fully-baked product that does everything you'd ever need and then attach an 8-figure price tag and hand you off to integrators (like the companies I worked for) to do the (also very costly) implementation. And it's really very hit and miss to get adoption after you've delivered them such an ornery beast to manage 30 pages of brocureware.
We managed to push a few clients towards Contentful which is headless and a lot more dev friendly but they also are pretty sneaky with pricing and get fairly expensive with anything beyond basic usage. I actually begged their sales team to do a better job selling to marketers because their pitch was too tech focussed. I think the sweet spot is to not just say "developers like it" but rather "it will require far fewer developer hours to implement" which will resonate a lot more with budget holders. Also, my firm belief that building a suite of marketing tools by picking and mixing the best products is likely still easier and cheaper than buying any all-in-one tool that isn't great at anything.
I worked in consulting for many years doing a lot of CMS projects for Fortune 500s. They always bought their CMS products based on the marketing pitch to marketers. It was mostly bs, but the pitch was always focussed on engagement, testing, analytics, funnels, acquisition. I always came with the perspective that your CMS need not and usually should not be responsible for any of that and you can manage all of that in the application tier via a tag manager product or the like. The current kind of this space is Adobe. They built up their "Marketing Cloud" vis a series of acquisitions and sell it as a fully-baked product that does everything you'd ever need and then attach an 8-figure price tag and hand you off to integrators (like the companies I worked for) to do the (also very costly) implementation. And it's really very hit and miss to get adoption after you've delivered them such an ornery beast to manage 30 pages of brocureware.
We managed to push a few clients towards Contentful which is headless and a lot more dev friendly but they also are pretty sneaky with pricing and get fairly expensive with anything beyond basic usage. I actually begged their sales team to do a better job selling to marketers because their pitch was too tech focussed. I think the sweet spot is to not just say "developers like it" but rather "it will require far fewer developer hours to implement" which will resonate a lot more with budget holders. Also, my firm belief that building a suite of marketing tools by picking and mixing the best products is likely still easier and cheaper than buying any all-in-one tool that isn't great at anything.
I resonate a lot with what you're saying.
> I always came with the perspective that your CMS need not and usually should not be responsible for any of that and you can manage all of that in the application tier via a tag manager product or the like
Totally agreed. A CMS should stick to managing content. And its flexibility should allow it to integrate with services that are purpose-built. In addition to those that you mentioned, a good example of this would be Algolia for search experiences.
> "it will require far fewer developer hours to implement" which will resonate a lot more with budget holders.
I also resonate with this, and I think this needs to be worked into our positioning more, because that, at its core, is what Payload tries to do -through- its developer friendliness. When you don't have to fight your software, you save an incredible amount of time. At the core of any larger content infrastructure is code, and the more efficiently you can implement it, let alone maintain it, the more time / money you can save.
> I always came with the perspective that your CMS need not and usually should not be responsible for any of that and you can manage all of that in the application tier via a tag manager product or the like
Totally agreed. A CMS should stick to managing content. And its flexibility should allow it to integrate with services that are purpose-built. In addition to those that you mentioned, a good example of this would be Algolia for search experiences.
> "it will require far fewer developer hours to implement" which will resonate a lot more with budget holders.
I also resonate with this, and I think this needs to be worked into our positioning more, because that, at its core, is what Payload tries to do -through- its developer friendliness. When you don't have to fight your software, you save an incredible amount of time. At the core of any larger content infrastructure is code, and the more efficiently you can implement it, let alone maintain it, the more time / money you can save.
Inbound developer interest = company intent (and segment intent).
Just make sure your growth motion doesn’t stop there and layers in a way to nab the buyer.
Standard way is to outright ask for introduction or outbound, but there’s usually a clever referral mechanism you can discover somewhere.
e.g. “Ask your marketer for demo content” prompt, but with better copy.
Just make sure your growth motion doesn’t stop there and layers in a way to nab the buyer.
Standard way is to outright ask for introduction or outbound, but there’s usually a clever referral mechanism you can discover somewhere.
e.g. “Ask your marketer for demo content” prompt, but with better copy.
100%.
This is very good insight and I will take it to heart.
This is very good insight and I will take it to heart.
Hacker News is amazing because there are so many confidently wrong people.
Ever hear of contentful? https://www.crunchbase.com/organization/contentful
Or the entire category of headless CMS (A $600m/yr market growing at 20%+/year), for which eng is a primary stakeholder in the buying decision?
Ever hear of contentful? https://www.crunchbase.com/organization/contentful
Or the entire category of headless CMS (A $600m/yr market growing at 20%+/year), for which eng is a primary stakeholder in the buying decision?
Agreed! Do you have a favorite CMS?
(offtopic side note in case anyone is confused: I edited out that line you quoted. launching these guys was a last-minute thing this morning so I've been editing their blurb on the fly, from airplane wifi no less. I hope it worked!)
(this does not affect your question)
(this does not affect your question)
Few things I really need in a CMS:
* allow me to create a localized content (you seem to have this covered).
* a good story for blobs (images, video, PDFs, etc).
* integrated full text search (I do not want to set up elastic search when using a headless CMS saas).
* fully spec'd API (when I have defined a content type, I need some API spec to be updated; openAPIv3 was good, GraphQL is better: so I can generate a client lib).
* some mechanism to know the API was updated (so I can show the "a new version is available, the version you run may no longer work in certain cases, please click here to use the newest version" message somewhere).
* a story on content blocks (say: text, image, text, quote, text, author card) vs embeddable content in text blocks (say: a text block with a way to embed images/etc into it); the latter is really hard to do right imho.
* allow me to create a localized content (you seem to have this covered).
* a good story for blobs (images, video, PDFs, etc).
* integrated full text search (I do not want to set up elastic search when using a headless CMS saas).
* fully spec'd API (when I have defined a content type, I need some API spec to be updated; openAPIv3 was good, GraphQL is better: so I can generate a client lib).
* some mechanism to know the API was updated (so I can show the "a new version is available, the version you run may no longer work in certain cases, please click here to use the newest version" message somewhere).
* a story on content blocks (say: text, image, text, quote, text, author card) vs embeddable content in text blocks (say: a text block with a way to embed images/etc into it); the latter is really hard to do right imho.
This is a great list! I don't see anything in here that Payload doesn't handle. I'll try to address each.
> allow me to create a localized content (you seem to have this covered).
Localization can be done on any field(s), at any point in your content structure .
> a good story for blobs (images, video, PDFs, etc).
You can have as many upload collections and set mimetypes. Payload saves to a local directory in your Node app or you can use our cloud storage plugin for S3/Azure/GCP.
> integrated full text search (I do not want to set up elastic search when using a headless CMS saas).
Payload has a lot different querying options and you can get creative with relating content to one searchable collection, but we still recommend a proper search tool when you have complex filtering and searching requirements or massive collections which are better optimized elsewhere.
> fully spec'd API (when I have defined a content type, I need some API spec to be updated; openAPIv3 was good, GraphQL is better: so I can generate a client lib).
Along with REST endpoints, Payload opens up a full GraphQL implementation with complete schemas based on the config you provide for queries and mutations. It also can write these out to a graphql.schema file using a built-in command.
> some mechanism to know the API was updated (so I can show the "a new version is available, the version you run may no longer work in certain cases, please click here to use the newest version" message somewhere).
This would be up to your implementation of Payload and your frontend. You could make a field for publishDate or increment a version number to handle this scenario and query and compare based on that.
> a story on content blocks (say: text, image, text, quote, text, author card) vs embeddable content in text blocks (say: a text block with a way to embed images/etc into it); the latter is really hard to do right imho.
Payload's richtext field is capable of embedding relationships and file uploads so you can do the hard thing or you do predefined blocks for your content editors to use like you said too.
We really put in the work, I'd love to hear from you if you try it out.
> allow me to create a localized content (you seem to have this covered).
Localization can be done on any field(s), at any point in your content structure .
> a good story for blobs (images, video, PDFs, etc).
You can have as many upload collections and set mimetypes. Payload saves to a local directory in your Node app or you can use our cloud storage plugin for S3/Azure/GCP.
> integrated full text search (I do not want to set up elastic search when using a headless CMS saas).
Payload has a lot different querying options and you can get creative with relating content to one searchable collection, but we still recommend a proper search tool when you have complex filtering and searching requirements or massive collections which are better optimized elsewhere.
> fully spec'd API (when I have defined a content type, I need some API spec to be updated; openAPIv3 was good, GraphQL is better: so I can generate a client lib).
Along with REST endpoints, Payload opens up a full GraphQL implementation with complete schemas based on the config you provide for queries and mutations. It also can write these out to a graphql.schema file using a built-in command.
> some mechanism to know the API was updated (so I can show the "a new version is available, the version you run may no longer work in certain cases, please click here to use the newest version" message somewhere).
This would be up to your implementation of Payload and your frontend. You could make a field for publishDate or increment a version number to handle this scenario and query and compare based on that.
> a story on content blocks (say: text, image, text, quote, text, author card) vs embeddable content in text blocks (say: a text block with a way to embed images/etc into it); the latter is really hard to do right imho.
Payload's richtext field is capable of embedding relationships and file uploads so you can do the hard thing or you do predefined blocks for your content editors to use like you said too.
We really put in the work, I'd love to hear from you if you try it out.
> We really put in the work, I'd love to hear from you if you try it out.
I see that. And I saw that you have probably tick most of the boxes in my list.
Excuse me for my late reply...
> Along with REST endpoints
Are they fully spec'ed (as in OpenAPIv3)? And may the spec change based on how you setup/evolve your site?
I'm really, really done with writing boilerplate, a full spec (OpenAPIv3 or GraphQL) allows me to generate a client lib, and these spec standards have very cool generator for them.
I went deeper into Payload, and the REST endpoints are unspecced (just docs for the endpoints, not formal spec for endpoints or their bodies).
> full text search
I mentioned it because it is a really hard problem. Keeping the search db and the main db in sync is hard, i18n when doing full text search is hard, allowing customization of the full text search engine is certainly also going to be hard. It would be great to have something that abstracts some of these away.
I see that. And I saw that you have probably tick most of the boxes in my list.
Excuse me for my late reply...
> Along with REST endpoints
Are they fully spec'ed (as in OpenAPIv3)? And may the spec change based on how you setup/evolve your site?
I'm really, really done with writing boilerplate, a full spec (OpenAPIv3 or GraphQL) allows me to generate a client lib, and these spec standards have very cool generator for them.
I went deeper into Payload, and the REST endpoints are unspecced (just docs for the endpoints, not formal spec for endpoints or their bodies).
> full text search
I mentioned it because it is a really hard problem. Keeping the search db and the main db in sync is hard, i18n when doing full text search is hard, allowing customization of the full text search engine is certainly also going to be hard. It would be great to have something that abstracts some of these away.
Oh! I misunderstood your point about versioning. I was thinking versioning of content but you're talking about the API.
That is a harder situation, I think my approach here would be to route requests to the api version on a separate new instance, `v1.example.com/api`, `v2.example.com/api` for example. Any way I can think of handling this scenario in the application layer gets messy right away, but maybe there is a good way I haven't thought about yet. I'll keep this in mind in case as a future feature we could build in or make turn into a plugin perhaps.
That is a harder situation, I think my approach here would be to route requests to the api version on a separate new instance, `v1.example.com/api`, `v2.example.com/api` for example. Any way I can think of handling this scenario in the application layer gets messy right away, but maybe there is a good way I haven't thought about yet. I'll keep this in mind in case as a future feature we could build in or make turn into a plugin perhaps.
Having a schema generated, one could see if it changed between releases and increase a version number based on that.
Have you ever found one that covers all of these well?
Nope. Not even close. And always a huuuuuge hassle to work around a missing bit when needed (obviously we can also change the requirements to meet deadline/budget)
I had most of this in the times of PostNuke and MD-Pro. How I miss them! :_(
> Consistent with Payload's goal of making you learn as little of Payload as possible, customizing and using the Rich Text Editor does not involve learning how to develop for a Payload rich text editor. Instead, you can invest your time and effort into learning Slate, an open-source tool that will allow you to apply your learnings elsewhere as well.
I have to say, this callout from the JSON-based Rich Text Field docs [0] really resonated with me. Rather than build out something yourself that would further lock folks into your platform (and force them to customize yet another bespoke tool), you leaned on an existing, mature, and capable framework for rich text editors, Slate [1]. And your stated reason—to “allow you to apply your learnings elsewhere as well”—was really appreciated. It shows a lot of respect for time and resources of the individuals using Payload.
I don’t have a specific need for a headless CMS right this second, but I can promise that Payload will be my first candidate to review when I do. Previously, it would’ve been Strapi, as I’ve used that tool already for several projects. But that one paragraph really struck me.
[0]: https://payloadcms.com/docs/fields/rich-text [1]: https://docs.slatejs.org/
I have to say, this callout from the JSON-based Rich Text Field docs [0] really resonated with me. Rather than build out something yourself that would further lock folks into your platform (and force them to customize yet another bespoke tool), you leaned on an existing, mature, and capable framework for rich text editors, Slate [1]. And your stated reason—to “allow you to apply your learnings elsewhere as well”—was really appreciated. It shows a lot of respect for time and resources of the individuals using Payload.
I don’t have a specific need for a headless CMS right this second, but I can promise that Payload will be my first candidate to review when I do. Previously, it would’ve been Strapi, as I’ve used that tool already for several projects. But that one paragraph really struck me.
[0]: https://payloadcms.com/docs/fields/rich-text [1]: https://docs.slatejs.org/
Ugh I am so happy that this paragraph resonated with you. I personally wrote it and it's so, so important to me. It represents the ethos of what we're trying to do with Payload. The whole team and I feel very strongly about this.
Thank you for your kind words and I would love to help you as you start your next project with Payload!
Thank you for your kind words and I would love to help you as you start your next project with Payload!
As someone who's been actively looking for a headless CMS recently, I'm curious about how you compare yourselves to Contentful [1]?
From a quick look the key difference is that Payload's backend can be self-hosted, but Contentful is SaaS only.
You've said that you're targeting enterprise customers and mention an SLA in that respect. Does that mean your enterprise offering is also SaaS only?
[1] https://www.contentful.com/
From a quick look the key difference is that Payload's backend can be self-hosted, but Contentful is SaaS only.
You've said that you're targeting enterprise customers and mention an SLA in that respect. Does that mean your enterprise offering is also SaaS only?
[1] https://www.contentful.com/
Hey there - your points are accurate! Here are a few more:
- We are open source / MIT
- You can re-use Payload's auth layer in your own apps and with Contentful you can't
- Contentful has rigid RBAC, but Payload features function-based access control down to the field level
- Payload supports field conditional logic, meaning "check a checkbox, see more fields, uncheck it, extra fields disappear". This is huge. And is super hard to build right but it's very important for a good admin experience.
- Payload gives you a local Node API (note: not HTTP / REST / GraphQL.) Contentful does not. With Payload's local API, you can do lots of awesome things within hooks, access control, etc. - and even reuse it in your own endpoints. All of this is impossible with Contentful without going through their HTTP layer
- Payload lets you add your own admin UI views
- Payload has no usage limits
- Payload is code-first, Contentful is "point and click"
Phew. There's a lot more. This all is just top-of-mind word vomit.
Our enterprise offering can either be self-hosted or it can leverage Payload Cloud, once we have it built. Some enterprises opt to manage Payload on their own infrastructure, and just pay us for SLA and premium features like SSO, audit logs, etc. But we do have enterprises in line to use our managed infrastructure as well... so basically, the answer is "both".
Does that help answer your questions?
- We are open source / MIT
- You can re-use Payload's auth layer in your own apps and with Contentful you can't
- Contentful has rigid RBAC, but Payload features function-based access control down to the field level
- Payload supports field conditional logic, meaning "check a checkbox, see more fields, uncheck it, extra fields disappear". This is huge. And is super hard to build right but it's very important for a good admin experience.
- Payload gives you a local Node API (note: not HTTP / REST / GraphQL.) Contentful does not. With Payload's local API, you can do lots of awesome things within hooks, access control, etc. - and even reuse it in your own endpoints. All of this is impossible with Contentful without going through their HTTP layer
- Payload lets you add your own admin UI views
- Payload has no usage limits
- Payload is code-first, Contentful is "point and click"
Phew. There's a lot more. This all is just top-of-mind word vomit.
Our enterprise offering can either be self-hosted or it can leverage Payload Cloud, once we have it built. Some enterprises opt to manage Payload on their own infrastructure, and just pay us for SLA and premium features like SSO, audit logs, etc. But we do have enterprises in line to use our managed infrastructure as well... so basically, the answer is "both".
Does that help answer your questions?
for what its worth - would take this "word vomit" and polish it up and post it somewhere. Coherence does a great job of this: https://docs.withcoherence.com/docs/coherence-vs-other-softw...
most people wont read it, but the serious people will. and better to claim your narrative than leave it in the hands of users who know less than you about your own market.
most people wont read it, but the serious people will. and better to claim your narrative than leave it in the hands of users who know less than you about your own market.
That is all useful info, thanks.
For the enterprise offering can you give a rough idea of pricing without having to book a demo etc.?
For the enterprise offering can you give a rough idea of pricing without having to book a demo etc.?
Yep! As our cloud hosting is not yet launched, we don't have the pricing finalized for that but for our enterprise features and SLAs, it's all broken down based on what you need. For 20 seats, a few enterprise features and a lower-tier SLA, you'd pay a few thousand a month.
For hundreds of seats, with a more robust SLA, your costs would scale linearly, but it's entirely based on what you need.
Does that help?
For hundreds of seats, with a more robust SLA, your costs would scale linearly, but it's entirely based on what you need.
Does that help?
I'm kind of curious what you mean by 'point and click' here? The contentful web interface is, of course, a web interface - but it's perfectly possible to interact with the API directly for people who want to do so.
We have a Next.js website with a blog section that's powered by Sanity. Problem is, it's pretty finicky to install basic components that we like to use (which looks like Payload comes with out of the box) + communicating with Sanity via groq is clunky with Typescript (and possibly causing some SEO issues).
How simple is it to install Payload in an existing Next.js app to power basically just the /blog/* subdirectory?
How simple is it to install Payload in an existing Next.js app to power basically just the /blog/* subdirectory?
Next.js works great with Payload. One cool feature of Payload is the Local API, which works awesome for server side rendered pages. You get your data from Payload right in your `getServerSideProps` functions.
You'd be interested in the example repo: https://github.com/payloadcms/nextjs-custom-server
The example is set up to manage Pages, but with a few tweaks you'd be able to manage blogs posts instead.
You'd be interested in the example repo: https://github.com/payloadcms/nextjs-custom-server
The example is set up to manage Pages, but with a few tweaks you'd be able to manage blogs posts instead.
Insanely simple. You can opt-in on a page by page basis with NextJS to any data source that you want to use. I LOVE NextJS' paradigms, and we've actually modeled a lot of what we do after its beautiful DX.
Great question!
Great question!
Hi! Knut from Sanity.io here.
Would love to learn more about:
* What you find finicky with installing basic components * What SEO issues that are connected to using GROQ/TypeScript
As far as I can gather from the docs, Payload doesn't come with more out-of-the-box components, and doesn't support custom blocks in the rich text editor, unless you commit to building the UI for it yourself?
Would love to learn more about:
* What you find finicky with installing basic components * What SEO issues that are connected to using GROQ/TypeScript
As far as I can gather from the docs, Payload doesn't come with more out-of-the-box components, and doesn't support custom blocks in the rich text editor, unless you commit to building the UI for it yourself?
1. Outstanding marketing site.
2. My initial thought was, "this looks fantastic… just as good as Sanity, which is a problem because Sanity is already around so what's the point? Really my only gripe with Sanity is that there's no free open sou—" oh dang, there it is.
Yeah, I will definitely give your product a shot on my next project.
2. My initial thought was, "this looks fantastic… just as good as Sanity, which is a problem because Sanity is already around so what's the point? Really my only gripe with Sanity is that there's no free open sou—" oh dang, there it is.
Yeah, I will definitely give your product a shot on my next project.
Yeah! The other big difference with Sanity is that the API side of Sanity is 3rd-party. So you never truly have control over the API logic or backend side at all. Whereas with Payload, you control both the admin UI AND the entirety of your API. That's what I mean by "closing the gap" between an app framework and a headless CMS. Lots more backend potential with Payload.
Knut from Sanity.io here. First of all, congrats on the launch and what seems to be a well done product!
And to be a bit nit-picky and to clarify our world-view: The API side of Sanity isn't 3rd-party (it's native to the platform), but it is hosted and propertary.
There are always trade-offs, so no, you don't get the kind of control you get when you host your own Express-server or sit on your own MongoDB instance, but then again, you don't have to do those things to have a scalable real-time document store that supports deeply nested document structures with queryable references (with referential integrity). We build our APIs specifically to improve developer experience where we take care of the hard parts™ so that you can focus on the productive things. All of our HTTP APIs are versioned, because we specifically want to avoid breaking changes as much as possible.
Furthermore, there are other things that you just get. Like GROQ which is way more expressive and flexible for querying data compared to GraphQL (which we also offer). You get on-demand image transforms. You get both content and assets behind a CDN. You have a mutation/patch API that can do transactions with pretty specific operations (“change only this value in an nested array for this key if it matches this value”). Since the backand has full attributed revision history, you can also have controls that prevents race conditions, so that you can programatically update documents even if people are editing them. You can define triggers for webhooks and its payload with GROQ, so you can use serverless functions (or a server) to update content based on conditions. You can hit the export API endpoint and get all of your stuff over a stream wherever you want it. And so on and so forth.
Of course, there are always use cases where you want a solution that can be run fully on-prem or specific bespoke behavior in the database/API-layer beyond the capabilities in the platform. If you need those things, then you should probably look elsewhere than Sanity.io, and Payload might be an excellent choice.
And to be a bit nit-picky and to clarify our world-view: The API side of Sanity isn't 3rd-party (it's native to the platform), but it is hosted and propertary.
There are always trade-offs, so no, you don't get the kind of control you get when you host your own Express-server or sit on your own MongoDB instance, but then again, you don't have to do those things to have a scalable real-time document store that supports deeply nested document structures with queryable references (with referential integrity). We build our APIs specifically to improve developer experience where we take care of the hard parts™ so that you can focus on the productive things. All of our HTTP APIs are versioned, because we specifically want to avoid breaking changes as much as possible.
Furthermore, there are other things that you just get. Like GROQ which is way more expressive and flexible for querying data compared to GraphQL (which we also offer). You get on-demand image transforms. You get both content and assets behind a CDN. You have a mutation/patch API that can do transactions with pretty specific operations (“change only this value in an nested array for this key if it matches this value”). Since the backand has full attributed revision history, you can also have controls that prevents race conditions, so that you can programatically update documents even if people are editing them. You can define triggers for webhooks and its payload with GROQ, so you can use serverless functions (or a server) to update content based on conditions. You can hit the export API endpoint and get all of your stuff over a stream wherever you want it. And so on and so forth.
Of course, there are always use cases where you want a solution that can be run fully on-prem or specific bespoke behavior in the database/API-layer beyond the capabilities in the platform. If you need those things, then you should probably look elsewhere than Sanity.io, and Payload might be an excellent choice.
any chance the website itself is open source? i'd love to see how Payload uses Payload.
Not yet. When we built the site, Payload's licensing and business model was built around a SaaS model, and was all baked into Payload's frontend. Of course, it does use Payload on the backend (including the entirety of our old SaaS billing infra) but for those reasons, we did not open-source it.
However, v2 is coming and that will 100% be open-source!
However, v2 is coming and that will 100% be open-source!
This is welcome, great launch James.
I'm constantly looking about for a new CMS system, either Strapi, Wordpress, etc, how does PayloadCMS compare to these?
What is PayloadCMS's killer feature?
I'm constantly looking about for a new CMS system, either Strapi, Wordpress, etc, how does PayloadCMS compare to these?
What is PayloadCMS's killer feature?
Thank you!
WP is a blogging platform from the early 2000's that still uses many of the same code conventions that it started with. It does have a REST API, and you can extend it with plugins to work as a headless CMS, but it's riddled with inefficiencies and is truly a great example of why most devs would not think to reach for a CMS if they were building a SaaS app. Can you build a SaaS app with WP? Sure. Should you? Absolutely not. WP is good for its plugins and themes, but for anything more robust, it falls apart.
Strapi is a contender that is quite similar to Payload but they have a mixed focus on "GUI-based" logic and code-based logic. You design your content models with a GUI, and access control is highly limited to a typical RBAC pattern. Where in Payload, everything -starts with code-. You can version control your schema, because it's all just a config. Deploy to other environments (stage, prod, etc) with ease. Use and re-use functions across different collections. Even access control is handled beautifully with functions in Payload, and is significantly more powerful than RBAC.
I'd say our killer feature though is the simplicity, yet robustness of our admin UI. We have many features that Strapi does not have - like field conditional logic (Check a checkbox field, see more fields. Uncheck checkbox, those fields go away). Our admin UI is also completely extensible. You can create custom field types easily just by importing React components and passing them to a field config - then boom, your React component appears in the admin UI rather than the built-in component. It's intensely powerful.
There's a lot more, but these are just a few quick points. I've been using headless WP for ~6 years, and I've always liked the idea of Strapi, but never trusted it enough to hit production. That's why we built Payload.
WP is a blogging platform from the early 2000's that still uses many of the same code conventions that it started with. It does have a REST API, and you can extend it with plugins to work as a headless CMS, but it's riddled with inefficiencies and is truly a great example of why most devs would not think to reach for a CMS if they were building a SaaS app. Can you build a SaaS app with WP? Sure. Should you? Absolutely not. WP is good for its plugins and themes, but for anything more robust, it falls apart.
Strapi is a contender that is quite similar to Payload but they have a mixed focus on "GUI-based" logic and code-based logic. You design your content models with a GUI, and access control is highly limited to a typical RBAC pattern. Where in Payload, everything -starts with code-. You can version control your schema, because it's all just a config. Deploy to other environments (stage, prod, etc) with ease. Use and re-use functions across different collections. Even access control is handled beautifully with functions in Payload, and is significantly more powerful than RBAC.
I'd say our killer feature though is the simplicity, yet robustness of our admin UI. We have many features that Strapi does not have - like field conditional logic (Check a checkbox field, see more fields. Uncheck checkbox, those fields go away). Our admin UI is also completely extensible. You can create custom field types easily just by importing React components and passing them to a field config - then boom, your React component appears in the admin UI rather than the built-in component. It's intensely powerful.
There's a lot more, but these are just a few quick points. I've been using headless WP for ~6 years, and I've always liked the idea of Strapi, but never trusted it enough to hit production. That's why we built Payload.
What you describe sounds similar to Statamic. The config and even the content is yaml files, and the admin UI is also quite extensible. But I always wish it was easier to change stuff with code in Statamic, so maybe that's where Payload shines.
Nailed it.
Payload's config is straight up TypeScript. Import a React component, pass it to your config, and boom — it shows up in your admin UI.
Everything is written like that and this is certainly where we shine!
Payload's config is straight up TypeScript. Import a React component, pass it to your config, and boom — it shows up in your admin UI.
Everything is written like that and this is certainly where we shine!
[deleted]
Hi James,
I'm really excited about V1 release of Payload, as well as the open sourcing of the project. I've wanted to use it in a project for a while and this news is definitely going to push me over the edge. I'm a huge fan of the typescript first approach, as well as local mode, and the thought that went into adding custom blocks and components.
I'm really excited about V1 release of Payload, as well as the open sourcing of the project. I've wanted to use it in a project for a while and this news is definitely going to push me over the edge. I'm a huge fan of the typescript first approach, as well as local mode, and the thought that went into adding custom blocks and components.
Ahh thank you! You cherry-picked my favorite parts about Payload. So much went into having a proper custom block-based field type. That in specific is something that every single project I build has always needed and this is only the start. We have a lot of ideas that are going to take our blocks field to the next level.
Congratulations and great idea! What's your roadmap or appetite for pay-for-features? For example, what would be involved in hiring your team to improve a specific area or two?
This is hugely important to us. For features that belong in the core, we point people to GitHub Discussions (https://github.com/payloadcms/payload/discussions) and more often than not, we are pretty fast to green light / build certain features for free. Our community has also been straight up amazing in this regard.
But if you've got something more significant that you'd like a hand with, we'd be happy to chat. Sounds great!
But if you've got something more significant that you'd like a hand with, we'd be happy to chat. Sounds great!
Great site and product. How will you monetize this? An obvious way is to offer a hosted version of the product on a subscription basis, but that doesn't seem to be possible in this case considering the whole value prop is to embed this in your own server.
In my original post, I've outlined our monetization strategy at a high level. And cloud hosting is certainly an aspect of our approach.
It's true that some will self-host Payload, and that's awesome. But look at NextJS - you can self-host NextJS as well, but most people go to Vercel. Hosting a CMS is quite a bit more complicated than a static site or a set of serverless functions, because you need to have a database and permanent file storage as well. Payload will provide all of that out of the box with a one-click Git integration.
Our users thus far have been telling us that they struggle with cobbling together vendors and wish that this was easier, so we're building Payload Cloud as a result.
One other aspect of Payload Cloud is that even though we -provision- the infrastructure for you, you'll always have access to it. You'll be able to connect to your DB, back it up, export it, etc. This is all in the works now!
It's true that some will self-host Payload, and that's awesome. But look at NextJS - you can self-host NextJS as well, but most people go to Vercel. Hosting a CMS is quite a bit more complicated than a static site or a set of serverless functions, because you need to have a database and permanent file storage as well. Payload will provide all of that out of the box with a one-click Git integration.
Our users thus far have been telling us that they struggle with cobbling together vendors and wish that this was easier, so we're building Payload Cloud as a result.
One other aspect of Payload Cloud is that even though we -provision- the infrastructure for you, you'll always have access to it. You'll be able to connect to your DB, back it up, export it, etc. This is all in the works now!
Congrats on the launch. I saw payload here on HN a few months ago. Good seeing it again.
On the "Enterprise" sso approach, are your first party offerings just plugins? I've worked with various node cms recently, and for our needs we often see the only way to extend is by dangerously forking the upstream rather than hooking in through the plugin architecture.
The second aspect I wondered about, is why Mongo? It doesn't seem as "open" compared to a postgres, although maybe works better for your hosting platform offering. I wonder if an adapter to pg/json might be possible.
Thanks, and good luck with launch!
On the "Enterprise" sso approach, are your first party offerings just plugins? I've worked with various node cms recently, and for our needs we often see the only way to extend is by dangerously forking the upstream rather than hooking in through the plugin architecture.
The second aspect I wondered about, is why Mongo? It doesn't seem as "open" compared to a postgres, although maybe works better for your hosting platform offering. I wonder if an adapter to pg/json might be possible.
Thanks, and good luck with launch!
Thank you!
Yes, all of our first-party offerings are plugins and 100% of their functionality can be accomplished with Payload core itself. No need to fork or extend. Our plugin infrastructure runs incredibly deep and it's super straightforward.
Mongo was extremely deliberate. The nature of "content", especially pages and posts, lends itself extremely well to the document-based structure of NoSQL. Add in complex field types like arrays, a block-based layout builder, groups, and more, and this becomes even more apparent. But this all being said, supporting Postgres is on our radar and will be happening at some point. Our internal infrastructure is already quite organized and swapping out a different database adapter won't be a monumental task. It'll require some work, for sure, but it's doable.
Thank you for the great questions!
Yes, all of our first-party offerings are plugins and 100% of their functionality can be accomplished with Payload core itself. No need to fork or extend. Our plugin infrastructure runs incredibly deep and it's super straightforward.
Mongo was extremely deliberate. The nature of "content", especially pages and posts, lends itself extremely well to the document-based structure of NoSQL. Add in complex field types like arrays, a block-based layout builder, groups, and more, and this becomes even more apparent. But this all being said, supporting Postgres is on our radar and will be happening at some point. Our internal infrastructure is already quite organized and swapping out a different database adapter won't be a monumental task. It'll require some work, for sure, but it's doable.
Thank you for the great questions!
Congrats on the launch. Always wanted something like this to be able to build a more opinionated CMS on top of it for all my projects. My first try was Qards (https://www.qards.io/) but the npm, exhaustingly breaking changes from js libraries + the painful experience I've had dealing with & integrating Netlify CMS into it just left me dry by the time I've actually launched. Was a cool project though and I'm thinking of reviving it one day, maybe with Payload.
Oh I can intrinsically relate to what you're saying. I would love to see your project revived on Payload. If you need a hand, please do reach out on Discord!
Guys, amazing work you're doing with Payload. I think it's pushing the way we build apps forward.
I love the energy, but you should communicate more sincerely. In your intro video you say "frameworks like Laravel and Rails can be great on building the back-end of your complex apps, but then you're stuck having to build the entirety of your admin panel completely by yourself", and that's untrue. There are solutions out there that help you not build it by yourself.
Again, great energy, but don't lie!
Again, great energy, but don't lie!
I've explored the options in Laravel and did an entire project with Nova. Based on that, it wasn't as straightforward of an experience as I would have wanted. You still have to learn the ins-and-outs of the framework and then also still define your editor experience.
I haven't done the same exploration for Rails gems. I'd be curious, which have you have used that take care of the CMS and admin panel requirements?
I haven't done the same exploration for Rails gems. I'd be curious, which have you have used that take care of the CMS and admin panel requirements?
You still have to learn the "ins-and-outs" of Payload also for this to work so what's your point? Based on my experience with npm based projects, I bet you x,xxx dollars that even an npm install will start vomiting 3 months after you finished your project. This ecosystem is cancer and I blame designers trying to do programming work because...it's javascript, what can go wrong? Everything seems like a complete hack in this space. Tools are built based on unicorns and rainbows and not logic, maintenance and backwards compatibility.
Do a project now and come back 3 months later and update it to latest versions to see what happens. Compare that with a Django app + django admin afterwards.
Do a project now and come back 3 months later and update it to latest versions to see what happens. Compare that with a Django app + django admin afterwards.
I totally hear what you're saying. One thing I can say extremely confidently is that while my agency was eating our own dogfood with Payload during 2020/2021, we released some large projects on Payload and have kept Payload updated in all of those projects since. It's been seamless. A large focus of ours since the beginning was to identify an API that could reduce breaking changes to an absolute minimum and to restrict the use of other packages wherever possible, to avoid the NPM whirlwind. Our config-based approach has delivered exactly that. All of our projects, and our customers' projects, built even before beta release have been updated without issue. But this is certainly systemic to NPM and especially if you look at packages that are of lesser quality. That's the classic downside to the way that the JS ecosystem does things - it's basically open-ended at every turn. Even with React. But I am very confident, having had experiences very similar to yours, that it's handled quite effectively with Payload.
On another note, one of our goals with Payload was to rigorously minimize the amount of learning that you have to do to get up and running with Payload's specific conventions. This was a huge requirement of ours while we designed our initial API. We've always _hated_ having to learn the intricacies of another platform like Drupal or WordPress before being able to be proficient in those systems. It's like you have to get a degree in the CMS before you can use it rather than sharpening your skill set with the underlying language.
Payload's conventions are quite flat and are all config-based. From there, you write your own code to do whatever you want in the conventions that you're used to.
On another note, one of our goals with Payload was to rigorously minimize the amount of learning that you have to do to get up and running with Payload's specific conventions. This was a huge requirement of ours while we designed our initial API. We've always _hated_ having to learn the intricacies of another platform like Drupal or WordPress before being able to be proficient in those systems. It's like you have to get a degree in the CMS before you can use it rather than sharpening your skill set with the underlying language.
Payload's conventions are quite flat and are all config-based. From there, you write your own code to do whatever you want in the conventions that you're used to.
Looks like an interesting idea. Other than PHP-hate, why would someone choose this over something like Drupal?
Drupal is obviously one of the longest-running content management systems available and they have done a much better job at keeping up with the moving target that is tech, when compared to Joomla / WP.
Outside of being written in TypeScript with more modern conventions, the fact that Payload borders on an application framework is what would make someone choose it over something like Drupal.
Feature-wise, this commonly means reusing Payload's auth in your own app(s), defining function-based access control rather than RBAC, swapping in React components into the admin UI, and more.
But another HUGE reason is that when we built Payload, we tried to keep its own internal conventions as close as possible to just regular JS / TS. If you know JS, you know Payload. With Drupal and even WP to an extent, you need to know how _their_ conventions work. It's all very specific to the platform and the Payload team has always hated that. Devs don't want to learn CMS - they want to learn the underlying language, and Payload embraces that to its core.
Outside of being written in TypeScript with more modern conventions, the fact that Payload borders on an application framework is what would make someone choose it over something like Drupal.
Feature-wise, this commonly means reusing Payload's auth in your own app(s), defining function-based access control rather than RBAC, swapping in React components into the admin UI, and more.
But another HUGE reason is that when we built Payload, we tried to keep its own internal conventions as close as possible to just regular JS / TS. If you know JS, you know Payload. With Drupal and even WP to an extent, you need to know how _their_ conventions work. It's all very specific to the platform and the Payload team has always hated that. Devs don't want to learn CMS - they want to learn the underlying language, and Payload embraces that to its core.
Personal opinion: Even as someone who used and loved PHP for a decade, Drupal is just awful. It's overengineered and bloated and the documentation is pretty sparse, not to mention it's hard to scale up. Its admin and editor UX is decades being modern headless CMSes. It is extremely powerful, but seemingly built to handle the most extreme edge cases rather than the most common use cases, and a lot of the power is just confusing and unnecessary for your typical website. In like 10% of the time it takes to get a Drupal system up and running well, you can do the same thing with Wordpress and Advanced Custom Forms and end up with an infinitely better UX, DX, and EX.
Drupal suffers tremendously from "by engineers, for engineers" and it's just an incredibly poor experience if you don't fit that mold. It's non-stop pain for no reward.
Having used it for a major project (both in daily use and in a big migration from D7 to D8/9), I will NEVER take another job that uses Drupal again... it is the second most dreaded web framework for a reason (above only Angular): https://survey.stackoverflow.co/2022/#section-most-loved-dre...
Halfway through our Drupal "upgrade" (rewrite, because D7 had no upgrade path), we just gave up on it and went to Next.js + a headless CMS instead. Everyone was massively happier after that... the devs, the editors, IT, marketing, content writers, analytics... Drupal was just soooo bad that even its newest version was years if not decades behind modern experiences.
Sorry I feel so strongly about this... the mere word makes my blood boil. I've never HATED a technology the way I hate Drupal, before or since. If you're considering it for a project for the first time, don't walk, SPRINT as far away as it as you possibly could.
Drupal suffers tremendously from "by engineers, for engineers" and it's just an incredibly poor experience if you don't fit that mold. It's non-stop pain for no reward.
Having used it for a major project (both in daily use and in a big migration from D7 to D8/9), I will NEVER take another job that uses Drupal again... it is the second most dreaded web framework for a reason (above only Angular): https://survey.stackoverflow.co/2022/#section-most-loved-dre...
Halfway through our Drupal "upgrade" (rewrite, because D7 had no upgrade path), we just gave up on it and went to Next.js + a headless CMS instead. Everyone was massively happier after that... the devs, the editors, IT, marketing, content writers, analytics... Drupal was just soooo bad that even its newest version was years if not decades behind modern experiences.
Sorry I feel so strongly about this... the mere word makes my blood boil. I've never HATED a technology the way I hate Drupal, before or since. If you're considering it for a project for the first time, don't walk, SPRINT as far away as it as you possibly could.
You're not alone.
I ran a team at a weekend hackathon event for non-profits. We needed to finish building their new site on the latest version of Drupal. I had SEVEN devs working on a 5 page brochure site with a page to manage events and we couldn't get it done! I felt terrible leaving it incomplete at the event, but honestly, with Drupal as the tech stack—my hands were tied. Luckily the developer who started the work was able to finish it a few months later.
To do it all over again, I would have convinced them to throw away what they had and use a different platform. If we used any other tech stack, we could have finished and launched the site during the event.
That was the first, and last time I touched Drupal.
I ran a team at a weekend hackathon event for non-profits. We needed to finish building their new site on the latest version of Drupal. I had SEVEN devs working on a 5 page brochure site with a page to manage events and we couldn't get it done! I felt terrible leaving it incomplete at the event, but honestly, with Drupal as the tech stack—my hands were tied. Luckily the developer who started the work was able to finish it a few months later.
To do it all over again, I would have convinced them to throw away what they had and use a different platform. If we used any other tech stack, we could have finished and launched the site during the event.
That was the first, and last time I touched Drupal.
Wow. I was seriously considering Drupal as an option for an lod-style minimal-JS site (with mainly news+comments, gallery, wiki, statistics and stuff). Previous CMS I used was quite allright, but maintainers dropped it :( Can you suggest something besides Dripal and WP? (pls not JS)
What is lod? If you limit yourself to non JS, do you care what language the CMS is written in? Does it have to have all the features built in or just support plug-ins? Self hosted or vendor hosted in the cloud?
Sorry, I was typing "old" :) And yes, I care about language to be able to support it and manage resources (PHP, CPP is fine). Self-hosted, bare metal. I used PostNuke-based CMS (LAMP) and was very satisfied with it. I was also thinking about basing site on nextcloud (I tried it for storage for friends, would be nice to integrate it with CMS), but it's a huge thing in itself I don't really know how to approach )
Oh wow, when you said old, you really meant it lol. Haven't heard of the Nukes in decades now.
Honestly, I hate to say this, but if you really want that level of server-side all in one power... maybe Drupal IS worth considering after all. Most modern sites aren't built that way anymore, instead opting to compose a site out of many services (eg a CMS for marketing pages, Discourse for a forum, an auth provider linking them all together, etc.)
A monolithic community on a single engine is in fact the kind of (rare) use case that Drupal actually fits... making its complexity possibly worthwhile. It's just overkill for most sites that aren't like that.
WordPress might also be able to get there eventually, with a lot of plug-ins, but at that point it would be so bloated that Drupal might actually be cleaner. Might also be worth checking to see if any of the older PHP CMSes (Joomla, etc.) are still being maintained.
Sorry, I haven't looked at this sort of use in years and wouldn't be able to provide more details than that :/
Honestly, I hate to say this, but if you really want that level of server-side all in one power... maybe Drupal IS worth considering after all. Most modern sites aren't built that way anymore, instead opting to compose a site out of many services (eg a CMS for marketing pages, Discourse for a forum, an auth provider linking them all together, etc.)
A monolithic community on a single engine is in fact the kind of (rare) use case that Drupal actually fits... making its complexity possibly worthwhile. It's just overkill for most sites that aren't like that.
WordPress might also be able to get there eventually, with a lot of plug-ins, but at that point it would be so bloated that Drupal might actually be cleaner. Might also be worth checking to see if any of the older PHP CMSes (Joomla, etc.) are still being maintained.
Sorry, I haven't looked at this sort of use in years and wouldn't be able to provide more details than that :/
I see the value in this product, and I agree that for developers it’s boring to build CMS, that’s why me and my team have been shopping around for a solution to give marketers and sales a tool which could give them autonomy, we picked contentful a couple of weeks ago as no one wanted to be on call for hosting issues, so it’s a shame, I wished you could’ve launched few weeks ago but now we’ve already started developing it after pitching it to stakeholders and getting the budget approved, good luck for your success
Awww dang! Sorry to have missed you. I've used Contentful in a handful of projects in the past and our team's struggles were partially responsible for the creation of Payload. Keep us in mind for your next project - and best of luck!
> Imagine you're going to build a new SaaS app. Would you think of building it on a headless CMS?
I'm guessing this mostly makes sense for a SaaS that's mostly about serving content to users. I wonder how common that kind of SaaS is, as opposed to a SaaS where the core functionality wouldn't be served well by a CMS, and the administrative tedium that one wants to alleviate mostly has to do with account management, payment processing, enabling or disabling service based on billing status, etc.
I'm guessing this mostly makes sense for a SaaS that's mostly about serving content to users. I wonder how common that kind of SaaS is, as opposed to a SaaS where the core functionality wouldn't be served well by a CMS, and the administrative tedium that one wants to alleviate mostly has to do with account management, payment processing, enabling or disabling service based on billing status, etc.
The point here is that it isn't just a tool for content. The way I see things, there is no useful distinction between content and any other kind of data. Payload makes it trivial to set up custom data structures and manage it.
The tedium of development in my experience is building CRUD—whether it is for a SaaS app or anything else. When you're rolling a project using a framework you've got to set up a database, write the API logic and build an admin UI to manage that data. It is complicated and time consuming work even with a great framework. To be able to skip all that is a massive advantage.
I personally would not build a SaaS app on Wordpress and ACF, but I would use Payload to build just about any custom business app.
The tedium of development in my experience is building CRUD—whether it is for a SaaS app or anything else. When you're rolling a project using a framework you've got to set up a database, write the API logic and build an admin UI to manage that data. It is complicated and time consuming work even with a great framework. To be able to skip all that is a massive advantage.
I personally would not build a SaaS app on Wordpress and ACF, but I would use Payload to build just about any custom business app.
Congrats on the launch! Great to see more forward-thinking CMS solutions hitting the market.
We've been using Statamic[1] (built on Laravel) which is also a package that's sits atop the framework so you can build your app how you like and side-load CMS features.
It also features an API. The whole platform is steadily improving despite being a small bootstrapped team behind it.
If you're looking for something like Payload but for Laravel, give Statamic a go!
[1]: https://statamic.com
We've been using Statamic[1] (built on Laravel) which is also a package that's sits atop the framework so you can build your app how you like and side-load CMS features.
It also features an API. The whole platform is steadily improving despite being a small bootstrapped team behind it.
If you're looking for something like Payload but for Laravel, give Statamic a go!
[1]: https://statamic.com
I've heard good things about statamic also. How do you feel about their pricing model?
You should try to get listed on awesome-cms [1] list now too, since you're out with public release. That was the first place I checked for options last time I needed to find a headless CMS.
[1] https://github.com/postlight/awesome-cms
[1] https://github.com/postlight/awesome-cms
Absolutely! Thanks for linking this.
How does this compare to KeystoneJS, another TypeScript CMS? https://keystonejs.com/
I've been using keystone to run a small coffee roasting operation. The underlying concept (primsa + graphql + custom crud hooks + ootb ui) makes it incredible easily to model and build businesses processes.
Only compliant is that the admin UI isn't that flexible or extendable. You eventually end up rewriting standard views entirely when you need to add additional features that ideally would have just been minor extensions (eg adding a custom action to a record page)
Only compliant is that the admin UI isn't that flexible or extendable. You eventually end up rewriting standard views entirely when you need to add additional features that ideally would have just been minor extensions (eg adding a custom action to a record page)
This looks great! We use Strapi for our marketing site at https://articleasset.com and have been bitten by the lack of conditional logic before.
Is there any plan to support serverless deployment? We use Nextjs with incremental static regeneration, so will only need to query the cms service a couple times a day.
Is there any plan to support serverless deployment? We use Nextjs with incremental static regeneration, so will only need to query the cms service a couple times a day.
Serverless has been asked for quite a few times and we've gone back and forth on it. We want to keep an open mind, but the business case to build it isn't there at the moment. That could change if somebody wants to sponsor that development or some OS devs open a PR or build some porting plugins.
It could simplify deployment and have some other benefits, but we always go back to the fact that even with a sleak serverless architecture, you're still hitting a centralized DB. It really weakens the argument for going serverless.
It could simplify deployment and have some other benefits, but we always go back to the fact that even with a sleak serverless architecture, you're still hitting a centralized DB. It really weakens the argument for going serverless.
Depending on the startup time, you can use something like AWS Serverless Express and just wrap the application. If startup takes a little while you can store an instance above the handler code which will be kept alive across invocations of that serverless instance.
I've used this to great success in a similar project.
I've used this to great success in a similar project.
Understandable. Appreciate that you all have a monetization strategy already. One of my hesitations with adopting VC-backed open source projects is that a lot of them don’t have a clear business model.
We host Strapi on a server, so shouldn’t be a problem.
We host Strapi on a server, so shouldn’t be a problem.
Looks great! I've been looking to avoid rolling my own admin for my hobby project, which is mongo based, and very much driven on certain db schemas and collections. Adding CRUD and simple admin views to the mongodb will go a really long way, and the flex to throw in some react sounds great. Glad i found this!
Awesome, sounds like the perfect fit for your project!
Nit, but, "The most powerful TypeScript headless CMS there is."
Should be
"The most powerful headless CMS for TypeScript"
Or something to that effect. The first time I read the headline, I thought "there is" was preparing for a followup sentence.
Should be
"The most powerful headless CMS for TypeScript"
Or something to that effect. The first time I read the headline, I thought "there is" was preparing for a followup sentence.
Fair enough. That whole headline needs to be rewritten IMO. Describing Payload in one sentence is super tricky and feels like buzzword soup.
We're on it. Actually I think the whole site needs to be redone but I'm never happy with my own work.
We're on it. Actually I think the whole site needs to be redone but I'm never happy with my own work.
Hi James, congratulations on the launch!
The website looks great, your pitch is compelling and the vision is very similar to what I've been doing with vendure.io, which takes the same approach but towards ecommerce rather than CMS. Namely: open-source, headless, Node/TypeScript, dev- and code-first.
In our experience, your thesis is correct in that there certainly is a niche for a great, dev-first, self hosted version of what is otherwise seemingly already handled by SaaS products. We see users moving to Vendure from closed SaaS commerce platforms for reasons like: full control over the code & data, integration requirements, need to support unique requirements, wanting to build their own platform etc.
Furthermore our business model is similar - MIT core and paid enterprise plugins, and exploring cloud. Notably enterprise support and SLAs is also becoming a major area for us.
So it's great to see a kindred product getting some attention here on HN!
If you are interested to swap insights or discuss potential collaboration (many of our users are looking for a good CMS...) feel free to drop me a message at m.bromley at vendure.io :)
The website looks great, your pitch is compelling and the vision is very similar to what I've been doing with vendure.io, which takes the same approach but towards ecommerce rather than CMS. Namely: open-source, headless, Node/TypeScript, dev- and code-first.
In our experience, your thesis is correct in that there certainly is a niche for a great, dev-first, self hosted version of what is otherwise seemingly already handled by SaaS products. We see users moving to Vendure from closed SaaS commerce platforms for reasons like: full control over the code & data, integration requirements, need to support unique requirements, wanting to build their own platform etc.
Furthermore our business model is similar - MIT core and paid enterprise plugins, and exploring cloud. Notably enterprise support and SLAs is also becoming a major area for us.
So it's great to see a kindred product getting some attention here on HN!
If you are interested to swap insights or discuss potential collaboration (many of our users are looking for a good CMS...) feel free to drop me a message at m.bromley at vendure.io :)
Ah awesome! Thanks for the comment! I'd absolutely like to trade experiences sometime. I will certainly send you a message.
Looking forward to it!
Looking forward to it!
I just evaluated all the javascript headless CMS just last week and my conclusion is that the best offering in this space is probably directus. Maybe I'll do a writeup when my directus app gets up and running.
Yeah - Directus certainly provides a lot of value out of the box. We're a bit more razor-focused on a code-first approach vs. Directus, as the content model is stored directly in the database rather than being defined in a version-controlled schema. And in Payload it's much easier to swap in your own React components / customize the admin UI. But we really respect the Directus team for sure!
Nice.
A page comparing this with existing solutions would be useful. In particular how does it compare to something like Wagtail which is a CMS but also has all of Django to fall back on for custom backend work.
Hey there - we do have a set of comparisons on our site (linked in the footer of the site), but we don't have a comparison to Wagtail yet. Would be happy to add this to the list!
I’d be really interested in this as well (disc. – I work on Wagtail). This feels so similar to our vision for the CMS aside for the fact the project has been running for a while and is in Python land.
This is great, I can stop emailing markdown files back and forth with my content writers.
Would this work as a sort-of wiki, for crowd-sourced documentation and translations? Or is it a bad idea to let the public edit things?
Would this work as a sort-of wiki, for crowd-sourced documentation and translations? Or is it a bad idea to let the public edit things?
You can absolutely do this. You can bake in any type of "review" workflow you can think of, and Payload comes with versions / drafts out of the box as well. It's easy to control who can update the "main" published doc, vs. who can submit drafts.
Would love to see if you gave this a shot, and we'd be happy to help along the way on Discord!
Would love to see if you gave this a shot, and we'd be happy to help along the way on Discord!
Wonderful! What a great product, well done. Thanks.
Question: How are migrations handled? Can I rename fields without losing my data? Can I change a relation without losing the underlying data? Are there other edgecases where I lose my data?
Thanks to using MongoDB as a database layer, you will not lose your data if you rename fields. This is a huge benefit for NoSQL in general honestly and it is one of the reasons why we chose to move forward with Mongo initially. We will be supporting Postgres + others in the future, at which point we will be introducing a migrations pattern, but for now, you don't need to worry about that at all.
With Payload as it stands now, to migrate data from one field to another, you can make use of Payload's Local Node API to move data from one property to another with ease.
With Payload as it stands now, to migrate data from one field to another, you can make use of Payload's Local Node API to move data from one property to another with ease.
Looking forward to a replacement for https://www.netlifycms.org/
Yeah! We've had a lot of people move to Payload from Netlify CMS. Those that have moved have given us a ton of great feedback in regards to our UX and dev experience comparatively.
In my previous job we struggled to get a CMS for our app: it was a medical app with articles embedded in it, and we wanted a way to have doctors and translators work independently in a CMS environment, with the final product being released in the normal way.
We never found anything that would have done the CI automation we wanted, or not without significant customisation. Do you support CI workflows at all?
We never found anything that would have done the CI automation we wanted, or not without significant customisation. Do you support CI workflows at all?
Just about anything CI-wise you can think of is completely doable with Payload. That's the beauty of being staunchly code-first.
I would love to hear more about this at some point too, btw.
I would love to hear more about this at some point too, btw.
Sure :-) I've moved on to another company, so I will need to have a think and remember what the difficulties were.
Congrats on the launch.
What is the difference between this, and say a customized vBulletin et al.? (or, did I misunderstand what the offer is?)
What is the difference between this, and say a customized vBulletin et al.? (or, did I misunderstand what the offer is?)
Well, at its core, Payload is a headless CMS / application framework. There are actually quite a few differences between either of those and a forum software like vBulletin which is deliberately geared toward creating online communities (moderation, comments, threads, etc.)
Payload could power the same use cases as something like vBulletin, but its use cases are significantly more widely applicable because Payload is not geared solely toward being community software. Instead, Payload delivers a content API and admin UI to power / manage just about any type of digital product you can think of, ranging from enterprise marketing websites, to native apps, to omni-channel content (think Spotify music), to SaaS app backends, to video games. Of course, forums are included here.
Does that help clarify?
Payload could power the same use cases as something like vBulletin, but its use cases are significantly more widely applicable because Payload is not geared solely toward being community software. Instead, Payload delivers a content API and admin UI to power / manage just about any type of digital product you can think of, ranging from enterprise marketing websites, to native apps, to omni-channel content (think Spotify music), to SaaS app backends, to video games. Of course, forums are included here.
Does that help clarify?
Congratulations!
> To devs, "content management system" is usually a swear word.
Yet "CMS" is in your tag line. Is that not a bad idea then?
> To devs, "content management system" is usually a swear word.
Yet "CMS" is in your tag line. Is that not a bad idea then?
I lolled at this - gonna cause me to do some introspection, huh.
One goal of ours is to make this not the case - but you are 100% right. The whole notion of "app framework / headless CMS" doesn't have a good label so right now we've gotta make some concessions. We have this discussion quite often!
One goal of ours is to make this not the case - but you are 100% right. The whole notion of "app framework / headless CMS" doesn't have a good label so right now we've gotta make some concessions. We have this discussion quite often!
Great writeup; bookmarked, will revisit soon.
Thank you! We would love to help support you in your first Payload project if you need a hand. We're super active on Discord. Stop by if you need anything!
I think that we do need more CMS. However, I was really put off by the homepage. It's very hard to figure out what really differentiates you from others, the interface is very hard to go through with all of the scrolling left / right. Based on the responses here it seems open source?
Thanks for the feedback! Our website has changed minimally since launch. In about a month or so, our focus will be shifting back toward sharpening our messaging and presence online.
Yes—as you mentioned, Payload is self-hosted, open-source, natively TypeScript and extremely extensible both on the API and admin UI sides. Outside of specific features that we support and others do not, those are the big differentiators. But there are lots more!
Yes—as you mentioned, Payload is self-hosted, open-source, natively TypeScript and extremely extensible both on the API and admin UI sides. Outside of specific features that we support and others do not, those are the big differentiators. But there are lots more!
Similar to https://pocketbase.io ?
Yep, but with a lot more admin-specific features like field conditional logic, block-based layout editors, customizable React components, localization, versions / diffs / drafts / preview / autosave, etc. Payload ships with way more than just a CRUD UI!
Currently working on some SaaS, so I'd like to take a look at this and see if it fits.
Curious if there are multi-tenancy features baked in, since you mentioned targeting SaaS companies? Really happy to see all the recent innovation in this space, congrats on the launch :)
Curious if there are multi-tenancy features baked in, since you mentioned targeting SaaS companies? Really happy to see all the recent innovation in this space, congrats on the launch :)
For example, can the cloud version do sub-tenants? Is the admin panel exposable to end-users? That sort of thing
Yes! You can absolutely do both sub-tenant / multi-tenant architecture and you can definitely expose the admin panel to end-users.
Both are possible. Thank you for your kind words!
Both are possible. Thank you for your kind words!
One more question: is support for non-node environments on the way? We use a bit of node but we're mostly JVM. Kotlin would be clutch, all good if it's not yet in the cards.
I love it. Congrats for launching!
As a developer I'd never use this. I don't want to learn the thought process of someone else just to get some work done, I can do it myself. If I want a headless CMS there are plenty of options out there.
Was a complete turned off by the original monetization model, what has changed?
Sharp eye - we threw it away and went MIT a few months ago! Basically.... we listened to our audience. And it was a great move. So, thank you for giving us the push if you commented or provided feedback in any way!
That's great to hear!
Seriously, it's liberating to -say-. We're so happy with the move. Credit to the community.
Looks great. Lots of little "nice to have"s all over the place, and the latency is pretty snappy. Not the way I'm interested in doing my content these days but I can see the appeal for sure.
good job
good job
Thank you! Yep, the fact that we ate our own dogfood for over a year really helped us fill in the "nice to haves" all over the place.
How do you do your content nowadays? Git-based CMS? Markdown? Would love to know!
How do you do your content nowadays? Git-based CMS? Markdown? Would love to know!
I know that a lot of web frameworks already have admin panels available either released by the main development team or by a 3rd party. What is the advantage of using Payload over those?
Hi! I'm Dan, Payload co-founder.
Prior to building Payload I was a consulting full-stack engineer. I have built large web apps using Laravel and have rolled my own admin UI a dozen times and I've worked within the official 'Nova' package too. Laravel had a few open source options which I didn't try as it seemed like support was better with Nova. The project I built went okay, but it was a ton of work over what you can do with Payload.
To add a field you have to: 1) create a migration to add a column to the DB 2) add your field to the model 3) define the field again in the nova "resource"
In Payload you do all of this in one place. Every field you define will have the proper DB schema, API and admin UI in a streamlined way without having to touch your app in a bunch of places.
Two other things that made me scratch my head while using Nova specifically. The first, I had to cobble together plugins for building blocks for component based field defintions and image uploads, but these didn't play well together at all. How could image uploads and blocks not be built-in core features? The other pain point with Nova is that it isn't refined at all, and they say it shouldn't be used for customer facing UIs.
Do you have a favorite framework/package you would suggest for mananging admin UIs and APIs that do a great job?
Prior to building Payload I was a consulting full-stack engineer. I have built large web apps using Laravel and have rolled my own admin UI a dozen times and I've worked within the official 'Nova' package too. Laravel had a few open source options which I didn't try as it seemed like support was better with Nova. The project I built went okay, but it was a ton of work over what you can do with Payload.
To add a field you have to: 1) create a migration to add a column to the DB 2) add your field to the model 3) define the field again in the nova "resource"
In Payload you do all of this in one place. Every field you define will have the proper DB schema, API and admin UI in a streamlined way without having to touch your app in a bunch of places.
Two other things that made me scratch my head while using Nova specifically. The first, I had to cobble together plugins for building blocks for component based field defintions and image uploads, but these didn't play well together at all. How could image uploads and blocks not be built-in core features? The other pain point with Nova is that it isn't refined at all, and they say it shouldn't be used for customer facing UIs.
Do you have a favorite framework/package you would suggest for mananging admin UIs and APIs that do a great job?
Elliot from Payload here. In addition to Dan's comments above, the main advantage of using Payload's Admin is that it can integrate directly with your auth as well as offer a richer editing experience beyond the normal CRUD that others provide.
For instance:
- Field-based access control - This allows a developer to use code to write complex functions in order to regular access to a field. This can also reference the currently logged in user's permissions/fields etc.
- Conditional logic - Functions can be written to show/hide certain fields in the admin UI
- Dynamic field types - Complex layouts can be built with the Block and Array field types. This allows the ability to build out more of a "page builder" type input vs. simple CRUD.
I hope that answers your question. Here are some links to the docs on each of those:
- https://payloadcms.com/docs/access-control/overview
- https://payloadcms.com/docs/fields/overview#conditional-logi...
- https://payloadcms.com/docs/fields/blocks
For instance:
- Field-based access control - This allows a developer to use code to write complex functions in order to regular access to a field. This can also reference the currently logged in user's permissions/fields etc.
- Conditional logic - Functions can be written to show/hide certain fields in the admin UI
- Dynamic field types - Complex layouts can be built with the Block and Array field types. This allows the ability to build out more of a "page builder" type input vs. simple CRUD.
I hope that answers your question. Here are some links to the docs on each of those:
- https://payloadcms.com/docs/access-control/overview
- https://payloadcms.com/docs/fields/overview#conditional-logi...
- https://payloadcms.com/docs/fields/blocks
It looks awesome, I will give it a try.
There's a loot of CMSs already, but the quality open-source ones is usually.. lacking. A high quality one with great DX has a huge potential
There's a loot of CMSs already, but the quality open-source ones is usually.. lacking. A high quality one with great DX has a huge potential
Thank you! I totally agree. I've been using headless CMS since the start and have ridden along with a few of the options out there, but never trusted them enough to hit production.
Congrats @sneek_ and team, looking forward to sparring with you some more!
February 37nd, 2022? [1]
When did they add so many more days in February?
[1] https://payloadcms.com/
[1] https://payloadcms.com/
I assume they are using date-fns - Saw this bug in that lib once when doing a demo and it was really embarrassing.
You would expect a date processing library to somehow manage to not have bugs like this.
Haha, you called it!
I guess we'll have to update those screenshots! :)
I guess we'll have to update those screenshots! :)
Ha actually that is a mockup and I personally wrote that in in there to give peoples' brains a blue screen :)
Sort of an easter egg. I also worked in a bunch of references to Metal Gear Solid (so good) elsewhere in our screenshots as well. This is likely going to all be removed though as I really wouldn't want people to think this is a Payload bug!
Sort of an easter egg. I also worked in a bunch of references to Metal Gear Solid (so good) elsewhere in our screenshots as well. This is likely going to all be removed though as I really wouldn't want people to think this is a Payload bug!
perfection
Really impressive, congrats on the launch!
Thank you! We're looking forward to doubling down our efforts. So much more to come.
Congrats! So much opportunity for an API-first CMS.
Imagine you're going to build a new SaaS app. Would you think of building it on a headless CMS? Probably not. To devs, "content management system" is usually a swear word. If a team of engineers gets assigned a CMS project, it's less than thrilling. Engineers want to avoid roadblocks, write code, and build things they're proud of—but existing CMS's get in the way of that left and right with their third-party integrations, point-and-click schema designers, code generation, etc.
Rather, you'd build your backend on an app framework like Django, Laravel, etc., for good reasons: ownership over the backend, better access control, customizable auth patterns, etc. Typically, headless CMS are super limiting; you'll end up fighting the platform more than having it help. But, with app frameworks, you're often left to roll your own admin UI, and that takes time. Not to mention building CRUD UI gets old quick after you do it a few times.
That’s where a headless CMS could shine, because they instantly give you admin UI that non-technical teams can use to manage digital products. That saves a ton of UI dev time— but without an extensible API, headless CMS's are far too limiting. They're designed for marketing teams, which usually only need the generic basics: log in, create a draft, preview the draft, publish the content. Go back and update some pages. Define editor roles and localize content. If you need more than that, you'll soon be out of luck.
Payload is different because we treat developers as first-class citizens. We provide the best of both ends: a powerful and extensible API and a fully customizable admin UI out-of-the-box. All with a developer experience that we obsess over, because we want it ourselves.
Payload is code-first, which allows us to get a lot of things right. We give you what you need, then step back and let you build what you want in TypeScript. You'll understand how your CMS works because you will have written it exactly how you want it. Version control your schema and use your own Express server. Completely control the Admin panel by using your own React components. Swap out fields or even entire views with ease. Use your data however and wherever you need thanks to auto-generated, yet fully extensible REST, GraphQL, and Local Node APIs.
Since it uses your own Express server, you can open up your own endpoints alongside what Payload does. In fact, you can extend just about everything that Payload does. It's MIT and open-source, fully self-hosted, comes with GraphQL and REST APIs, and completely customizable.
We realized the need for Payload while we were building the corporate website for Klarna. The Klarna engineers we were working with were among the best in the world, and while they evaluated headless CMS options, they saw restrictions in how all of the normal contenders "black-box" away the API. They wanted to build their CMS, deploy it on their own infrastructure, and truly "own" their CMS. They fell back to using WordPress. When that happened, Klarna inadvertently shined a spotlight on the CMS market and pointed out a significant void in proper code-based, developer-first CMS. There was no one to give them the developer experience they needed. That's what got us started working on this.
It might seem like a CMS is just a wrapper around a database with a nice UI to show different field types—but in reality, it's a lot more complex than that. We obsessed for years around how to build a proper API that minimizes breaking changes, but still exposes a simple way to extend everything. When you start to introduce things like field-based access control, field-based conditional logic, localization, versions, drafts, and autosave, the task becomes a lot more daunting. Doing it right requires a significant development investment—especially if you want it to perform at scale in addition to removing roadblocks at dev time.
It seems like every day, a new headless CMS pops up. But when you filter down to those that are completely self-hosted, the options quickly dwindle. And then when you remove the confused point-and-click "no-code" (argh!) GUI nature of the existing options, the options narrow to one: Payload.
Our users have built quite a diverse set of apps on Payload. We've seen a virtual events platform, a broadcast platform, SaaS apps of all shapes and sizes, video games, and an Uber-like snow plow service! There are over 1,000 projects in production as of last week, and we can't wait to see more.
Open source has been incredibly helpful. We've gotten significant PRs and our community has gone above and beyond in their contributions. We did not anticipate the level of skill and involvement that we are seeing daily from our community.
Our business model is based on two things:
1. Enterprise features like SSO, audit logs, publication workflows, and translation workflows. Of course, as Payload is open-source, you can build these functions yourself, but enterprises are opting to pay for our official functionality and SLAs rather than rolling it themselves.
2. Cloud hosting. Now that Payload 1.0 is released and ready for production after more than two years of development and dogfooding, we've shifted focus to building a deployment platform for Payload that will deliver permanent file storage, database, API layer, and CI. It will be the easiest way to deploy Payload, but not mandatory to use—much like the NextJS and Vercel model.
You can get started in one line by running `npx create-payload-app` or you can try out our public demo at https://demo.payloadcms.com. The code for the demo is at https://github.com/payloadcms/public-demo.
We would love to hear your feedback. If we don't have something, we'll build it. If there's a sticky spot in the DX (developer experience), we’ll fix it. Looking forward to hearing what you think—and thank you!
[1] Quick refresher: CMS stands for "content management system" and headless just means API-based, with no restrictions over where you use the content on the frontend.