How To: Local Facebook App Development


Developing any computer application is a process that will inevitably involve many mistakes, bugs, and other trials. Indeed, half of writing an application is just testing the code to make sure it behaves correctly, and scratching your head when it doesn’t. Clearly, you want to shield your end-users from experiencing the app in such a state. So, one important and popular web application development technique is to have a local test server for development, only pushing code to the live server after it has been appropriately tested. This is a relatively easy process, especially if your local server (be it your laptop or some other computer on your local network) runs the same OS as your server.

Writing Facebook apps adds a layer of challenge to this development pattern, since you can’t exactly download the Platform and run it on your computer, and anyway with all the overhead you wouldn’t want to. Furthermore, each app has a specific server to which it is linked, and there’s no current way to list “test” servers alongside the live one. Hence this tutorial.

(What follows assumes you’re already somewhat familiar with the Facebook Platform and the Developer Application, and, obviously, that you know how to write an application. If not, go to Facebook’s Developer page for more information).

Step 1: Preparing Your Local Environment

The first part of local prep is to ensure that your local server has web server and script interpreter software installed. By far the most common arrangement of these is the LAMP set-up (Linux/Apache/MySQL/PHP). Various LAMP (or “WAMP” for Windows) installer packages exist for just about every platform. In Ubuntu, simply search for the individual packages and install them. For Mac OS X, I like Marc Liyanage’s packages here. For Windows, I have used WAMP Server.

Once you’ve got your server operating locally, the next step in local Facebook app development is ensuring that your local server can be accessed from the external web. There are a number of ways to do this, but unless your server has a dedicated external IP, it will involve port forwarding from your internet gateway (perhaps a DSL modem and router) through to your server. Since each internet gateway is different, the actual steps in the process will themselves differ, but basically, you need to ensure that port 80 is passed from your gateway to your server. It makes it easier if your computer has a static IP internally, that way you can forward port 80 to that IP and you know it will always go to your server. Otherwise, every time you reconnect your server/computer to the local network, you may have to change the internal IP address to which you’re forwarding port 80. To get instructions for forwarding with your particular router, check out

Third, you need to find the external IP for your internet gateway. If you already have a dedicated IP, you’re set. If not, you need to find out what your external IP is. The easiest way to do this is to go to Copy and paste what you find there, and save the IP for later.

Finally, ensure your web server accepts connections from the wider internet by pasting the IP into the address bar of your browser. If you get a response from your server, you’re good to go! If not, you need to fix your server set-up, or if your server works fine locally, your port forwarding. Note that if you have a home network with an internet gateway (DSL router) and a wireless router, and you’re connected to the wireless router, you’ll need to forward port 80 from the gateway to the wireless router first, and then configure the wireless router to forward port 80 to your computer. This is a complicated set-up, but hopefully isn’t too common.

Step 2: Preparing Your Test Facebook App on Facebook

Since Facebook doesn’t allow you to have a “dev mode” for your new application, you’ll need to create a whole new test application. Call it whatever you want. Make sure to give it all the same settings as your real app, except (1) Use the IP you copied in the last step for your server (plus any subdirectories you may be using), and (2) Make sure you pick a new name/canvas page URL for the test app. Most importantly, check the box that makes the app restrict adding to developers only (so random people can’t add it)!

When your app is successfully created, note that it has a different API key and secret key than your “live” app. Copy these values down somewhere.

Step 3: Coding Your App / Modifying Your App to Run Locally

If you haven’t coded your app yet, now’s the time to do it.

If you have, you’ll need to make a few changes to ensure it runs locally. First, replace your API keys with the test ones. Second, make sure that any references in the app to your live server are changed to your local server (for images, urls, etc…). Third, ensure that your database connection strings are valid for your local database.

…And that’s it! (One word of caution, however: given that your test app is, to Facebook, actually a different app than the live one, your app’s functionality vis-a-vis the “friends” system will be hampered somewhat. One way around this is to designate a few volunteers as developers also, so you can test multi-user behavior. Also, you will want to be careful with News Feed actions and stories, since these will actually show up on the live site, but may confuse your friends who see them.)

Anyway, you should now be able to add your test app on Facebook and Facebook will query your local server for its pages. You can make changes to the code and see them reflected instantly, without uploading anything. This is by far the most efficient way to develop, or continue development of, a Facebook app.

Step 4: Avoiding Dev/Live Sync Pitfalls

A problem exists, if you’ve followed the instructions faithfully: You now have two apps, one local and one remote, each with its own version of the code. Your well-tested local app now contains the newer (and better) code, but if you just uploaded it to the remote server, or committed it to your versioning software (I heartily recommend using SVN, by the way), you would overwrite all the live server’s settings, including API keys, local URLs, database connections, etc…

The best way to get around this problem is to extract all such settings to an environment file which is required by and parsed before all other scripts. In my environment file, I define PHP constants like API keys, database connection information, server IP, and so on. These constants will then be available for my app, and will be appropriate to the server at hand. This environment file should never be added to SVN or uploaded to another server, because it only pertains to its own locale.

With this technique, you can happily “svn ci / svn up” or FTP upload your code revisions from your local dev server to the remote live one, and they will take effect at that time, while still using the server’s own particular settings.


I hope that this tutorial has been useful. There is really no more efficient way to develop than when your local code changes can be tested immediately. But one reminder: if your internet gateway is restarted or acquires another IP address somehow, you will need to change the test app’s settings on Facebook (and any references of your own to that IP) to reflect this. Also, if you are traveling and using someone else’s internet, you’ll need to have access to their router to go through the steps above of ensuring port 80 forwarding to your machine, adjusting the test app’s server settings on Facebook, etc… Still, I have done this at a number of houses around the US, and it has worked like a charm.

Another alternative is of course to use a service like, which tracks your gateway’s IP changes and allows you to always access it using a certain domain name. If you do move around a lot, this could be a time-saving solution (though you’ll still need to pass port 80 to your box).

If you have any tips, techniques, or strategies of your own, please leave them in the comments!