Local Sync: a simple way to deploy your localhost WordPress website

You build WordPress websites on your computer because it’s the fastest and most secure way. Deploying it to the live server, however, is stressful and time-consuming. Luckily, Local Sync helps you deploy your localhost website with ease.

You build WordPress websites on your computer because it’s the fastest and most secure way. Deploying it to the live server, however, is stressful and time-consuming. Luckily, Local Sync helps you deploy your localhost website with ease.

What’s Local Sync?

Local Sync takes care of all the hassle that comes with syncing the latest version of your website between local, staging, and live environments. It helps you effortlessly move the latest version of your website between the localhost environment and live environment, doing in minutes what would manually take you hours.

There’s no desktop app or port forwarding needed. Just open your localhost website in a browser, and Local Sync takes care of the rest.

How can Local Sync help me?

WordPress website development on localhost is the fastest way to get things done, since it’s fast and you can work offline. Once the localhost website is ready, Local Sync will copy the site from local to a website server. There you will spot any issues that would not show up in the local environment.

Local Sync works both ways. Let’s say you just got a new client and their website needs some work. You don’t want to wreck the live website, so you use Local Sync to push the latest version of the website to a local environment. Once the work is done, Local Sync will deploy the changes back to the live website.

Local Sync can:

  1. Sync differences between a website on your local computer and the one on a website server
  2. Deploy a website from your local computer
  3. Sync websites on different website servers

To get Local Sync to work, you just need to:

  1. Get your localhost WordPress website up and running
  2. Install and activate the Worker plugin

Local Sync will take care of the rest. It’s so straightforward, you’ll wonder why anyone in their right mind would deploy a localhost website any other way.

How is Clone different from Local Sync?

Clone relies on backup archives to get things done. It’s slow but very reliable.

Local Sync, on the other hand, skips the “create a backup in cloud storage” step and transfers the website content straight to the destination website:

Local Sync is essentially a lightweight version of Git Push command, where existing websites act as repositories.

Local Sync is currently in beta. With so many different server setups on the web, it is impossible to test them all in advance. That’s why we need your help.

Go to the Local Sync page on your single site dashboard, play around with it, and try to break it. Send us bug reports, but also your feedback – both good and bad. Help us turn Local Sync into a valuable asset.

Local Sync roadmap

We want to go above and beyond the Git functionality – you choose which files and database tables you want to sync. More importantly, we want a world where you make changes in staging and push them to a live website without any stress, in under a minute — and with no data loss. You gotta admit that it’s a great goal to have!

Nemanja Aleksic

Head of Growth at ManageWP. Marketing Manager at GoDaddy. WordCamp Belgrade organizer. But first and foremost, a father, a husband and a puck stopper.

20 Comments

  1. Kyle Charlton

    I tried the app today, it was very simple to use and fills in the missing gap between live and local development. I did experience one bug where single word page titles such as “Home” , “About”, “Contact” became lowercase title “home” , “about”, “contact”. Pages with 2 or more words were not affected. Very excited about this app.

    1. Marko Tanaskovic

      So glad to hear that you like our new feature Kyle.
      I’ll make sure that someone looks at this particular issue although it should not be related to Local Sync working mechanism.
      If you have any ideas for improvement, please share your thoughts via the ‘Send feedback’ option within the dashboard. They will be greatly appreciated.

    2. Kyle Charlton

      Disregard my comment above, I had tried a different system called “LocalSync” not “Local Sync”

  2. Jurre

    This is great! Thanks for this update and let’s make it a good one 🙂

  3. Tim Martin

    This is a fascinating idea. I develop WordPress sites locally using Laravel Valet and Nginx. I’ll run some tests later this week and see if I can break it.

  4. Luther Adams

    How do I test this in beta, I cannot see the option in my dashboard. Thank you.

  5. Vladi

    Great Goal? That’s like a dream coming true 🙂

  6. Jean-Francois Arseneault

    You mention on the feature page “Smart database merge, so you won’t lose any database entries that happened in the meantime”

    I’m curious how / if you’ll be able to solve this, given others have tried it and failed : VersionPress, MergeBot, etc

    The issue becomes : How can you reconcile new “local” posts/postmeta using a given ID, with the fact that given ID might have been used in the “live” environment. Perfect example would be creating a new page in “local”, but the client has published a new blog post in “live”, therefore creating a potential collision… and how can you avoid this while ensuring all post_metas are kept in sync, should you change on of the post_id ?

    1. Nemanja Aleksic

      Author

      We should be able to detect a conflict, i.e. different products under the same id. From there we need to determine every place where this id is referenced, give on of them a new id, and search and replace the database.

      Now, this makes it sound straightforward, but the actual reality is much harder, and it might take a lot of work to get there, but it’s not impossible.

      The only real hurdle is the lack of WordPress coding standards, where each plugin could potentially be a liability.

      1. Leonardo Gandini

        This will definitely be THE killer feature since almost nobody merges DBs without losing something. So at the moment is not possible right?
        If a client publishes a post on the live site, the local DB push will replace it, right?
        Is exciting to see this new Local sync, and I can easily see the same application but to a non-local website. This way we can have some sort of Local Stage – OnlineDevStage and OnlineLive.

      2. Borek Bernard

        Hi, one of the authors of VersionPress here.

        The approach you have outlined, Nemanja, means that Local Sync will need to have _perfect_ semantic understanding of all plugins and themes and their data structures, otherwise the sync will not be reliable. Well, reliable may be a weak word here as replacing `123` -> `124` in the database _and not being extremely careful_ might lead to e.g. changing a price of something.

        That is “unfortunately” the nature of database merging in WordPress and every tool trying to do it will face the same challenges. At the same time, I think it’s a very noble goal and I applaud you for trying. I would also like to offer our expertise in this area if you or your engineers ever want to discuss anything; the topic is a passion of mine and I’ll be happy to help. Feel free to reach me at borekb@gmail.com.

        Thanks,

        Borek

        1. Nemanja Aleksic

          Author

          I agree – while on paper it may sound straightforward, in reality it’s a ton of work.

          Will reach out to you in due time to see how we can help each other out. Thanks for being so open about it!

      3. Brad Touesnard

        This is the approach we took with Mergebot, but we ultimately ran into a chicken-egg problem.

        We needed lots of people to use it and to contribute plugin schemas (describe how the plugins store their data) to make it more reliable. But few people were willing to use it because it wasn’t reliable.

        Ultimately we found people weren’t willing to analyze their plugins and come up with schemas for them. And who could blame them? It’s a lot of time and effort and not fun.

        I had a chat with Boris about Mergebot earlier this year. Let me know if you guys would like to chat again.

      4. Patrik Alienus

        This would be absolutely lovely if it worked, but I’ve been burned by these types of features before that I would be scared to use it. Even WP Engine’s StagingLive doesn’t always work, and that simply replaces everything.
        I’d rather just replace the DB altogether and add in changes afterwards. Usually when starting a project on an existing site, I tell the client to log all changes they make to posts/pages, so that we can re-add them afterwards.

    2. Borek Bernard

      Just for the record, VersionPress is still the only existing solution that actually does database merging and we feel pretty much alive 🙂 It’s true that the open source project didn’t receive much love in the past year or so but the basics are solid and we have quite a few individuals and agencies who depend on it in their day to day work. By my estimates, VersionPress will require something like 20 man-years of work; we have invested roughly 7 into it and are working hard to be able to fund the next 12 (that is, man-years, not calendar years 🙂 ).

      1. Borek Bernard

        (It would also help if I could add up two numbers 🙂 )

    3. Vinodh David

      Hello, Founder of WPMerge here. We have been working on this problem for almost 2 years now and we have cracked the processes without using Database schema. It has been not a simple ride but we would also be glad to discuss more on making this happen with Local Sync if ManageWP is open 🙂

  7. Morten Ellegaard Larsen

    I can’t get my hands down, this is like a wet dream to me! 🙂

    I haven’t tested it yet (my hands are still up in the air), but this function is what I have missed. I my first born hadn’t moved out, I would have shipped him right away.

    1. Nemanja Aleksic

      Author

      Don’t forget to send us feedback once you test it!

    2. Paul Beck

      I’m anxious to see this work. I tried to dump my operational site to my localhost dev site, and it destroyed my database. I had to re-install WP, add in UpdraftPlus plugin and restore the database from my last Updraft backup. I tried it three times, and it failed all three times in the same way. I’m not sure what I am doing that differently that would cause it to totally destroy my local database. My local URL is 192.168.1.11/asa. I use the fixed I/P address so I can access my local instance via other devices on my LAN. My operational site uses many custom DB tables. Perhaps that is a contributor.

Leave a Reply

Your email address will not be published. Required fields are marked *

Over 40,000 WordPress professionals are already using ManageWP

Add as many websites as you want for free, no credit card required. Sign up and start saving time!

Have questions? Get in touch!

Over 40,000 WordPress professionals are already using ManageWP

Add as many websites as you want for free, no credit card required. Sign up and start saving time!



Have questions? Get in touch!

Over 40,000 WordPress professionals are already using ManageWP

Add as many websites as you want for free, no credit card required. Sign up and start saving time!



Have questions? Get in touch!

Over 40,000 WordPress professionals are already using ManageWP

Add as many websites as you want for free, no credit card required. Sign up and start saving time!



Have questions? Get in touch!