I'm considering the reengineering of my web development ecosystem. We use Git very successfully to deploy new changes to our Production, Staging, and Development servers. Traditionally, I've always had a copy of Apache on my local machine - in the interest of keeping my local machine as lean as possible, I'm considering running Apache in a non-local VM and syncing changes somehow.

My initial thought was to run something like rsync and cron (Mac development system) to monitor the directory for file changes and then sync them up. I have been tempted to use a separate branch in Git and writing a hook to have the Apache server pull in the changes, but versioning all of my changes may be unproductive, particularly on very experimental additions.

My question is, is there something I'm not considering in this workflow? This particular project requires ColdFusion, so am I going to realize significant benefits over not having Apache/CFIDE locally?

4 Answers 4


It does not really matter if your server is local or on a separate machine; what matters is if you can test any changes to your code fast enough. For example, you should not have to wait not even a minute for a cron job to pull your code changes to the server. And typically you should test any changes to your code first, and then check them into you repository.

So for a separate machine, what you need is a quick possibility to transfer your code changes from your local machine to the dev server "on-demand". A simple shell script, logging on to the server, running some commands there, which you can run seamlessly from your local box should do this. How this script has to look like depends mostly on your network environment, perhaps you need only some ftpcommands, but since you mentioned rsync, I guess you have a shared file system available.

If this gets "fast enough" for you you will have to test by yourself in your environment. And perhaps you will have to do some optimizing (network speed, for example, may be a factor if you have a large code base with several ten thousands of files).

  • I have a LOT of flexibility - we run gigabit between the two sources, so speed shouldn't be an issue at all. I might just have to test it out for awhile and see if it is fast enough.
    – Nic
    Mar 11, 2012 at 9:02
  • @melee: I've been playing with a ruby gem called guard. It monitors the filesystem, and can execute arbitrary commands when something changes. I'm sure you could hook this up easily to rsync or similar, if you can't just use a network share. Mar 11, 2012 at 10:43
  • @MatthewScharley I already implement guard and think it'd be great in this situation.
    – Nic
    Mar 11, 2012 at 19:35

Have you tried simply exporting the version on the development server as a network share and developing that way?

I'm in the reverse situation. I have a workstation with limited storage, but plenty of grunt. I've got a NAS with a NFS export that I use as /home with little problems over gigabit ethernet. All the web files are on that share, along with most of the files the rest of the services on my PC use, and it's very responsive with a gigabit backbone. Keep in mind that in your case, all the services will be on the same local machine as the files, so it's only the editor that has to access the files across the network. You should see even better performance.


It depends on whether your development stack involves a build step or not.

If it does, then adding a 'copy to development server' step should be added to your personal build configuration. If you rely on step debugging a lot, then check out whether your development environment supports remote debugging.

The other solution is to keep the source files on the remote server in the first place, and work on them there. Either ssh into the server and code over ssh (if you're a vi / emacs kind of guy, this works pretty well), or mount the relevant directories on the server locally.

  • We don't currently implement a build step. I'm on the path to learning VIM, but not quite there yet. Thanks for your input!
    – Nic
    Mar 11, 2012 at 9:01

Lets look at the solutions here:

Adding a deploy command on your build configuration

That's a big no-no for development purposes. This is only to be used for QA by a different team (QA team preferably, but another developer who is not too familiar with the project would help).

Syncing local files to a remote location where the web server is located

This could work, however the time consumed to actually sync the data (or the constant checks) would be a lot of unneeded delay/overhead when you want to test a quick fix for example.

Keeping your local apache but turning it on/off

This could help lean your system, but still the overhead each time would be greater than the gain in performance.

My suggestion:

You should setup a workstation to work directly on a shared folder. This means that you save changes directly to the webserver folder. The overhead is minimal, and mostly unnoticed as by the time you hit save then alt+tab to hit refresh, the file has been already passed to the webserver. You keep your computer with the minimum software required only to develop, kind of like a terminal.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.