<p>Even if <code>useProjectConfig</code> was set to <code>false</code>, it's not a good idea to update Craft on a live site because, as you've discovered, errors sometimes happen.</p>

<p>There's even an <a href="https://docs.craftcms.com/v3/config/config-settings.html#allowupdates" rel="nofollow noreferrer">allowUpdates</a> config setting that we recommend people setting to <code>false</code> on the live site just so someone doesn't <em>accidentally</em> update Craft from the control panel.</p>

<p>The safer workflow is to have a dev/staging/test environment where you can perform the update first, verify that everything still works fine and then you can deploy the update files to the live site with a much smaller chance of something going wrong.</p>

<p>If you've decided to use <a href="https://docs.craftcms.com/v3/project-config.html#enabling-the-project-config-file" rel="nofollow noreferrer">Project Config</a>, which it seems you have, then you should <em>really</em> not be doing updates on the live site from the control panel.</p>

<p>And you should also have <a href="https://docs.craftcms.com/v3/config/config-settings.html#allowadminchanges" rel="nofollow noreferrer">allowAdminChanges</a> set to <code>false</code> so no one can even make Craft settings changes from the control panel.</p>

<p>At that point, Project Config should be enabled in all of your environments and your <code>config/project.yaml</code> and <code>composer.json</code> and <code>composer.lock</code> files should be deployed to your live site along with a deployment process that runs <code>composer install</code> on the live site post-deployment.</p>

CC BY-SA 4.0
2020-03-13T21:15:03.283Z
2020-03-13T21:15:03.283Z
Brad Bell
<p>Should Project Config ('useProjectConfigFile' => true,) be set to 'true' or 'false' on the Production server? I have been reading Craft CMS documentation, watching some CraftQuest Lessons,  searching here on Stack Exchange, but have not found a suggested best practice.</p>

<p>I performed a Craft CMS update via the Control Panel Update button with Project Config on. The Update crashed.</p>

<craft3><projectconfig><project.yaml>
Project Config On or Off for Production Server
# Project Config On or Off for Production Server

(Asked by: username_0 on 2020-03-12)

Should Project Config ('useProjectConfigFile' => true,) be set to 'true' or 'false' on the Production server? I have been reading Craft CMS documentation, watching some CraftQuest Lessons, searching here on Stack Exchange, but have not found a suggested best practice.

I performed a Craft CMS update via the Control Panel Update button with Project Config on. The Update crashed.

**Tags:** craft3, projectconfig, project.yaml

---

## 1 answers

### Answer by username_1 on 2020-03-13. Score: 3 | Accepted answer

Even if `useProjectConfig` was set to `false`, it's not a good idea to update Craft on a live site because, as you've discovered, errors sometimes happen.

There's even an [allowUpdates](https://docs.craftcms.com/v3/config/config-settings.html#allowupdates) config setting that we recommend people setting to `false` on the live site just so someone doesn't *accidentally* update Craft from the control panel.

The safer workflow is to have a dev/staging/test environment where you can perform the update first, verify that everything still works fine and then you can deploy the update files to the live site with a much smaller chance of something going wrong.

If you've decided to use [Project Config](https://docs.craftcms.com/v3/project-config.html#enabling-the-project-config-file), which it seems you have, then you should *really* not be doing updates on the live site from the control panel.

And you should also have [allowAdminChanges](https://docs.craftcms.com/v3/config/config-settings.html#allowadminchanges) set to `false` so no one can even make Craft settings changes from the control panel.

At that point, Project Config should be enabled in all of your environments and your `config/project.yaml` and `composer.json` and `composer.lock` files should be deployed to your live site along with a deployment process that runs `composer install` on the live site post-deployment.


---

