<p>In your general.php for a production site you'll probably see <code>"allowAdminChanges"</code> set to false. This is not an inconsistency, this is how it is supposed to work. 
Every change you make on your local development will be added to a project config file ( yaml file in your config folder ) and fields / sections / settings you create locally will then automatically be synced into your staging or production environment, the reason admin changes aren't allowed by default in there is simple, if you make changes in many places, the project.yaml file will be inconsistent and you'll run into a lot of issues trying to sync your install across different environments.</p>

CC BY-SA 4.0
2019-03-24T06:09:35.250Z
This was it. Thank you for explaining it. What exactly triggers the switch from dev, staging, or production?
Palmtree Studios
CC BY-SA 4.0
2019-03-24T20:17:29.830Z
It looks like the "ENVIRONMENT" variable, if not defined, automatically assumes as production. The generated .env file on setup did not create this variable, so it deferred to the default state. Makes sense, just one of those things that's easy to miss.
Palmtree Studios
CC BY-SA 4.0
2019-03-24T01:54:08.443Z
2019-03-24T01:54:08.443Z
Michael Thomas
<p>So I've created a boilerplate for my web development company using Craft. However, I'm encountering so much inconsistency across different machines.</p>

<p>I recently set up a new website at my public domain. I set up the webserver, and did a Git pull from the boilerplate Bitbucket I've got going.</p>

<p>After the pull, I did a <code>composer install</code> and installed Craft.</p>

<p>At this point the website is working, but I can't login. The Craft setup never prompted me to create a new user/password. Not sure why.</p>

<p>Regardless of this issue, I have to import my DB from my local box to the web server. So after doing so, I can now login. Great right? Not quite.</p>

<p>After I login, I can't access any Settings in the backend and get a error about my license key. I've since fiddled around with my License Key settings on Craft's website, but I <em>still</em> can't access the Settings panels.</p>

<p>I'm sure there's a process to deploying a site to production, but so far I can't find any consistency. Any advice is greatly appreciated.</p>

<p>Screenshot below.</p>

<p><a href="https://i.sstatic.net/eNj0N.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/eNj0N.png" alt="Dashboard View"></a></p>

<craft3><deployment>
Unable to Access "Settings" in Backend
# Unable to Access "Settings" in Backend

(Asked by: username_0 on 2019-03-24)

So I've created a boilerplate for my web development company using Craft. However, I'm encountering so much inconsistency across different machines.

I recently set up a new website at my public domain. I set up the webserver, and did a Git pull from the boilerplate Bitbucket I've got going.

After the pull, I did a `composer install` and installed Craft.

At this point the website is working, but I can't login. The Craft setup never prompted me to create a new user/password. Not sure why.

Regardless of this issue, I have to import my DB from my local box to the web server. So after doing so, I can now login. Great right? Not quite.

After I login, I can't access any Settings in the backend and get a error about my license key. I've since fiddled around with my License Key settings on Craft's website, but I *still* can't access the Settings panels.

I'm sure there's a process to deploying a site to production, but so far I can't find any consistency. Any advice is greatly appreciated.

Screenshot below.

[![Dashboard View](https://i.sstatic.net/eNj0N.png)](https://i.sstatic.net/eNj0N.png)

**Tags:** craft3, deployment


---

## 1 answers

### Answer by username_1 on 2019-03-24. Score: 2 | Accepted answer

In your general.php for a production site you'll probably see `"allowAdminChanges"` set to false. This is not an inconsistency, this is how it is supposed to work.
Every change you make on your local development will be added to a project config file ( yaml file in your config folder ) and fields / sections / settings you create locally will then automatically be synced into your staging or production environment, the reason admin changes aren't allowed by default in there is simple, if you make changes in many places, the project.yaml file will be inconsistent and you'll run into a lot of issues trying to sync your install across different environments.

> **Comments:**
> **username_0**: This was it. Thank you for explaining it. What exactly triggers the switch from dev, staging, or production?  
> **username_0**: It looks like the "ENVIRONMENT" variable, if not defined, automatically assumes as production. The generated .env file on setup did not create this variable, so it deferred to the default state. Makes sense, just one of those things that's easy to miss.  

---

