Seeking Understanding


I do apologise for bothering you all with this potentially trivial question - please feel free to direct me to where I can read up to solve it :slight_smile:

I very much like the idea a headless cms and specifically ghost. The one thing that I do not understand or can wrap my head around is how or why it is fine that ghost cannot be clustered? how is ghost able to serve and manage all the content requests from a single instance and to a single db that is not Highly available. Also how do you ensure locality of deployment is satisfied with only one instance?

Is this more of a concern without a Static Site Generator? I.e if using a SSG you would “compile” your public facing site and content and deploy that to a global CDN? If so what about the case of leveraging the content API?

I am essentially looking for best practise for production deployment and want better understanding of the design and architecture choices! I know that there are big sites that run fine on ghost - I just want to understand how/why given my concerns and what actual things I need to be aware of so as to be properly prepared for serving my content!


Hey @CockyAmoeba :wave:

Here’s the FAQ entry relating to clustering:

I know it doesn’t fully answer your questions, so feel free to follow up any others :slight_smile:

Thanks Vikas

I did see that - I was posing the question and thinking deeper due to my newness with ghost.
I understand that a CDN will work for a blog especially one built with a static site generator - all the “compiled” pages can be served from a CDN answers a lot of my questions BUT!!
How do you front the content requested via the content for any content you wish to serve from a dynamic website backend? i…e using Ghost a a pur API CMS? is this possible via a CDN? I do not understand! Can you use Ghost in this way ? If this is indeed the path how do you reliable do this for secured content that should only be served to authenticated website users (not ghost users) ?

I understand the current choice and design constraint that only one admin is needed - downtime there is of little impact and the db can be back-up etc. As stated above my main concern is with requesting the content - that this is scalable, reliable and available!!!

Please provide insight!


If I understand your question correctly, you’re asking 2 things:

  1. How can ghost’s frontend handle any volume of requests?

Here, a cache service is your best bet. The cache service will sit in front of Ghost, and serve all frontend requests (never any /ghost/* requests, though!). When a post gets updated, you can use a webhook to purge the specific post-url, or you can purge the entire cache.

  1. How can ghost’s headless API handle a large volume of requests

I don’t personally have a good answer for this. From what I understand, the content api is designed to be highly available - for example, the Content API is hit quite often as users getting started with Gatsby + Ghost use its demo content

Greetings Vikas

Regarding #1 - yes that is what I wanted to confirm and am happy with that
Regarding #2 - The example you posted is using the content api to feed data to a static site generator that is deployed dot a CDN. I am more concerned about front ends that need to dynamically request content i.e. native apps, logged in dynamic content? this will not be “pre-compiled”

So in this case how much load can Ghost handle and what are best practices for using ghost as a pure content api?


You’re correct that the content API is used to feed Gatsby, but what I’m saying is every single person that uses gatsby-starter-ghost will have the content api keys for and a decent number of them will actually hit it. Again, I can’t really say much about the specifics of the content API, you’re probably going to have to wait until next week (since it’s the weekend) for a response from one of the Ghost core members :slight_smile:

Thanks for your reply Vikas. While I understand you proving that the public will be hit a decent number of times to generate a static site - it is not the same use case as hitting ghost content api actively and constantly for a dynamic site. I appreciate your trying ot provide clarity - I was hoping that a core member would be able and willing to comment and provide further clarity…
Any advise on I might entice other to answer?