GridServer implementation using NginX Server Blocks, and gitlab.

Posted May 2, 2014 3.7k views
Goal is to run a setup similar to Media Temples GridServer using NginX Server Blocks optimized with varnish for lightning Wordpress installs, all under structure, while also housing gitlab under This is branching off my other question: Ideal end goal is to: 1. Have a main wp install on (company site) 2. House all "staging" sites under #1, as 3. House gitlab on 4. Gitlab would house all "staging" sites in individual repos 4a. Is the best method for the repos to hold the whole site including core, themes, plugins, etc. like pagodabox does or house only say a vagrant/composer setup so the repo is lightweight - but what about the theme files? 4b. When pushing to these repos should they auto deploy changes similar to pagodabox/heroku? 5. Separate droplets created from snapshots of "staging" site for "production" sites, which im not even sure thats currently possible since the snapshot wouldnt be able to target individual blocks.. 5a. Would it then require an image ( say NginX/wp/php/varnish/vagrant setup ) to launch new "production" droplets, and then import dbs and themes/files/uploads? Seems like there would be a better option, especially for when making updates. I know this cover a lot, trying to figure out the best method for staging/prod deployments while keeping a revision history (git repo) and making sure everyone has an exact copy of environments/dbs/dependancies (vagrant/composer). Any help would be much appreciated! -CK

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
4 answers
It sounds like you're up to some cool stuff! I'm excited to hear what deployment ideas people come up with.

The first thing that jumps to my mind is regarding 4b. I'd personally set set up automatic deployment after each git push to the gitlab instance. You can setup a post-receive hook that deploys to the different environments based on the branch. That way when you're ready to deploy to production, you can just merge master into a production branch. Something like:

while read oldrev newrev refname
branch=$(git rev-parse --symbolic --abbrev-ref $refname)
if [ "master" == "$branch" ]; then
# Deploy to staging
if [ "production" == "$branch" ]; then
# Deploy to production


As far as Wordpress specific things like whether to check in the whole site, there are lots of opinions out there. Some interesting things I've come across:
Thanks for the reply Andrew!

Had a look at those links, and Im familiar with the auto deploy script/post hook having used that with bitbucket, but didn't like the fact that I couldn't deploy based on branch rather than always, so thanks for that bash script, thats pretty nifty!

Came across, bedrock ( ) which is interesting but doesn't yet support Vagrant or a method of syncing dbs, but the closest Ive come across that implements pagoda/heroku is the dokku app.

1. What are your thoughts on easyengine ( ) or puphpet ( ) ?

2. Back to implementing gitlab as a nginx server block @, is that ideal/practical compared to having the under its own droplet?

3. I love the idea of setting up a boilerplate so to speak, and creating a snapshot from it to easily create new projects! If using vagrant, however, you mentioned there might not be a need for it. If not using vagrant, would the best method for keeping teams in sync be to launch the droplet from the image, setup the wordpress install on the remote first, then pull it everything down w/ a sql dump?
Will you make tutorial after you done with this? My idea was very close to that. So:
- for main site
- gitlab on
- development part

But somthing what i want to make to move gitlab main repo folder from there original location to location. In that case i don't need any hook. Master branch will be always in sync with dev. Can someone help with this?
ckiriaze do you have new informations about this?