<p>Absolutely, this will work! In fact, I would say this is the recommended workflow for Craft CMS.</p>
<blockquote>
<p>I wish to install the Craft CMS updates on the developer environment and then push any and all changed and new files to the GIT repo, and then pull them on the production instance.</p>
</blockquote>
<p>You can perform the update using the command <code>php craft update all</code>. See the <a href="https://craftcms.com/docs/4.x/updating.html#updating-from-the-terminal" rel="nofollow noreferrer">updating instructions</a> for details. This will write the newly installed versions of Craft and any plugins you're using to your <code>composer.json</code> and <code>composer.lock</code> files. For some updates, you may also see some changes in your <code>config/</code> directory. Commit the two composer files and any changes in the <code>config/</code> folder to git, then pull that version in your live environment.</p>
<p>Use <code>composer install</code> to install the dependencies, then use <code>php craft migrate/all</code> to apply any pending migrations. This will change the database structure to reflect any changes required by Craft or plugins. It will (usually) not overwrite any content.</p>
<blockquote>
<p>First question is, do the databases of both environments need to be identical?</p>
</blockquote>
<p>Usually, the <em>structure</em> should be identical, because there should be no configuration changes done on the live environment. All changes should be done in a development environment and then propagated to the live environment. Any changes done locally to the config will be reflected in the <code>config/</code> folder. You can commit that to git, then pull those changes to the live environment and use <code>php craft project-config/apply</code> to apply the changes to that database.</p>
<p>The <em>content</em> can differ between environments, applying the config will not overwrite any content. Unless of course a config change is destructive – for example, deleting a field will also delete the corresponding database column. In those cases, you'll want to write a <a href="https://craftcms.com/docs/4.x/extend/migrations.html" rel="nofollow noreferrer">migration</a> to migrate that content first.</p>
<blockquote>
<p>Will this work or am I missing something?</p>
</blockquote>
<p>If you're updating an older site, make sure the site is already using composer to manage dependencies, and check if it's using project config. Also, make sure your development environment is up-to-date with your live environment (regarding configuration, not content). Before you put anything live, test the changes thoroughly in your development environment, and maybe replicate the live site to a staging environment to test the deployment first. Also, make sure to take a full backup of the live site before deployment.</p>
<p>I recommend putting all the steps required for deployment in a deployment script – see <a href="https://craftcms.com/knowledge-base/deployment-best-practices" rel="nofollow noreferrer">Deployment Best Practices</a> for details.</p>

CC BY-SA 4.0
2022-12-13T09:24:28.933Z
Thanks so much for this. One question, is updating through the CMS backend on the dev environment the same as running "php craft update all"? The reason I ask is because I noticed that I don't have the craft cli installed on the dev environment for some reason.
BrokenCode
CC BY-SA 4.0
2022-12-13T10:01:18.010Z
@BrokenCode I think updating through the backend should have the same effect as updating through the CLI, though you probably don't get detailed error messages if something goes wrong. If your site is already using version control, you can just try it out and see if it writes the new versions to your composer files. If you don't have the craft binary in your project, you can just add it, it's just a few lines of code. See the [`craft` file in the starter project](https://github.com/craftcms/craft/blob/main/craft).
MoritzLost
CC BY-SA 4.0
2022-12-13T23:50:42.820Z
Just to be clear, updating Craft and plugins will not generate any change in your repo apart from `composer.lock` and `composer.json` as the `vendor` folder should be in `.gitignore`. Also just pulling these in prod would not have any effect till you run a `composer update` (or run `php craft update all` or press the "update" button, but these 2 ways don't really need the new composer files anyway as they would be regenerated during the update).
Capsule
CC BY-SA 4.0
2022-12-14T08:44:55.540Z
@Capsule Updating Craft and plugins can also result in changes in the `config/` folder, for example, updated schema versions. Those should be committed as well. `composer update` doesn't perform any pending migrations, so `php craft update all` should be used instead. On the live environment, you should use `composer install` instead of `composer update`, to install the exact versions you updated to in your dev environment.
MoritzLost
CC BY-SA 4.0
2022-12-14T11:21:27.590Z
Sorry, I'm used to only run `php craft migrate/all` after a fresh `composer install` happening during deployment. You are right, `composer update` and `php craft update all` don't do the same, but `composer update` followed by `php craft migrate/all` will end up with the same changes. In saying that my comment was more about the fact pushing these changes alone to the repo and pulling them from another environment will NOT update Craft.
Capsule
CC BY-SA 4.0
2022-12-13T09:04:41.163Z
2022-12-13T09:04:41.163Z
MoritzLost
<p>I have a local environment in developer mode, and I have a remote environment in production mode.</p>
<p>I wish to install some Craft CMS updates.</p>
<p>First question is, do the databases of both environments need to be identical?</p>
<p>I wish to install the Craft CMS updates on the developer environment and then push any and all changed and new files to the GIT repo, and then pull them on the production instance.</p>
<p>Will this work or am I missing something?</p>

<craft3>
Craft CMS: update workflow
# Craft CMS: update workflow

(Asked by: username_0 on 2022-12-13)

I have a local environment in developer mode, and I have a remote environment in production mode.

I wish to install some Craft CMS updates.

First question is, do the databases of both environments need to be identical?

I wish to install the Craft CMS updates on the developer environment and then push any and all changed and new files to the GIT repo, and then pull them on the production instance.

Will this work or am I missing something?

**Tags:** craft3


---

## 1 answers

### Answer by username_1 on 2022-12-13. Score: 1 | Accepted answer

Absolutely, this will work! In fact, I would say this is the recommended workflow for Craft CMS.

> I wish to install the Craft CMS updates on the developer environment and then push any and all changed and new files to the GIT repo, and then pull them on the production instance.

You can perform the update using the command `php craft update all`. See the [updating instructions](https://craftcms.com/docs/4.x/updating.html#updating-from-the-terminal) for details. This will write the newly installed versions of Craft and any plugins you're using to your `composer.json` and `composer.lock` files. For some updates, you may also see some changes in your `config/` directory. Commit the two composer files and any changes in the `config/` folder to git, then pull that version in your live environment.

Use `composer install` to install the dependencies, then use `php craft migrate/all` to apply any pending migrations. This will change the database structure to reflect any changes required by Craft or plugins. It will (usually) not overwrite any content.

> First question is, do the databases of both environments need to be identical?

Usually, the *structure* should be identical, because there should be no configuration changes done on the live environment. All changes should be done in a development environment and then propagated to the live environment. Any changes done locally to the config will be reflected in the `config/` folder. You can commit that to git, then pull those changes to the live environment and use `php craft project-config/apply` to apply the changes to that database.

The *content* can differ between environments, applying the config will not overwrite any content. Unless of course a config change is destructive – for example, deleting a field will also delete the corresponding database column. In those cases, you'll want to write a [migration](https://craftcms.com/docs/4.x/extend/migrations.html) to migrate that content first.

> Will this work or am I missing something?

If you're updating an older site, make sure the site is already using composer to manage dependencies, and check if it's using project config. Also, make sure your development environment is up-to-date with your live environment (regarding configuration, not content). Before you put anything live, test the changes thoroughly in your development environment, and maybe replicate the live site to a staging environment to test the deployment first. Also, make sure to take a full backup of the live site before deployment.

I recommend putting all the steps required for deployment in a deployment script – see [Deployment Best Practices](https://craftcms.com/knowledge-base/deployment-best-practices) for details.

> **Comments:**
> **username_0**: Thanks so much for this. One question, is updating through the CMS backend on the dev environment the same as running "php craft update all"? The reason I ask is because I noticed that I don't have the craft cli installed on the dev environment for some reason.  
> **username_1**: @username_0 I think updating through the backend should have the same effect as updating through the CLI, though you probably don't get detailed error messages if something goes wrong. If your site is already using version control, you can just try it out and see if it writes the new versions to your composer files. If you don't have the craft binary in your project, you can just add it, it's just a few lines of code. See the [`craft` file in the starter project](https://github.com/craftcms/craft/blob/main/craft).  
> **username_2**: Just to be clear, updating Craft and plugins will not generate any change in your repo apart from `composer.lock` and `composer.json` as the `vendor` folder should be in `.gitignore`. Also just pulling these in prod would not have any effect till you run a `composer update` (or run `php craft update all` or press the "update" button, but these 2 ways don't really need the new composer files anyway as they would be regenerated during the update).  
> **username_1**: @username_2 Updating Craft and plugins can also result in changes in the `config/` folder, for example, updated schema versions. Those should be committed as well. `composer update` doesn't perform any pending migrations, so `php craft update all` should be used instead. On the live environment, you should use `composer install` instead of `composer update`, to install the exact versions you updated to in your dev environment.  
> **username_2**: Sorry, I'm used to only run `php craft migrate/all` after a fresh `composer install` happening during deployment. You are right, `composer update` and `php craft update all` don't do the same, but `composer update` followed by `php craft migrate/all` will end up with the same changes. In saying that my comment was more about the fact pushing these changes alone to the repo and pulling them from another environment will NOT update Craft.  

---

