ANSWER: Yes, we offer free staging sites via our partnership with WP StageCoach. These staging sites are hosted remotely to maintain the highest level of speed and security for our clients’ production servers. You should know that these staging sites are meant for short-term testing of new features and so forth, and are not free long-term hosting of any sort. If you stop logging into your staging site after around 3 weeks, it will be automatically deleted by WP StageCoach in order for them to keep their system slim and also for privacy/security reasons.
LINK (E.G.): https://www.littlebizzy.com/wp-admin/admin.php?page=wpstagecoach
While certain managed WordPress hosting companies like to overload their system with various features, at LittleBizzy our top priorities are speed, stability, and security. Enabling staging sites on the same servers as origin sites means also enabling multiple MySQL databases and/or multiple WordPress installations, multiple (sub)domains, and so forth. As our web hosting network assigns each client their own dedicated IP address and cloud VPS server, offering i.e. dev.littlebizzy.com also would not work either. In line with our philosophy, we recommend you properly compartmentalize and instead use an off-server solution such as WP Stagecoach if you truly need a staging area (or use a cheap shared hosting company for staging i.e. HostGator). Ultimately, we believe that on-server staging environments are a poor idea that jeopardize security and rarely (if ever) get properly cleaned up or deleted when they are finished being used.
Update: We no longer provide staging sites of any kind:
Another more recent trend is to use a single Git repo (such as GitHub) for each domain’s development work. For example, for example.com you could launch a new repo (public or private) and then create a “branch” for each “stage” in your dev workflow, such as A) dev B) staging C) production. From there you can use LittleBizzy server as your production server, and sync back and forth with your repo and/or staging server as appropriate. Do be aware that WordPress Core files are always managed by our system, and most of the time your plugins shouldn’t be included in your repo either (because they don’t get customized by your team). Instead, it has become a typical workflow to only keep your custom WordPress theme in the repo, along with any custom functions your site uses in functions.php (in your theme directory).
Our forthcoming “pseudo-fork” of WordPress Core called Shelby (similar to Roots’ Bedrock boilerplate) is also going to be managed/installed/updated by our servers, so again just make sure you are only working on your theme files (or any custom plugin maintained by your team) and nothing else. And of course be sure not to expose your config details such as database passwords in wp-config.php in any public facing Git repo.