enters beta

TL;DR:, a hosted WordPress platform with focus on workflows, enters beta today. It brings revolutionary staging with database merging and we’ve got a great offer for the first 100 of you who subscribe, please read on.

Workflows are still an unsolved problem in WordPress

When we started working on VersionPress (WordPress + Git) in 2013, the problem we were trying to solve was this: after you spend some working on your site in a staging environment (or similar, like local dev), how do you push your changes back to the live site ? When I asked my WordPress friends, they usually had manual and not very convenient / reliable workflows like taking notes on paper and re-doing everything manually. The Mergebot guys have very similar observations.

Why is it that all these workflows are natural and well-supported in software development projects (via Git, GitHub, pull requests, push to publish, etc.) yet so hard to achieve in WordPress?

Because of the database.

Version control systems were created solely for files so no luck with MySQL there. As a consequence, workflows in WordPress are problematic and a concrete example is that most hosts will give you a staging environment today but won’t really help you get your changes live (replacing the production database entirely is a very scary option, in our opinion).

This problem is worth solving, and the keyword here is database merging. There are three key solutions today:

  • VersionPress, an open-source project based on Git.
  • Mergebot, a cloud service by Delicious Brains, based on SQL query recording.
  • staging.

Wait, what is that third item? Is that VersionPress or something new?

It’s something new.

It is database merging for which we’ve taken our experience from building VersionPress but created a new implementation with two key characteristics:

  1. It has much better compatibility with WP plugins – basically, it works with any WordPress site without VersionPress-like plugin definitions.
  2. Git is no longer required. We still use it behind the scenes but the WordPress sites doesn’t need to worry about it: it communicates via REST API with our backend services and the version control is transparent for them.

It is admittedly not as powerful as VersionPress but the compromise is really good: staging is about 80% as powerful as VersionPress but close to 100% compatible with various plugins. This is a big win and a great starting point for future improvements, with the eventual goal being full VersionPress deployment when it’s mature enough.

How staging saves work for you

A.k.a., a demo.

Let’s say you work on a site of a small coffee shop, something like this:


On, you get two environments for every site, staging and live. They are visualized like this in the management portal at and also inside WP admin (the beauty of React apps; use whichever context you like):


Each site also gets a clear indication in the admin bar so that you don’t confuse them:


Now let’s say that on the live site, someone updated the title:


In staging, we updated this title’s color in the meantime:


These changes were simple enough but already pose a challenge when publishing live: how do we get the orange color out without rewriting the site title again?

On, you’d press the Compare button. It scans both sites and shows an overview:


You can inspect each particular change if you wish and then press the Push button:


After a while (and a lovely arrow animation), you’ll see a confirmation that the push was successful. There’s also a button to Undo the changes easily:


Let’s check the live site. It indeed combines both of the database changes!



This is a basic example but you can already see its power and the nice thing is that the same workflow is applicable to basically everything:

  • Updating plugins
  • Merging content (posts) with other types of changes
  • Doing design updates in staging, having them signed-off by the client and pushing them live

It changes how you think about updating your sites, and we want to make the staging experience great to the point that you’ll never want to update your live site directly.

Note that this is our “v1” and many things can (and will) be improved, from visualizing the changes to iterating on the database merging technology. But even today, it is miles better than the traditional “would you like to overwrite your entire production database?” approach you see around the web.

Let us know in the comments below what you think about it.

Modern take on WordPress hosting

Apart from workflows, our other major goal was to build a modern infrastructure not for the sake of it but so that you and your site visitors can directly benefit from it. A couple of key technologies emerged over the past few years so here’s our stack:

  • Everything is based on Docker. This is important on multiple levels, from giving you a full access to your site (e.g., SSH) to being able to provide awesome local workflows in the future. Each site is a set of isolated, scalable containers while keeping the costs close standard shared WP hosts.
  • We’re running on AWS and utilize Kubernetes behind the scenes, it’s an awesome technology!
  • CDN is a natural part of the snappy hosted service and we aim to provide it in 2018.
  • We only support HTTP/2 & HTTPS as protocols as they are fast and secure.
  • Same with PHP 7, we don’t support old versions of PHP.

Simply put, we care about the infrastructure your sites are running on.

… and more

We come from a software developer background and spend most of our days in collaborative tools like GitHub so we’re naturally inspired to bring some of it to the world of hosted WordPress, because most of the same principles apply. has team features like collaborating on a site with your colleagues and clients, being in different roles when it comes to site access, creating “organizations” as a natural structure for agencies, etc.

Again, VersionPress in general is all about workflows so expect more features from us in this area in the future.

Special beta offer

The platform has privately launched late last year and has been powering several production sites since February. In June, we opened the door for a couple more early customers and now, we’re ready for public beta.

Beta means that you might still hit issues here and there but the service is reasonably stable. Note that we currently discourage e-shops and other complex WordPress sites because staging for them is quite challenging but it’s ready for business websites, blogs, presentational sites, etc. We expect the beta to run for a couple of months.

As a special thank you for helping us iron things out, we offer the first 100 of you 50% off the Developer plan for life – 10 sites for just $49 / month. It’s for life so you’ll keep this price even after the beta ends (after the first 100 seats are gone, there will still be this discount but only for the beta period). If you’re a WordPress developer or a small agency, we hope this helps ?


  • enters beta today. It brings new kind of staging with database merging.
  • The implementation is inspired by VersionPress but not powered by it (yet). It is slightly less powerful but on the upside, it has almost perfect compatibility with WP plugins and doesn’t require Git on the server. We think it’s a really good compromise.
  • Besides workflows, we care a lot about infrastructure – all is based on Docker, running on AWS and supporting only modern and fast technologies like HTTP/2, HTTPS and PHP 7.
  • The first 100 of you can get the Developer plan (10 sites) for 50% off for life; get it here.

Thanks for reading. Let us know in the comments below what you think and if you have any questions, we’ll be happy to answer them.

14 thoughts on “ enters beta

  1. Hi, Borek! Good to hear about A question: is it possible to have the staging of a site at and the live site out of it, at the actual implementation? Does works as that?

    1. Hi Paulo, both environments need to be hosted on We’re considering offering just staging as a service; technically, we’re not that far from being able to do that. Is that something you would prefer?

      1. Yes… Staging is a great challenge for developers and administrators. We are developing a site (our site) and looking for staging solutions. We need a staging site, where we can make the updates (content and configuration), let the administrators and quality assurance people have access, not being the real site. When the updates are approved, we need to move the updates to the real site. But we already have the real site (I think this is the common scenario for many people). So, we want to keep our site at the URL we already have and have another URL just for staging. This is the “ideal” world for us. If you can offer the staging as a service, with controlled access, and with the possibility to update to the real site, I will be the first to contract you. Is it possible to copy the real site to the staging site using Thanks for your attention…

        1. Well, you could keep your live URL, just switch hosts 🙂 No, I understand what you’re saying. One challenge of “staging as a service” is that the database merging is hard enough even when we have everything under control and having to deal with various configurations of 3rd party hosts will not make it simpler. But thanks for describing your use case, this will help us plan for the future.

          1. Thanks, Borek. Sorry to make so many questions… Is there any intermediate configuration we could make between what offers and what I described as desirable for our site? Could I redirect my URL to the live site at How I could keep my URL and use the facilities of

          2. I’m not sure if I fully understand but if you moved your site to, you’d keep your site’s domain / URL so the site visitors would not know the difference. Once the site is on, it gets both the live site and the staging environment. Currently, it’s not possible to host your site on your current host and have only the staging environment on Does this clear up things a bit?

          3. Yes, it clears… More questions: Does subscription include backups for the sites or I need to schedule and do it for myself? Is it possible to do a backup of the site and download it? How the site growth (in terms of storage area and CPU use) is billed? Is there a limit to Docker server to support? How a site growth will be considered in terms of billing? Regarding the site’s domain, is it possible to host a site with a domain from other country (not US)? To create the staging site for the first time, is it possible to upload the entire site to this environment and after transfer it to production (live)? Thanks…

          4. Hi Paulo,

            Sorry for the delay, here are the answers to your questions:

            1. Backups are included. We actually have three levels of them: a system image level, then regular ZIP-like backups and then a custom incremental backup technology that overlaps with our staging functionality (this stores backup in a highly efficient but proprietary format).
            2. We can send you the ZIP of the backup or you can export the site using any of the standard WordPress methods or plugins out there.
            3. For now, we have flat billing and ask you to keep the site within reasonable limits – tens of thousands of visits per month as a general guideline. We’ll make this clearer on the website and in the Terms of Service. As we expand to support larger sites, there will be more expensive plans / overage billing but we don’t offer that during the beta.
            4. Could you please explain a bit more what you mean by “Is there a limit to Docker server to support?”
            5. We don’t host DNS so you can use any domain provider and just point your domains to our servers – this works for any domains, including non-US ones.
            6. It is possible to use staging for site migrations, yes, and people actively do this. However, diffing a migrated site with the default WordPress install usually leads to large diffs so it’s generally better if you migrate to the live site directly. If you have any doubts, we’ll be happy to help with the migration.

            Hope this helps,


          5. Thanks a lot for your answers. Regarding my question “Is there a limit to Docker server to support?”, my concern is that Docker is a virtualization schema and each “machine” has limits for memory, CPU, processors from the entire machine. For the hosting offered, is there any limit already defined in these terms for the contracts, that will limit the usage of the site? In other words, if is going to use Docker as the base for virtualization, which are the limits we need to conform for the usage of the site? Sorry if it is not clear… the concern is: if I move my site to, how heavy traffic and usage the Docker machine will support considering the baseline contract? Is it defined in the contract we sign with

  2. Echoing Paulo’s last questions + aspects like charging for metrics–site visits, hits, volume of data. That sort of info would make it easier to consider your offers! TIA.

Leave a Reply

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

Some HTML tags are supported