configure admin server to another server magento

This will change the name of the path entity used to get access to the admin panel.
Edit “app/etc/local.xml” and change
 # <frontName><![CDATA[admin]]></frontName>
to the path you would like to use

 # <frontName><![CDATA[hidden_path]]></frontName>
and then clear Magento cache in backend.
After that the Magento Admin panel will be accessible through the URL selected, in this case:
If you want just set up a different domain for your backend and use, for example VirtualHost related features like HTTP auth for your backend or restrict access by IP, you can do this with “Custom admin path”.
It MUST be the same Magento installation with the same document root as for the frontend. 
In other case it will break your Magento installation.
1. Set
"System->Configuration->General->Web->URL Options->Auto-redirect to Base URL" to "No"
2. Configure the VirtualHost. You MUST ensure that Magento is accessible with your new domain, EG. “”.
3. Set
"System->Configuration->Advanced->Admin->Admin Base URL->Use Custom Admin Path" to "Yes"
then set
"System->Configuration->Advanced->Admin->Admin Base URL->Custom Admin Path" to ""
That should be the full URL with “http://”, admin domain, slash at the end “/”.
Now, backend should be accessible on URL “
Magento allows you to set up the admin interface on a separate node. This can be useful if you actively work with the admin as well as if you want to decrease the indexing impact on the frontend.
1. You should set up shared cache Memcached+DB:
- install memcached ( and PHP memcache extension ( Memcached service should be accessible from both frontend and backend nodes.
- set the following config in local.xml. Pay attention and change IP address of memcached server.
For EE up to and CE any version (For EE additional FPC config required).
Once shared cache is working, the following step will be:
2. Export media directory with NFS.
When you upload product images on a separate server you should make them available in a certain way for the frontend server. The best way is to share media catalog with NFS and mount it on a backend server in a document root.
There are a few steps for the permissions:
* use the same UID for running web-server (apache for instance). Default is “48” in RHEL
* use idmapd to map any UID’s to single UID (RHEL: /etc/idmapd.conf)
Sample config “/etc/exportfs” for frontend. 48 is single web-user UID:
sample fstab mount options: /var/www/html/media nfs proto=udp,hard,bg,intr,noatime,rsize=32k,wsize=32k,noatime 0 0
Don’t forget enable run on boot “/etc/init.d/netfs” in RHEL
 # chkconfig netfs on
this will enable automount NFS share on boot.
3. (Optionally) Shared sessions
We should mention that shared sessions in memcache is recommended for such set up. For that you should set up a second memcached instance and set the following config in local.xml (replace given IP with your session memcached IP):
4. Set URL option in backend
"System->Configuration->General->Web->URL Options->Auto-redirect to Base URL" to "No"
5. Configure VirtualHost. You MUST ensure that Magento is accessible with your new domain. For instance let’s use “”.
6. Set custom URL in backend
"System->Configuration->Advanced->Admin->Admin Base URL->Use Custom Admin Path" to "Yes"
then set
"System->Configuration->Advanced->Admin->Admin Base URL->Custom Admin Path" to ""
It should be the full URL with “http://”, admin domain, slash at the end “/”.
7. Cron set up
You should run cron only on the backend server. Normaly it should run every 5 minutes:
*/5 * * * * /bin/sh /var/www/html/
Now, the backend should be accessible on URL “” located on a separate server.
Remember keep your code in a synchronized state on nodes frontend and backend. 
If you install something in Magento you should copy the modules, updates to the other node. 

A good way to do that is set up rsync for code, for example from backend to frontend.
Also it can be done with NFS, but it's not recommended!
If anything goes wrong and you cannot get access to admin anymore you can back everything up with the following steps:
You should delete changed options from database (you are doing this on your own risk!!!):
SELECT * FROM core_config_data WHERE path LIKE "%url%";
Then find config_id of your added custom admin URL options. It can looks like
 | config_id | scope| scope_id | path                                      | value                                    |
 |         4    | default |               0 | web/unsecure/base_url    |  |
 |         5    | default |               0 | web/secure/base_url        |   |
 |        14   | default |               0 | admin/url/use_custom     | 1                                             |
 |        15   | default |               0 | admin/url/custom             | |
 |        16   | stores   |               0 | web/secure/base_url       | |
 |        17   | stores   |               0 | web/unsecure/base_url   | |
 |        26   | default |               0 | web/url/redirect_to_base | 0                                             |
Locate the paths “web/secure/base_url” and “web/unsecure/base_url” with scope “stores” and the invalid custom adminURL. Then use their config_id to delete this options
DELETE FROM core_config_data WHERE config_id=FIRST_ID_HERE;
DELETE FROM core_config_data WHERE config_id=SECOND_ID_HERE;
And then
UPDATE core_config_data SET value=0 WHERE path="admin/url/use_custom";
UPDATE core_config_data SET value="" WHERE path="admin/url/custom";
Then clean cache.
This can be done with removing “var/cache” directory when you use cache in files
Or restart memcache if you use it for caching.