<p>Nothing native in Craft that would do this, but I suppose you'd be able to <code>.htaccess</code> redirect all requests to your <a href="http://buildwithcraft.com/docs/config-settings#cpTrigger" rel="nofollow">cpTrigger</a>.</p>

CC BY-SA 4.0
2019-07-10T16:42:16.630Z
You could also just change to cpTrigger to something really obscure and not share that with the client. At least then you'd be able to access to admin panel in production yourself, if you needed to. The client would just get a 404 since the cpTrigger in production would not be what they were used to.
Alex Kendrick
CC BY-SA 3.0
2014-11-21T20:03:42.387Z
2014-11-21T20:03:42.387Z
Brad Bell
<p>The best way to do this (in my opinion) is to disable access to the CP from the user's permission panel.</p>

CC BY-SA 4.0
2019-12-06T00:37:49.447Z
This is partially-valid, in that it _will_ work to revoke access, but I think the question is more about how to completely remove the possibility of admin access and mutations via the admin in one environment. I'd assume the project is using User Groups to define permissions, which means that the asker would have to define separate Groups and/or permissions for each environment—or manually grant/revoke access in the database (which in itself is likely not a viable solution, as it sounds like they're synchronizing the database _up_ from a place where the admin _is_ accessible).
August Miller
CC BY-SA 4.0
2019-12-06T21:09:23.237Z
Good points, it does seem likely the user groups are already set up though.
Clark Nelson
CC BY-SA 4.0
2019-12-05T23:14:46.560Z
2019-12-05T23:14:46.560Z
Clark Nelson
<p>Good call Brad! Not sure why that didn't occur to me :)</p>

<p>Here's how that's done: </p>

<pre><code># Kill admin access
RewriteCond %{REQUEST_URI} ^(.*)/admin
RewriteRule ^(.*)$ - [F,L]
</code></pre>

CC BY-SA 3.0
2014-11-21T20:17:27.017Z
2014-11-21T20:17:27.017Z
dgrebb
<p>Is it possible? I have a situation where a client needs the production site to be completely shut down and void of content updates. They do all of their content management on a staging site, then publish the database when changes are approved.</p>

<control-panel><admin><login>
Can I disable the control panel?
# Can I disable the control panel?

(Asked by: username_0 on 2014-11-21)

Is it possible? I have a situation where a client needs the production site to be completely shut down and void of content updates. They do all of their content management on a staging site, then publish the database when changes are approved.

**Tags:** control-panel, admin, login

---

## 3 answers

### Answer by username_0 on 2014-11-21. Score: 5 | Accepted answer

Good call Brad! Not sure why that didn't occur to me :)
Here's how that's done: 
# Kill admin access
RewriteCond %{REQUEST_URI} ^(.*)/admin
RewriteRule ^(.*)$ - [F,L]


---

### Answer by username_1 on 2014-11-21. Score: 3

Nothing native in Craft that would do this, but I suppose you'd be able to `.htaccess` redirect all requests to your [cpTrigger](http://buildwithcraft.com/docs/config-settings#cpTrigger).

> **Comments:**
> **username_2**: You could also just change to cpTrigger to something really obscure and not share that with the client. At least then you'd be able to access to admin panel in production yourself, if you needed to. The client would just get a 404 since the cpTrigger in production would not be what they were used to.  

---

### Answer by username_3 on 2019-12-05. Score: 1

The best way to do this (in my opinion) is to disable access to the CP from the user's permission panel.

> **Comments:**
> **username_4**: This is partially-valid, in that it _will_ work to revoke access, but I think the question is more about how to completely remove the possibility of admin access and mutations via the admin in one environment. I'd assume the project is using User Groups to define permissions, which means that the asker would have to define separate Groups and/or permissions for each environment—or manually grant/revoke access in the database (which in itself is likely not a viable solution, as it sounds like they're synchronizing the database _up_ from a place where the admin _is_ accessible).  
> **username_3**: Good points, it does seem likely the user groups are already set up though.  

---

