Why We Built It (2023 Edition)

When we publicly launched the WPCloudDeploy project we wrote a lengthy article about why we built it. A lot has changed since then and that article was written from the perspective of a reader circa 2020.

So we figured it’s time we wrote an updated article that would make more sense to a new 2023/2024 reader.

Searching And Not Finding The Ideal…

Back in 2019 we started the WPCloudDeploy project to scratch a private itch. We were looking for something we just couldn’t find from standard hosting providers. We tried most of the big names such as WPEngine, Kinsta, Flywheel and more.

In that pre-covid era, SpinupWP and Gridpane were relatively new services and we also tried them out. They were much closer to what we were looking for, but still not quite right.

Out of all the services available (managed or semi-managed), we felt that those two would eventually get to where we wanted but we also knew that it would take way too long since their development priorities would not necessarily be our priorities.

So, as developers usually do, we figured we’d build what we were looking for.

---

That’s it in a nutshell – that was our decision to build.

Now that you know why we decided to build the thing, here is some more information about the journey and our thought process.

Arrogance

Looking back now, we have to admit that our arrogance in making the decision to build this ourselves was staggering.

As you might expect, we bit off more than we could chew – by considerably underestimating the task we had taken on. A 30 – 45 day project turned into six months as we rapidly expanded the project scope.

Our Requirements & Scope Creep

We started off with a very small list of requirements.  But, by the time we were done after six months, we had created a very very long list.  Here are some of the major items that we ended up including on the list:

• Hosting in our accounts at our choice of cloud server providers – this meant that no matter what, our servers and data belonged to us. And if we negotiated special volume pricing or got other deals, the cost benefits would flow to us and our customers.
• The panel should allow for each server to run multiple isolated WordPress installations.  While each cloud provider could quickly spin up a server instance of any size with WordPress, you ended up with only one WordPress instance on each server and a lot of hoops to jump through if you wanted to deploy a second site.  So our panel needed to make that a lot easier.
• Ideally, the management panel itself should run on WordPress – WordPress provides a lot of flexibility and, by running on it, we can use our favorite plugins and existing coding knowledge to easily tweak things to our way of working.
• It should have a command line option.
• It should be easily extensible. (If it ran on WordPress, this would be a given.)
• It shouldn’t treat us as beginners – in other words, expose and offer the advanced things that we might need – without forcing us onto the command line all the time.
• Be cheaper than the existing options out there – not on a single site basis but on a multi-site basis since we handle many sites.
• Be flexible – we wanted to be able to sort, filter and query our servers and applications list by any dimension.
• Secure – it should have only our keys and our cloud providers keys on the server. This one was non-negotiable. We might be flexible on some items above but this one was the most important for us.
• Support – we knew if we built this we would have to support it ourselves. So we wanted to make sure the tech stack was something that most sysops would be comfortable trouble-shooting.
• Speed – We didn’t need the most blazing performance on the planet if it meant creating a custom stack that few sysops could handle. We were willing to take a ten percent hit compared to the best performance we could get if it meant something more mainstream could be used.

The WordPress Development Platform For The Win

As WordPress developers we decided to build the entire thing as a plugin. Given all the advantages of the WP platform and our WP experience, it made sense for us to start there.

Which was a radical decision – even to this day. Building something like this on WordPress had never been attempted before.

Coming A Long Way

Once v1 was built, we quickly realized that others might want the same thing which lead to the project being opened up to the public as well as the source eventually being published and managed on github.

Even now, WPCloudDeploy is the only dedicated WP Control Panel that is 100% open-source.

Since 2019 we’ve added hundreds of features including support for multiple web servers, a front-end UI, additional server providers, WooCommerce integration and a mini-crm.

Anyone Can Use It For Free

If you’re new to WPCloudDeploy or still exploring your options, you can quickly try most of the features by deploying a pre-built DigitalOcean droplet.

Or, if you’re more developer focused and want to get down into the weeds, grab it from github and install it on your own server.