New prices and plans for Flownative Beach

For the first time since we launched Beach we make adjustments to our pricing model, based on how our customers use Beach today and what is planned for the future. We added some plans, removed others and updated prices for most of them.

tldr; We love transparency, so I'm going to give you some insights into how our prices come to be. However, if you're only interested in the actual changes and not the background information, you can skip to "what we changed" further below.

The Guess Work

We use Google Cloud Platform as our infrastructure, and as you can guess, there are literally hundreds of line items on the invoices we receive from Google. Every service we use is split up into detailed positions which are charged by the byte, the microsecond or based on an algorithm. When we came up with our first concept for Beach plans, we could only guess what our customers would prefer and how costs could be turned into a fair pricing model.

One of our goals was to provide a feature-rich cloud environment for Neos and Flow, but without the uncertainty of complex price calculations. Therefore we had to guess many aspects of the costs we have in order to provide you with an easy and predictable set of plans. This worked out pretty okay, considering that we could only guess. But since we now have more customers, using Beach in very different ways, we need to make some adjustments so that Beach projects are more in line with the actual costs they produce on the infrastructure side.

Projects, Instances and Support

Our concept is quite simple: For a Neos website you need a project and one or more instances (for example, for production, staging and testing respectively) and optionally add a support plan, so you can page us on Sunday night at 3am.

The fees we charge for projects are used for running the general platform and for financing development and operations. The money coming in from the instance plans are roughly covering the actual costs which Google charges us for using their cloud. And finally, what comes in from our support plans is meant for motivating us to take the on-call shifts on weekends and at night.

Comparing Prices

One rather popular plan in Beach is the "Micro" project. For 19 € / month you can run a Neos site with cloud storage, backups, build pipeline and all that, and it works for many types of projects. One problem though is, that the margin we can generate for these sites is in the range of a couple of Euro cents (unless you submit a support questions, then it's … well, you get the idea). And since we don't have hundreds of projects in Beach just yet, it really doesn't pay off.

Now, if you compare this plan to, let's say, firing up a server at Hetzner or Uberspace, you might wonder, where our price tag comes from?

First of all, comparing Beach with plain server space would be a little unfair, because you get a lot more than compute power in Beach (but you already know that.) All the services which run in the background – for example the cluster, the build pipeline or backup system – generate additional costs for compute time, storage and services. Just running an idle cluster will cost a significant amount of money, because you'll need machines for Kubernetes, load balancers, monitoring, metrics, and all that. And on top of that, CPUs and RAM cost a lot more at Google, AWS or Azure than at Hetzner (see Google's price list).

So if already running the infrastructure part is so expensive, does it make sense to run small / tiny projects in Beach at all? Well, it depends … If you already have other projects running on Beach, or simply want a one-stop solution for all of your projects, so you don't need to deal with deployment, builds and all that again and again, it makes sense to pay that little premium. Or you decide to host those small projects yourself.

Do it Yourself

If you enjoy administrating servers and have the time to do so, you should be fine with renting a virtual machine and install your project manually. This is great, if you want to learn how to administer a server (and the project you're hosting is not super-important) and this is what a lot of us "senior" devs and admins have done for quite a while.

What a lot of people underestimate or ignore, though, is the amount of work you can put into providing a stable and secure environment for a web project. I once in a while get inquiries for trainings or coachings. People would like to learn "the cloud" and Kubernetes and then set up their own environment. Looking back at the amount of time I have invested into learning the ropes of Kubernetes, there are only few reasons for these folks to create such a solution themselves. Saving money is not on that list. 

Learning Kubernetes and all the related skills is a big investment (and probably a good one). But you could run dozens of Neos sites for many decades on Beach before this would pay off financially.

At Flownative, we use a lot of software-as-as-service products. For example, our help desk solution is an Open Source project and we have the expertise to host this ourselves. But it doesn't fit. We don't want to host Rails applications ourselves, this only distracts us from our other tasks. Therefore it's a no-brainer for us to book a managed solution and keep our heads clear for more important things.

Now this was a lot of text for some small details (but I felt like it was important enough to address this.) What in the world did we change, that needs such a long introduction?

What we Changed

Most importantly, project plans don't include a specific instance anymore. Instead, you pick a project and any instance type you like. For example, our middle project plan "Essential" was 79 € / month and included a "Production M" instance. Now "Essential" costs 49 € and an "M" instance is 29 €, which is 78 € in total.

We needed to raise prices of some project plans, based on which value they provide and what costs they cause. "Essential" now probably is our "best value for the price" plan.

The "Micro" plan has a lower Service Level Objective than the other projects. In practice that means that if cluster nodes run out of resources or need to be re-balanced, instances of Micro projects will be moved around first, which can lead to a short downtime. Nothing the average user will notice, but if you run an important project, you don't want even these minimal interruptions.

Instance types were simplified: Instead of the different variants "Prototype", "Staging" and "Production", we now only have types for different sizes ("S", "M", "L" and "XL"), all providing the features which were previously featured by "Production".

We adjusted prices of the large instance types to correspond with the raised costs on the infrastructure-side.

The organization plans were removed (what does an organization plan mean in the first place?). They were replaced by the new support plans which you can optionally book for your projects.

And finally, we included cluster plans for the first time (publicly.) If you are interested in a dedicated Beach cluster, just get in touch with us to discuss your needs (or if a bare metal Hetzner server would suffice.)

Thanks for Relaxing on the Beach

At this point, we'd like to thank all our Beach customers, who provided us with valuable feedback and patiently tested many of the Beach features while we polished them for the general public. 

Beach is still an exciting endeavor for us. Our goal was, and still is, to create a sustainable business which enables us to run and improve the platform for Neos we always dreamed of ourselves. We are grateful that we got this far and can't wait to make our plans for the next couple of months happen!