Wordpress - Jetpack Running Locally

As of JetPack 2.2.1 there is now a local development/debug mode. http://jetpack.me/2013/03/28/jetpack-dev-mode-release/

use:

define ('JETPACK_DEV_DEBUG', true);

in your wp-config and you should have access to any modules that don't require a connection to function.

Update, since around v3.3 another local development trigger was added via filter instead of define.

Latest is now here: http://jetpack.me/support/development-mode/

Development mode automatically gets enabled if you don’t have a period in your site’s hostname, i.e. localhost. If you use a different URL, such as mycooltestsite.local or something, then you will need to define the JETPACK_DEV_DEBUG constant.

You can also enable Jetpack’s development mode through a plugin, thanks to the jetpack_development_mode filter:

add_filter( 'jetpack_development_mode', '__return_true' );

As of Jetpack v3.9 there is also now a staging mode filter that forces a site to be recongized as a staging site rather than production: https://developer.jetpack.com/hooks/jetpack_is_staging_site/

add_filter( 'jetpack_is_staging_site', '__return_true' );

The method in the link provided by @TracyRotton seems not to be working since Jetpack 2.0 and WordPress 3.4.2.

Even replicating all database fields, it doesn't act as connected.
jetpack database


As the OP question is about syncing a development and a production environments, maybe it is not possible.

I haven't tested in-depth which modules work and which not, but Jetpack can be tricked into believing it is connected making the following modification in the file /plugins/jetpack/jetpack.php.

Inside the class Jetpack_Data, modify the very first function get_access_token like:

class Jetpack_Data {    
    function get_access_token( $user_id = false ) {
        return 'USER_TOKENS-VALUE-FOUND-INSIDE-THE-OPTION-JETPACK_OPTIONS'; // <---trick
        if ( $user_id ) {
            if ( !$tokens = Jetpack::get_option( 'user_tokens' ) ) {
                return false;
            }

Or simply put a return true; instead of the user_tokens that we can copy from inside the option jetpack_options.

PS: the first version of this answer used another trick. Here, it is a one-line modification that catches all, in theory...


It is possible to trick JetPack by copying the database field values from an activated install into your local install.

On an install (remote) with JetPack connected search the wp_options table for option_name fields beginning with jetpack_, such as:

  • jetpack_activated
  • jetpack_options
  • jetpack_nonce_{random_string}
  • jetpack_active_modules

Copy these fields and values into your local installs database.

For more detail on this process see: http://www.ravendevelopers.com/node/57