Set up your own local domains for web development on Mac OSX

I do a lot of local web development, mostly using WordPress. I have written several guides, including:

This guide is an addendum to an article I wrote on setting up multiple subdomains back in 2010.

If you find yourself working a lot on your local mac and then synchronizing your WordPress sites to a production server, you don’t want to have to replicate all your changes in WordPress on production — you just want to sync all the files and then export your local database for importing to production (or vise versa as the case may be).

There are some plugins that can help you with migration of the WordPress database and files. One excellent plugin is called BackupBuddy. It’s a Pro plugin (and really well done), so you’ll have to shell out some money. However, it’s slower and more tedious (i think) than my manual method and I never use it for deployment purposes (just for scheduled backups).

But let’s say you’re a cash-strapped developer and you can’t afford BackupBuddy, or (like me) you like the hands-on approach where you know exactly what’s happening at every stage of the sync process. You may be using Coda for development and keeping your files synced with production, or you’re using an FTP client with a sync function like Transmit. But what do you do about the database?

I use MySQL WorkBench to do my importing and exporting of SQL databases between localhost and remote. If you export your local database to a self-contained SQL file with the intention of importing it to production, you’ll have to replace the website domain name throughout the file before you import (or WordPress will break spectacularly). This can be done with a simple search-and-replace on the domain name before you import the file to its destination, but you could run into some gotchas along the way. Serialized data and email addresses can sometimes trip you up big time! A poorly written plugin could cause this whole export-search-and-replace-import method not to work at all.

If you followed my guide on setting up multiple localhosts, you might have a hosts file on your mac (/etc/hosts) that looks like this:

Screen Shot 2014-02-25 at 1.00.12 PMFor example, this let’s me access my local copy of client1‘s site at client1.localhost.

I’ve found a better way.

Instead of naming your localhost sites:

  •    localhost
  •    phpmyadmin.localhost
  •    clientsite1.localhost
  •    clientsite2.localhost
  • etc…

Try this approach instead:


No more “localhost” sites!!! What I’ve done here is simply replace the top level domain extension, “.com” (used in production), with one that I’ve created just for my own purposes on my local environment. The “.new” domain extension doesn’t actually exist anywhere but on my machine. If I enter (for example) into my web browser, the hosts file will kick in and send me to the local site.

Of course, you’ll also need to make a change in your vhosts config file in apache.

either here /etc/apache2/httpd.conf

or /etc/apache2/extra/httpd-vhosts.conf on OS X Lion

An example virtual host entry might look like this:


    DocumentRoot "/Users/Milkman/Sites/"
    ErrorLog "/private/var/log/apache2/thermal.localhost-error_log"
    CustomLog "/private/var/log/apache2/thermal.localhost-access_log" common
    Allow from all

So, and (without the “www”) both work locally. (The domain extension doesn’t have to be “.new” — it can be whatever you want, like “.loc”, or “.cat” or “.barf”, or whatever.)

This makes it really, really easy to do a search and replace on my WordPress databases when I’m either importing or exporting between my local site and production. All I need to do is search for the string:

and replace it with:

(or vise versa) throughout the SQL file.

Setting up the “.new” extension for local testing is really great! So, when I’m ready to copy the database from local to remote all I have to do is export the db as a self-contained SQL file, open it in BBEdit, search and replace with, save it as a new version, backup my live db for safety, and then import the new SQL file. Voila!

I hope this method helps you.

REMEMBER to ALWAYS make a backup of your database before and after importing .

And don’t assume this method will work without testing.

If you find any gotchas with this method, or have a better suggestion, let me know in the comments.

This entry was posted in Techno-babble, WordPress. Bookmark the permalink.
  • Guido Schlabitz

    For anybody running the Yosemite beta, remember that Apache was upgraded to 2.4 and a lot of directives have changed. See below and adjust your .conf files accordingly:

  • Sean Ansari

    I had to remove the “Allow from all” statement to get it to work.
    Regardless, nice tutorial. Thanks for sharing!

    • Alexander Lee Williams

      Ok, good to know. Thanks!