Using SpinupWP as a development server

SpinupWP is a modern cloud-based server control panel. It gives you the features of a managed WordPress host on your own low-cost and scalable Digital Ocean servers.

It’s a great choice for production sites, and I host many of my personal sites there. It also makes an excellent development environment.

My development server requirements are:

  1. Blazing fast. Most of my clients hire me to make their site faster, so my dev server should be optimized for speed.
  2. Scalable. I can easily scale up and down the size of the server based on my current needs.
  3. Reasonably priced. I want to keep my hosting costs minimal.

I’m currently using a $15/month droplet with 3GB of memory and 60GB of storage. When you add in the $9/month for SpinupWP, my total hosting bill of $24/month is less than most managed WordPress hosts for a single site.

$50 credit for SpinupWP

If you sign up for SpinupWP using the link below, you’ll get a $50 credit added to your account after 30 days.

Sign up now

My preferred development approach

I use git to version control the custom themes I develop. When I’m ready to push my local changes to the server, I type git push staging master. I also use WP Migrate DB Pro to push/pull the database between environments.

For my clients hosted with WPEngine or BigScoots, I use their built-in staging environments and git-based deployment. For more information, see my articles on git for WPEngine and git for BigScoots.

If a client is hosted elsewhere, I use SpinupWP to replicate the same git push development workflow and features.

Setting up a development environment

Once you have your SpinupWP server setup, it’s easy to add new sites. I have a domain I use for development sites, with each site being setup as a subdomain.

Log into the SpinupWP Dashboard and click the “New Site” button. Create a fresh WordPress install (here’s a guide).

Install WP Migrate DB Pro along with the Media and Theme & Plugin addons on the production site and the new development site. Pull a copy of the database, media, themes, and plugins to your dev server. Alternatively, you can copy the site files over via SSH.

Set up git on the server

  1. When you ssh into the server, you should already be in the site directory. Typing ls should list /files and /logs
  2. Create a bare repository. git init --bare project.git
  3. Create the post-receive hook. touch project.git/hooks/post-receive
  4. Add execute permissions to the post-receive hook. chmod +x project.git/hooks/post-receive
  5. Edit the post-receive hook (vi project.git/hooks/post-receive) and add the following to it. Make sure you update the two paths at the top to match your environment
#!/bin/bash
TARGET="/sites/clientname.cultivatewp.com/files"
GIT_DIR="/sites/clientname.cultivatewp.com/project.git"
BRANCH="master"

while read oldrev newrev ref
do
        # only checking out the master (or whatever branch you would like to deploy)
        if [ "$ref" = "refs/heads/$BRANCH" ];
        then
                echo "Ref $ref received. Deploying ${BRANCH} branch to production..."
                git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f $BRANCH
        else
                echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed on this server."
        fi
done

In your local environment, add the remote:

git remote add staging ssh://[email protected]/~/project.git

Local environment, no media

A lot of the sites I build have massive uploads directories. To save local hard drive space and simplify database syncing, I don’t pull any of the media down locally.

I’ll use Migrate DB Pro to pull down a local copy of the database, theme and plugins. I’ll then install BE Media from Production and use it to source media from the development server. You can install and set it up with wp cli:

wp plugin install be-media-from-production --activate
wp config set BE_MEDIA_FROM_PRODUCTION_URL https://clientname.cultivatewp.com --type=constant

One of the first things I do when building a new theme is determine all the required image sizes. After adding the relevant add_image_size()‘s to the theme, I’ll push the theme and database to staging and regenerate thumbnails. I can then pull a fresh copy of the database locally and have access to all the newly generated thumbnails.

Likewise, if I need to upload new images, I push the database to staging, upload the image on staging, then pull a fresh copy of the database locally.

Bill Erickson

Bill Erickson is the co-founder and lead developer at CultivateWP, a WordPress agency focusing on high performance sites for web publishers.

About Me
Ready to upgrade your website?

I build custom WordPress websites that look great and are easy to manage.

Let's Talk

Reader Interactions

Comments are closed. Continue the conversation with me on Twitter: @billerickson

Comments

  1. John C Swaringen says

    This article could not come at a better time for me. I just got the “renewal” notice from Siteground and since this is the second year they’re wanting $415 for one more year. Incredible…

    This is a great package. Oh, the package is up to 19/mo after the 1st 3 months. Still, that’s half the price I’m paying for Siteground and a ton more features.

    Thanks, Bill. You’re helpful as always and I appreciate your articles. Keep it up.

    • Bill Erickson says

      Happy to help!

      I was in the exact same situation. I had a SiteGround account that was up for renewal, and I wasn’t really happy with speed or setup over there.

      I’m not sure how many sites you’re looking to host, but the $19/month plan if for up to three separate servers. The $12/month plan is for one server. All of the plans offer unlimited sites on your servers.

      If you’re hosting a bunch of personal and dev sites, having everything on one server should be fine. If you have some large and complicated production sites, you might want to put them on their own server.

  2. Jonathan says

    I loved WP Engine Devkit for local development, but I found out today they are shutting it down.

    • Bill Erickson says

      That’s part of the reason I don’t want to be tied too much to a particular host’s tooling. I don’t want my entire workflow to be dependent on a feature at a specific host.

      The approach outlined above works on any host that includes ssh access, and matches the feature set of WPEngine’s git push.

      If a client is hosted at WPEngine or BigScoots, I use the host-provided staging environment for development. If hosted elsewhere, I use SpinupWP. In all cases, my code deployment approach is exactly the same: git push staging master.