Answers.Body: <p>As the <a href="https://craftcms.com/docs/3.x/project-config.html#environment-setup" rel="nofollow noreferrer">Craft documentation suggests</a>, it's best to avoid configuration changes in production by setting the <a href="https://craftcms.com/docs/3.x/config/config-settings.html#allowadminchanges" rel="nofollow noreferrer"><code>$alloAdminChanges</code> General setting</a> to <code>false</code>.</p>
  <p>In my company, we're used to doing all configuration changes in the development environment (ie. on developers' working copy), commit them &amp; let CI deploy to staging &amp; production environments. We run <code>craft project-config/apply</code> at the end of our deployment process.</p>
  <p>This means we lose a little bit of agility, as every configuration related change involves work from a developer and a deployment. On the other end, this is a clear win in maintainability, because we know for sure that all environments share the same configuration.</p>
  <hr />
  <p><em>Edit: I just noticed you said you didn't use project config.</em></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-07-29T08:43:34.470Z
Answers.LastActivityDate: 2021-07-29T08:43:34.470Z
Answers.UserDisplayName: nstCactus
Body: <p>We have experienced issues with Craft updates since the project config feature was released. Typically we run a multi-node application cluster that auto-scales up/down as needed. The current theory on what's going wrong is that if we have changes to make during the course of an update (ie, configuration, enabling modules, etc) we'd make those changes and they would likely be applied to only one node in the cluster and never sync to the other nodes.</p>
  <p>How are other people solving this? I don't see recommendations in the official Craft documentation but I can envision two possibilities:</p>
  <ol>
  <li>Commit all changes to project config and only rely on deploys to put it in place.</li>
  <li>Create a shared mount point for project config so that all nodes read from the same configuration.</li>
  </ol>
  <p>Any other ideas? Any officially blessed approaches here? I'm betting #1 is preferred.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-07-27T22:09:45.840Z
Comments.Text: "we'd make those changes and they would likely be applied to only one node in the cluster and never sync to the other nodes." - I can't tell from the context, but are you making those changes locally and deploying them? Or are you making those changes directly on production?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-07-28T15:04:24.353Z
Comments.Text: We have made changes after deploying the code - not using project config to push settings out.
Comments.UserDisplayName: Jessica Zehavi
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-07-28T15:30:38.563Z
Comments.Text: We made the changes directly on production, that is, not using project config.
Comments.UserDisplayName: Jessica Zehavi
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-07-28T17:22:59.310Z
Comments.Text: How exactly are you running your cluster? Kubernetes? AWS ELB? TBH this is not a problem for Craft necessarily,  CMS like WordPress also have issues scaling and keeping resources in sync across multiple instances.
Comments.UserDisplayName: RitterKnight
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-07-28T19:07:59.093Z
Comments.Text: @RitterKnight AWS ELB. I think you're essentially restating my question - I'm asking how others are keeping settings and resources in sync because surely we are not the only ones running Craft in a multi-node cluster. :) We use S3 for assets but what lives on disk is always isolated with ephemeral web nodes.
Comments.UserDisplayName: Jessica Zehavi
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-07-29T08:48:47.220Z
Comments.Text: I think project-config is the right tool to help you keep settings in sync between environments. Any particular reason why you chose not to use it?
Comments.UserDisplayName: nstCactus
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-07-29T15:50:50.257Z
Comments.Text: @JessicaZehavi:  Thanks for the follow-up. To be clear I was asking for a bit more details about your deployment, as your question is too broad to answer. The SE format works best when you get specific.  Asking what others are doing it isn't really a question. You also didn't say what issues you're actually seeing? It sounds like one node has different content / code than the others? High availability is a really broad topic. Generally code needs to be replicated to multiple nodes and how you do that (EFS / Gluster) you can write a book on. Docker/Kubernetes could work, as could others...
Comments.UserDisplayName: RitterKnight
Tags: <craft3><projectconfig>
Title: Project config issues with multi-node clusters?
ThreadText: # Project config issues with multi-node clusters?
  
  (Asked by: username_0 on 2021-07-27)
  
  We have experienced issues with Craft updates since the project config feature was released. Typically we run a multi-node application cluster that auto-scales up/down as needed. The current theory on what's going wrong is that if we have changes to make during the course of an update (ie, configuration, enabling modules, etc) we'd make those changes and they would likely be applied to only one node in the cluster and never sync to the other nodes.
  
  How are other people solving this? I don't see recommendations in the official Craft documentation but I can envision two possibilities:
  
  1. Commit all changes to project config and only rely on deploys to put it in place.
  2. Create a shared mount point for project config so that all nodes read from the same configuration.
  
  Any other ideas? Any officially blessed approaches here? I'm betting #1 is preferred.
  
  **Tags:** craft3, projectconfig
  
  > **Comments:**
  > **username_1**: "we'd make those changes and they would likely be applied to only one node in the cluster and never sync to the other nodes." - I can't tell from the context, but are you making those changes locally and deploying them? Or are you making those changes directly on production?  
  > **username_0**: We have made changes after deploying the code - not using project config to push settings out.  
  > **username_0**: We made the changes directly on production, that is, not using project config.  
  > **username_2**: How exactly are you running your cluster? Kubernetes? AWS ELB? TBH this is not a problem for Craft necessarily,  CMS like WordPress also have issues scaling and keeping resources in sync across multiple instances.  
  > **username_0**: @username_2 AWS ELB. I think you're essentially restating my question - I'm asking how others are keeping settings and resources in sync because surely we are not the only ones running Craft in a multi-node cluster. :) We use S3 for assets but what lives on disk is always isolated with ephemeral web nodes.  
  > **username_3**: I think project-config is the right tool to help you keep settings in sync between environments. Any particular reason why you chose not to use it?  
  > **username_2**: @username_0:  Thanks for the follow-up. To be clear I was asking for a bit more details about your deployment, as your question is too broad to answer. The SE format works best when you get specific.  Asking what others are doing it isn't really a question. You also didn't say what issues you're actually seeing? It sounds like one node has different content / code than the others? High availability is a really broad topic. Generally code needs to be replicated to multiple nodes and how you do that (EFS / Gluster) you can write a book on. Docker/Kubernetes could work, as could others...  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2021-07-29. Score: 1
  
  As the [Craft documentation suggests](https://craftcms.com/docs/3.x/project-config.html#environment-setup), it's best to avoid configuration changes in production by setting the [`$alloAdminChanges` General setting](https://craftcms.com/docs/3.x/config/config-settings.html#allowadminchanges) to `false`.
  
  In my company, we're used to doing all configuration changes in the development environment (ie. on developers' working copy), commit them & let CI deploy to staging & production environments. We run `craft project-config/apply` at the end of our deployment process.
  
  This means we lose a little bit of agility, as every configuration related change involves work from a developer and a deployment. On the other end, this is a clear win in maintainability, because we know for sure that all environments share the same configuration.
  
  ---
  
  *Edit: I just noticed you said you didn't use project config.*
  
  
  ---
  
  