[dotBen]

So we don't apply the caching stuff to the staging server because the purpose of the staging server is to stage content and test new plugins and themes.

We invented this feature in response to bloggers and site owners who wanted to be able to test a new plugin before adding it to the live/production version of their site. We're also the only managed WP platform to offer such a feature as standard with all accounts.

I can see that in a true dev/staging/production test suite environment, it does't stand up as a true mirror of product for the reasons you stated - but then neither does the staging/local version of Google App Engine or Heroku offer the same exact environment of their production platform.

If you need true like-for-like mirroring of production and staging, then yes, you need to create another WordPress instance - that's the case for most providers. Also its wroth nothing all WP Engine accounts, other than the Personal plan, come with multiple WordPress instances, so rarely that means actually buying anything further.

[benatkin]

The solution with Heroku is to create a separate app and use that. The app will be identical except for having fewer (and optionally different) resources. Because it's billed hourly, it doesn't cost too much to run it at full power for a short while to answer a question, before scaling it back down. The reason you needed to "invent" this feature is because your environment isn't as self-service as it could be.

[haldean]

This is not true for App Engine. You can create a "staging" version of your app and access it at staging.my-app.appspot.com. It all runs on the same infrastructure that your main version runs on, and it's easy enough to make it admin-only. Once your satisfied that it's safe to deploy, it's two clicks to change which version is serving.

You may be the only managed Wordpress platform to do so, but App Engine has had this functionality for a long time.