<h3>Database</h3>

<p>I strongly discourage you from letting Staging and Production share a database. That is a recipe for disaster.</p>

<p>Your Staging site should be semi-disposable, and it's likely that your client will treat it as such. The last thing you want is for someone to make a change in Staging <em>without realizing</em> that they are also making the same change in Production. It's counterintuitive and dangerous.</p>

<p>Instead, have your Staging database be a <em>copy</em> of the Production database. There are several ways to do this, and with the right tools it is actually very simple to clone the database on a regular basis.</p>

<p>I'd recommend using <a href="https://github.com/nystudio107/craft-scripts" rel="nofollow noreferrer">Craft Scripts</a> by Andrew Welch to quickly &amp; easily clone the database. I've found the <code>pull_db.sh</code> script to be quite invaluable.</p>

<h3>Image Assets</h3>

<p>Cloning images is also possible (Craft Scripts has a tool for that), but you may find that it eats up a ton of server space. This, of course, only matters if you're storing your asset files in a local folder. If the assets are cloud-based, then cloning them is a non-issue.</p>

<p>So instead of cloning your image files, I highly recommend the new <a href="https://plugins.craftcms.com/untransform" rel="nofollow noreferrer">Untransform</a> plugin by Ben Croker. It allows your Staging server to actual use transformed images directly from the Production server. There won't be any need to store a second copy of those files, the Production site can provide the originals to your Staging environment.</p>

<h3>Local Dev</h3>

<p>You can use both of the aforementioned techniques on your local machine as well. Indeed, that's what they were originally created for.</p>

CC BY-SA 4.0
2019-08-30T18:52:50.413Z
Many thanks for this. To clarify, your suggestion is to push the database from Production to Staging, correct? Would this cause trouble if the Staging Craft installation was updated first to try out new features, etc? In this case, would the process be: update Staging Craft installation > push file changes w/ new Craft Version to Production > let Craft update Production DB.
Document Services
CC BY-SA 4.0
2019-08-30T18:54:20.987Z
Are you using Project Config? That would have a minor impact on your workflow.
Lindsey D
CC BY-SA 4.0
2019-08-30T18:56:58.030Z
No, but I can. I have used a fairly low tech deployment process for past Craft sites (Local pushed to Production with a few safeguards) but its less than ideal as it requires me to isolate what I'm syncing and when...
Document Services
CC BY-SA 4.0
2019-08-30T18:58:21.323Z
We don't use Project Config, and the processes I described work great for us.
Lindsey D
CC BY-SA 4.0
2019-08-30T18:58:42.037Z
If you want to discuss it in greater detail, let's take this conversation over to Discord.
Lindsey D
CC BY-SA 4.0
2019-08-30T18:15:06.330Z
2019-08-30T18:15:06.330Z
Lindsey D
<p>I'm hoping to implement staging and production installations for a larger scale Craft project I'm working on. My plan is to have the following structure:</p>

<p><code>/staging.domain.com
-- Complete Craft Installation</code></p>

<p><code>/domain.com
-- Complete Craft Installation
-- Image Assets</code></p>

<p>Updates would get done on my local server and then pushed to the staging domain, and finally cloned to the production domain. The two would share the same database and images would live on the production URL. This would allow me to see client updates to content while I make changes to templates and presentation files. I would also be able to make and test Craft software updates in the background.</p>

<p>From reading the documentation I would use the Sites settings to add in both domains and then set variables (dev mode, for example) in the <code>general.php</code> config file. </p>

<p>Does this sounds like a proper set up for this situation?</p>

<p>One optional additional change would be to move image assets off the production server and onto their own (cookieless) domain...</p>

<p>Many thanks in advance!</p>

<multi-environment>
Staging / Production w/ common DB and Assets
# Staging / Production w/ common DB and Assets

(Asked by: username_0 on 2019-08-30)

I'm hoping to implement staging and production installations for a larger scale Craft project I'm working on. My plan is to have the following structure:

`/staging.domain.com
-- Complete Craft Installation`

`/domain.com
-- Complete Craft Installation
-- Image Assets`

Updates would get done on my local server and then pushed to the staging domain, and finally cloned to the production domain. The two would share the same database and images would live on the production URL. This would allow me to see client updates to content while I make changes to templates and presentation files. I would also be able to make and test Craft software updates in the background.

From reading the documentation I would use the Sites settings to add in both domains and then set variables (dev mode, for example) in the `general.php` config file.

Does this sounds like a proper set up for this situation?

One optional additional change would be to move image assets off the production server and onto their own (cookieless) domain...

Many thanks in advance!

**Tags:** multi-environment


---

## 1 answers

### Answer by username_1 on 2019-08-30. Score: 3

### Database

I strongly discourage you from letting Staging and Production share a database. That is a recipe for disaster.

Your Staging site should be semi-disposable, and it's likely that your client will treat it as such. The last thing you want is for someone to make a change in Staging *without realizing* that they are also making the same change in Production. It's counterintuitive and dangerous.

Instead, have your Staging database be a *copy* of the Production database. There are several ways to do this, and with the right tools it is actually very simple to clone the database on a regular basis.

I'd recommend using [Craft Scripts](https://github.com/nystudio107/craft-scripts) by Andrew Welch to quickly & easily clone the database. I've found the `pull_db.sh` script to be quite invaluable.

### Image Assets

Cloning images is also possible (Craft Scripts has a tool for that), but you may find that it eats up a ton of server space. This, of course, only matters if you're storing your asset files in a local folder. If the assets are cloud-based, then cloning them is a non-issue.

So instead of cloning your image files, I highly recommend the new [Untransform](https://plugins.craftcms.com/untransform) plugin by Ben Croker. It allows your Staging server to actual use transformed images directly from the Production server. There won't be any need to store a second copy of those files, the Production site can provide the originals to your Staging environment.

### Local Dev

You can use both of the aforementioned techniques on your local machine as well. Indeed, that's what they were originally created for.

> **Comments:**
> **username_0**: Many thanks for this. To clarify, your suggestion is to push the database from Production to Staging, correct? Would this cause trouble if the Staging Craft installation was updated first to try out new features, etc? In this case, would the process be: update Staging Craft installation > push file changes w/ new Craft Version to Production > let Craft update Production DB.  
> **username_1**: Are you using Project Config? That would have a minor impact on your workflow.  
> **username_0**: No, but I can. I have used a fairly low tech deployment process for past Craft sites (Local pushed to Production with a few safeguards) but its less than ideal as it requires me to isolate what I'm syncing and when...  
> **username_1**: We don't use Project Config, and the processes I described work great for us.  
> **username_1**: If you want to discuss it in greater detail, let's take this conversation over to Discord.  

---

