Hey everyone!
I’m quite new to Ghost by would like to make it my #1 solution for blogging.
Previously I’ve worked on WordPress where we’ve (company) used a staging environment to first roll out any changes and then deploy it to production.
I wanted to ask whether there’s a simple way to do that on Ghost.
And if there’s no easy one, is there any way to do that?
Thanks!
Welcome here, JKL 
Simple is such a relative concept. Can you please share more details about your typical or preferred development environment?
Thanks for the answer 
Yea, you’re right. By “simple” I mean the easiest way from a non-technical person’s viewpoint.
I’m currently using Ghost Pro (Standard) and would love a solution to test the theme changes without having to upload a new version of the theme over and over again.
I searched high and low, and could not be happier with Fast Comet for its simplicity. Here is a writeup on my experience (in short, dirt cheap, dead simple, blazing fast servers, cPanel, web-based File Manager, and very responsive tech support):
https://ghost-o-matic.com/my-ghost-dev-tools/#fastcometsharedhosting
Thanks a lot! It seems like a good place to start (and maybe end).
[edited 2019-09-27: added v and n flags to the cp command to provide a verbose description of what’s happening and to not overwrite existing files; added explanation of how to disable staging afterwards]
As a Ghost newbie and fast fan, this feels like a very under-served topic, and warrants a bump.
After searching far and wide for some guides and coming up short, I rolled the dice on an idea and am fairly satisfied with it. To wit:
I created a staging environment by pointing staging.mydomain.name at the same IP as www.mydomain.name, and then simply following the install instructions a second time. Essentially I was able to say “yes” again to all the setup questions.
I then copied over the useful content (which amounted to just images):
sudo cp -vnpR /var/www/production-site/content/images /var/www/staging-site/content/
Then, somewhat surprisingly, used the Ghost Admin interface to copy the database via export/import: Admin → Settings → Labs → Export/Import. This produced 3 warnings, which all seem benign. Two were “User: Entry”, which warned that the duplicate entries for the Ghost user and my initial user would be ignored, and the third warned that Themes would not be imported.
That resulted in a staging.mydomain.name which was visually identical to www.mydomain.name. I’ve then been able to make all my experimental changes in the staging.mydomain.name Admin interface, before copying them to www.mydomain.name. Once done with staging, disable it by running ghost stop --disable in the install directory (the disable flag prevents it restarting next time you reboot). You’ll be left with a “502 Bad Gateway” error if you try to browse to the staging URL, but that doesn’t seem like a big deal to me.
Initially I thought my experimentation would involve installing a custom Theme, which I was confident doing because Themes are just files on the file system, plus the selection in the database, both of which could be easily synchronised back to production. In the end it turned out my initial experimentation only needed to use Code Injection, which is even easier to synchronise back to production.
So certainly not a full blown CI/CD staging pipeline, but in my mind meets the “easy” requirement nicely!