Ghost Website Configuration Changes Are Not Consistently Applied After Updating the Site Settings

Developer help
1

Hi All,

I am experiencing one specific configuration problem with my Ghost website where changes I make to the site configuration are sometimes not reflected on the live website even though the updated settings appear to have been saved successfully in the Ghost administration area. The configuration change itself does not produce an obvious error, and the Ghost admin interface indicates that the new value has been accepted, but the public website can continue behaving according to the previous configuration. This does not happen with every configuration change, which makes it difficult to identify a consistent pattern. In some cases, the new setting becomes active immediately, while in other cases the website continues using the previous value until some later point. The main issue I am trying to investigate is therefore the inconsistent application of saved Ghost configuration changes to the running website. I want to understand why the administration interface can show the new configuration while the live site still appears to be operating with the previous configuration.

The issue occurs after I modify settings that affect how the Ghost website behaves rather than after changing the actual content of individual posts. I make the change through the Ghost administration interface, save it, and then check the public website to verify that the new configuration is being used. When the problem occurs, the administrative side appears to retain the new value, but the public-facing site continues behaving as though the old configuration is still active. The website itself remains accessible and the affected pages continue loading, so there is no obvious startup failure or complete configuration error. This makes me think that the running Ghost process may not always be picking up the latest saved configuration immediately, although I am not certain whether that is how Ghost is expected to work. I am trying to determine whether configuration values are loaded dynamically, cached by the running application, or read only at a particular point in the application’s lifecycle.

I have already tried saving the same configuration again and then checking the live website after allowing some time for the change to take effect. I have also tested the affected setting more than once to make sure that the problem is not simply caused by accidentally entering an invalid value or failing to save the change. When the new configuration eventually becomes active, the website behaves as expected, which confirms that the setting itself is valid and can be applied correctly. The difficulty is that I cannot reliably predict when the live site will begin using the new value. I have also checked the browser from a fresh session to avoid relying entirely on an existing page state, but the behavior can still occur. Because the Ghost administration interface and public website can appear to disagree about the current configuration, I am trying to find out whether there is a recommended way to verify which configuration the running Ghost instance is actually using.

One thing I would particularly appreciate clarification on is how Ghost handles configuration changes in a production installation. I understand that some application configuration values may be loaded when Ghost starts rather than being dynamically re-read every time a request is handled, and I want to make sure I understand which types of settings behave this way. If a configuration change requires a service restart, cache refresh, or another specific action before the running Ghost instance recognizes it, I would like to know the correct procedure. I am also interested in whether Ghost provides any logs or diagnostic information that can show when a configuration value was loaded and which configuration the running process is currently using. I do not want to restart the server unnecessarily if there is a normal Ghost procedure for applying these settings, but I also do not want to assume that a saved value in the admin interface automatically means that every running component has already adopted it. A clear explanation of the configuration lifecycle would help me determine where the old value is being retained.

The reason I want to solve this properly is that configuration changes need to be predictable on the live website. If the administration interface confirms that a setting has changed but the public site continues using the previous value for an unpredictable period, it becomes difficult to know whether a configuration update has actually been completed. I am particularly interested in finding out whether there is a recommended production workflow for applying configuration changes without leaving the running Ghost process in an inconsistent state. If configuration values are cached internally or loaded only during startup, I would like to understand how that works and whether Ghost has a preferred command or process for reloading them. I am also trying to distinguish this from ordinary browser caching because the behavior can be observed from a fresh session as well. The main goal is to determine why the saved configuration and the behavior of the running website can temporarily differ and what supported procedure should be used to make the new configuration take effect reliably.

Has anyone else experienced a Ghost website where a configuration change appears correctly saved in the Ghost admin area but the live website continues behaving according to the previous configuration? I would appreciate guidance on how Ghost is expected to load and apply configuration changes in a production environment and how I can verify the configuration currently being used by the running instance. I can provide the Ghost version, installation method, hosting environment, specific type of configuration setting involved, and relevant logs if those details would help narrow down the cause. For now, I want to keep the investigation focused on this single problem: a saved Ghost configuration change is not consistently reflected in the live website even though the administration interface shows the new value. I would like to understand whether the cause is related to configuration loading, application state, caching, or the required configuration-reload process, and what the recommended troubleshooting steps are for making configuration changes apply consistently.

2

Hi Joeroot!

Ghost has two kinds of configuration, and they behave differently:

  • Settings saved in Ghost Admin (navigation, theme settings, code injection, design, etc.) live in the database and are applied immediately — no restart needed. Ghost keeps them in an in-memory cache inside the running process and updates it when you save.
  • Values in config.production.json or environment variables (url, mail, database, etc.) are read only once, when Ghost starts. Those need ghost restart (or restarting the container).

When Admin shows the new value but the site keeps the old one for an unpredictable time, the usual causes are:

  1. A cache in front of Ghost. Cloudflare, an Nginx proxy_cache, Varnish or your host’s CDN can keep serving the old HTML. Check the response headers of the page (curl -I ``https://yoursite.com): look for cf-cache-status: HIT, age: or x-cache. Purge or bypass that cache for HTML.
  2. More than one Ghost process sharing the same database (two containers, a scaled service, PM2 cluster). Ghost isn’t built to run multiple instances: each process has its own settings cache, so the one that didn’t handle your save keeps the old values until it restarts. This matches “sometimes immediate, sometimes much later” very well. Make sure exactly one Ghost process is running.
  3. A file-based setting. If the value comes from config or env, Admin may not show it at all — restart Ghost after editing it.

To see what the running instance uses, ghost config (Ghost-CLI installs) or the container’s env shows the file-based config, and ghost log shows startup.

If you can share your Ghost version, install method (Ghost-CLI, Docker, managed host) and which specific setting misbehaves, it’ll be easy to narrow down.

3

Thanks for explaining the difference between settings saved in Ghost Admin and values loaded from config.production.json or environment variables. That helps clarify why some changes might require a restart while others should take effect immediately. The possibility of multiple Ghost processes using separate settings caches is also worth investigating, especially if the behavior changes depending on which process handles a request. I’ll focus on identifying the exact type of setting involved and checking the response headers to see whether a proxy or CDN could be serving older HTML.

One thing I’d like to clarify is how best to distinguish these causes. If the setting is saved through Ghost Admin and the database contains the updated value, but the public site sometimes still uses the old one, would comparing responses from the origin server directly with responses through the public domain help identify whether the issue is an external cache or a separate Ghost process? Also, is there a recommended way to verify that only one Ghost instance is actively serving the site?

4

This still sounds like the same issue you had in the past:

My bet: you have some kind of caching in front of your Ghost site. Caching is great, but for a dynamic website like Ghost it also means you’ll need to bust the cache when things change.

Again, the question would be: where is your site hosted. Or an URL, so we can see what content delivery network/caching is used.

5

Yes, comparing origin vs. public is exactly the right way to split those two causes. Two quick checks:

1. Origin vs. public domain

Through the public domain, look at the headers:

curl -sI https://yourdomain.com/ | grep -iE "cache|age|via|cf-|x-"

Ghost sends Cache-Control: public, max-age=0 on the frontend by default. So an Age above 0, cf-cache-status: HIT, x-cache: HIT or a Via header means something in front of Ghost is serving stored HTML.

Then go around the proxy and hit Ghost directly, from the server itself:

curl -s -H "Host: yourdomain.com" -H "X-Forwarded-Proto: https" http://127.0.0.1:2368/ | grep "<the value you changed>"

(use the port in server.port of your config.production.json). Or from your machine, pin the domain to the origin IP: curl -s --resolve yourdomain.com:443:ORIGIN_IP ``https://yourdomain.com/.

Run each one several times in a row:

  • Origin always shows the new value but the public domain sometimes doesn’t → external cache (CDN or nginx proxy_cache). Purge it or lower its TTL.
  • Origin itself alternates between old and new → more than one Ghost process is answering, each with its own settings cache.

2. Making sure only one Ghost instance is serving

ghost ls                                 # Ghost-CLI installs and their status
pgrep -af "node.*ghost"                  # every running Ghost node process
sudo ss -ltnp | grep node                # which ports they're listening on
systemctl list-units 'ghost_*'           # systemd services created by Ghost-CLI
grep -R "proxy_pass\|upstream" /etc/nginx/sites-enabled/

(On Docker, docker ps instead.) You want exactly one process, on the port nginx proxies to. Pay special attention to an old install or a second container left pointing at the same database: Ghost doesn’t support running multiple instances against one DB, because each process caches settings in memory and only the one that handled the save refreshes its cache. That would match what you describe, where the admin shows the new value but the site flips between old and new.

If you share which setting it is and the output of the header check, I’m happy to take a look.

6

I appreciate that you want to help OP, but I doubt that an the LLM-extended-version of what I said adds much value beyond what’s already been said.

The extra instructions are nice, but I don’t know…a bunch of curl commands rather than “where do you host your Ghost site” isn’t that helpful, in my eyes.

7

Have you checked whether the affected settings require a Ghost restart rather than just saving them in the admin panel? Checking the Ghost logs and testing after a controlled restart could help determine whether the issue is related to configuration loading or caching.

8

Fair point, jannis — you’d already called it, and knowing where the site is hosted is the quicker way to the answer. I’ll keep mine shorter. @joeroot, I’d start with his question: where is your site hosted, and is there a CDN or proxy in front of it?