Pricing

I know right. If only WordPress sites didn’t need servers to run.

But today they do, so instead of ignoring servers and trusting someone else to handle them for you, why not learn more about servers and understand them better.

Put your blog on SpinupWP and see how that goes for six months or so. Then maybe move another low-risk site over. And then another.

With time, your confidence will increase and you’ll wonder why you were worried in the first place.

The promise of a managed WordPress host is so dang attractive. Pay considerably more for hosting and you get blazing fast WordPress sites and never have to think about hosting.

Unfortunately, that’s rarely the experience people have.

The truth is managed WordPress hosts like all web hosts are constantly working on scaling complicated infrastructure and tinkering with it. That’s usually why things go sideways and your sites go down.

With SpinupWP your sites run on one uncomplicated server that you control.

In our experience, having our own server that no one else is tinkering with but us has lead to a massive reduction in site downtime and hosting-related problems. But hey, give a managed WordPress host a try and hopefully you’ll be one of the lucky ones. 😬

Actually one server can handle a ton of traffic with full page caching enabled. According to our benchmarks a tiny 2 GB DigitalOcean server can serve 291 requests per second with an average response time of just 341 milliseconds.

Benchmarks are great and all, but what about the real world? Well, back when we were writing hip fresh blog posts, we had one hit the front page of Hacker News. Our 8 GB Linode never broke a sweat. In fact, there was no noticeable decrease in performance.

So as long as your site is like 99% of other sites out there, full page caching can be enabled and the server will handle a lot of traffic. If your site has dynamic parts (e.g. ecommerce) you can still enable full page caching for the parts that aren’t dynamic.

Probably not to begin with. That would be a big leap and what you need is a first step, a baby step. Spin up your first server with SpinupWP and try hosting your blog or some other low-risk site for six months or even a year.

Get yourself comfortable with hosting WordPress yourself and with time your confidence level will increase. Your only regret will be that you let fear prevent you from trying it earlier.

Web apps, other than WordPress, can be installed on SpinupWP servers as long as it works with our LEMP stack (Nginx, PHP, MySQL, Redis, etc).

This includes popular frameworks like Laravel and Symfony and CMSs like Drupal (with an Nginx config), Craft CMS, Statamic, etc. Any PHP/MySQL web app should work as well as static sites.

When creating a new site in SpinupWP, on the "Installation"step, select the Don't Install Any Files option (or Clone a Git Repository if your custom site is stored in Git) to create a site that can then be set up manually.

We realize that some similar apps charge per server rather than per site. In fact, we used to too. But there are important reasons why we felt we needed to change to limiting by site instead of by server:

Bad incentive. By charging more for additional servers, we would be incentivizing customers to cram as many sites onto a server as they can, leading to servers running out of CPU, memory, disk space, etc and a poor experience. Charging per site is better aligned with our advice to keep the number of sites per server to a reasonable level.

Value. If you take a step back and look at SpinupWP, most of the value it provides involves sites. Once you spin up a server, the rest of the functionality in SpinupWP is about sites. Configuring DNS, Nginx, HTTPS, databases, backups, etc are all site-based operations and almost all the features we plan to ship this year are site-based as well. Our costs are directly related to the number of sites you are running.

Fairness. When we charged on a per-server basis, we analyzed how many servers and sites our customers were running and we were surprised to see that some of our largest customers were paying very little. They were spinning up beefy servers and cramming dozens of customers onto them. Not only is this bad practice and against our advice (as mentioned above), but it is unfair to customers with fewer sites. For example, one of our largest customers was hosting 147 sites on 4 servers and paying just $24/month, while another customer had just 16 sites on 6 servers but was paying $34/month. Not fair at all.

Yes, each individual site counts towards your limit regardless of whether it’s a staging, dev or production site. For example, awesomesite.com, dev.awesomesite.com and staging.awesomesite.com would count as three sites.