The Upsun origin story: the evolution of a PaaS

Upsun is the newest offering from Platform.sh, based on the existing container-based architecture of the Platform.sh PaaS which has been active for almost a decade, managing several thousands of applications for its customers worldwide. Upsun comes with a completely revamped usage-based pricing model designed to provide the flexibility needed for decoupled- and composable-architecture projects. For our team, Upsun is the most important launch from Platform.sh since the company’s inception and we cannot wait to share it with you. 

Platform.sh: remedying the fear of deployment 

Before we dive into the Upsun PaaS product, let’s first take a step back into the past and take a look at the journey of Platform.sh. In the very early days of Platform.sh, around 10 years ago, the cloud and application infrastructure were always in the way of developers achieving what they wanted to. To keep up with competition and customers’ ever-growing expectations, regardless of your application’s goal, iterating fast is paramount. But if iterating means breaking production a couple of times a week, you quickly become very fearful of doing it at all. So we wanted to solve that: this fear of deployment. We set about making the cloud as simple and robust as possible with a focus on this exact use case with Platform.sh: big ecommerce applications with high-traffic, content-heavy CMS-based websites. 

One of the biggest challenges, somewhat specific to these use cases, is that you need preview environments to have non-synthetic data to do robust testing. Testing a content-rich application or an ecommerce solution with a catalog of a million items and thousands of concurrent shopping carts is not the same as testing it with a couple of test items. Just as testing a huge complicated content website is not the same as testing a few pages worth of Lorem Ipsums. 

So we created our cluster cloning technology that allowed us to provide preview environments on the fly, that are perfect copies of production, in just a couple of minutes. We built it so it runs precisely the same way on any underlying cloud infrastructure. Today, Platform.sh runs on top of AWS, Google Cloud, Azure, OVH Cloud, and Orange cloud. We built everything a large content or ecommerce site would need, fully integrated into our offering. An efficient, secure, reliable PaaS that allowed developers to continuously integrate and deploy without fear—even on Fridays. 

Developing a series of interesting PaaS technologies  

As the Platform.sh PaaS evolved, we developed a series of innovative technologies. Including our multi-cloud, hyper-dense regions through our streaming WAF and all of the automation layers that allow organizations to run hundreds of applications simultaneously while keeping them updated and secure. 

We also made our offer simple. With clear t-shirt size plans available: small, medium, large, XLarge, and 2XLarge. And if you ended up getting more traffic: just level up. No need to think about anything else, it all just works. 

When we first started working on Platform.sh, we wanted to ease the life of software developers that were managing infrastructure. And possibly due to our roots, we built it all on high-level abstractions. Containers before Docker was even a thing. Descriptive Infrastructure as Code (IaC) before it was even called that. All of this meant that early on when our customers, particularly agencies that often use different stacks for their different customers, would ask whether they could use Platform.sh for Symfony, Node.js, Rails, Elixir, or Django—we could say yes, of course. 

Headless ecommerce and CMSs were also all the rage at the time and so we had to ensure that running multiple application services in a cluster was something our PaaS was good at. If the initial use cases of Platform.sh were running just a couple of applications—a static head with a backend—abstractions were important. So we weren’t going to hardcode a limit. One app, two, a couple dozen: the primitives are the same.

Thanks to our ecommerce origins, we were great at managing the persistence layer—from a compliance, performance, and consistency standpoint—and ensuring backups enabled users to get back to business quickly. We found that these capabilities were very useful to our users, regardless of their chosen tech stack. It seems people running game backends care about not losing a high score just as much as merchants care about not losing their record of a sale.

Simplicity isn’t universal: the start of the Upsun evolution 

A few years into running hundreds of diverse applications with Platform.sh, we realized that our simple, t-shirt-size approach was perfectly suited for most CMS and ecommerce projects. However we needed to go further and grant users with more flexibility in the resource-allocation process, particularly for applications built on decoupled and composable architectures. Enabling them to have greater control over their resource allocation for each component of their project and to scale those components independently based on their project’s needs.

The plans we sold with Platform.sh were simple: a cap based on the maximum amount of CPU and RAM for the production environment. We would automatically fit the biggest size of each container type (within the plan’s limits) into these plans. Preview development environments had a different behavior. Instead, we simply made every container the smallest we could. It was simple. And it worked. Mostly. But as we figured out with time that for some types of applications this plan started breaking. Sometimes it was just a bit awkward and sometimes it meant that there were workloads that were a technical fit but we couldn’t run in any reasonable way.

We discovered that simple is hard; what might afford simplicity in one use case may make another use case horrendously cumbersome. CMS and ecommerce projects usually have a very stable topology so as a developer of these types of applications, you don’t often end up adding and removing services. And when they do, our Platform.sh system was simple. Just reallocate resources between all of them. But it also means that when you add a service to an existing environment, the other services might automatically get smaller.  And if you add a service and it overflows the maximums, you have to go to the next t-shirt size which is double. While this simple approach suits a large number of topologies—one app, one relational db, one cache, one search engine—it’s suboptimal for many other applications. 

While a lot of customers appreciated our nimble approach trying to fit as much as we could into a plan. Others, depending on their project’s typology, had to fight against these plans’ default behavior. And after seeing more and more workloads that painted outside of the lines of a CMS or ecommerce project, we decided it was time to offer an alternative pricing model. 

What makes Upsun so special?

While CMS-like monoliths are still a large part of our market, static site generators, and decoupled and composable architecture projects are gaining interest and market share every month. We wanted Upsun to be built to satisfy new use cases we see rising in the web development ecosystem and provide the best developer-focused experience in the market. Upsun's new offering is built around seven main features and one central concept: You are in control.

Explicit resources allocation

With Upsun, every container in every environment can now be configured with its own computing resource settings (CPU and RAM). 

This opens up many new possibilities for your production environment, including:

Guarantee that all applications and services always have the resources needed to serve incoming requests. 

Spawn as many workers or databases instances as you need, or add a new micro-service in a pinch without impacting the existing containers.

Grow only specific applications or services as your project is scaling instead of the whole project. 

Handle surges of traffic by quickly scaling the specific bottlenecks in your application.

However, the benefits are broader than just the production environment. That flexibility now allows you to size your preview environments how you want and creates a variety of new opportunities for our users who can:

Temporarily scale a preview environment with the same resources as production to run performance & load tests for a fraction of the price.

Profile applications and identify bottlenecks by changing the allocated resources and analyzing the results with Blackfire.

Run tiny preview environments to optimize the cost and carbon consumption of temporary instances.

A matching usage-based pricing

With the new ways of defining and allocating resources, we needed to rethink how we were pricing our value. We made countless attempts to create the most effective pricing model with three goals always in mind:

The pricing should be flexible to match the new possibilities offered by our resource allocation.

The pricing should be fair and transparent.

The pricing should be simple to understand for everyone.

A new pricing equation: separating resources from our value

Willing to be fair and transparent, we decided to isolate the resources—CPU, memory, and storage—from the value we provide—development workflow and safe and reliable deployment.

This provides users with a transparent view of how resources will be billed. It guarantees that you can scale your applications to hundreds of CPUs, should you need or choose to, at a cost similar to that of the IaaS providers you already know. Some of our regions cost us more than others but we still apply the same prices. Our goal is to put you in control without the headaches of managing overly complex IaaS billing.

Like AWS EC2 vs RDS, our managed services resources are priced to include the added automation and supervision required for databases, queues, and other backend services. And as we want to promote a more responsible cloud usage, our low-carbon regions will also benefit from an additional discount.

Valuing your time and fostering collaboration 

Platform.sh provides a lot of innovative features and best practices. But the main benefit of using Platform.sh is the ability to regain your time which you’d often spend on application infrastructure management. This is just as true for Upsun. 

We have always focused on ensuring our clients don’t spend countless hours setting up and maintaining costly infrastructures every month. And the more people work on your projects, the more the benefit is obvious. That's why we have decided to center our value around user licenses. This dimension is the best expression of the reclaimed time you gain.

We are confident that having all project members working on Upsun alongside developers is how you get the most out of it. That's why we are implementing free viewer licenses. Project members only viewing environments and deployed applications can enjoy Upsun for free. Invite as many stakeholders, clients & reviewers as you want without any financial impact on your projects.

And we’ve kept the best part for last. With Upsun, user licenses are now organization-based and not per project. Meaning you don't need to worry about giving access to a new project to an actual user.

Project automation

For every new project you create, you get a variety of included resources and you will only be billed overages if you go over these included quotas, which are:

10GB of Egress (outgoing) bandwidth & 500k incoming requests

1GB of storage in all environments

300 build minutes

Up to 100 hostnames & TLS certificates

You can find all the details on the Upsun pricing page.

Support and SLAs

As the need for support grows with your Upsun usage, we have decided to move the support to the organization level, your support amount will be directly proportional to your amount of projects and users. 

Unlike Platform.sh, our Uptime SLAs (99.9/99.99%) are per project. This allows within the same organization to run non-critical applications at  an optimized cost alongside critical ones that require these additional guarantees. 

A revamped user experience focused on the CLI

The Platform.sh CLI has always been at the core of the user experience and Upsun is no different. The new Upsun CLI comes with a “project:init” command, streamlining the creation of the Upsun YAML configuration files for migrating or creating new projects.

We are also introducing the “scale” command, letting you set the resources on your environment containers through the CLI and then you can scale them up or down. Vertically or horizontally.

Applications can be scaled horizontally out of the box. This means you can ensure stateless application scalability without limitation and increase your application reliability.

Observability on every level

Observability is crucial for web applications as it allows developers to understand how their systems function in real-time. Developers and operations can monitor their applications, detect errors and anomalies, and quickly identify and resolve issues before they become major problems with the Upsun observability tool. 

Our observability tools includes:

HTTP level metrics and analytics.

Continuous profiling of Go and Node.js application.

Extended Profiling and Application Performance Monitoring of PHP and Python applications.

Infrastructure and resources metrics.

With observability on every level, developers can make data-driven decisions and gain valuable insights into the behavior of their applications, enabling them to continuously enhance their systems for optimal performance and efficiency.

Upsun is not a replacement of the Platform.sh PaaS. It’s the best of the Platform.sh PaaS packaged up in a completely revamped pricing model designed to meet the needs of decoupled and composable architecture projects which were limited by the “plan-based” pricing model. 

Upsun is now available as a private beta for the next few months. If you have one or more projects that would benefit from these new features, let us know via this form! 

Join the wait list now! First come, first served!

UPDATE: 07 December 2023

Bring your application and your team to the Upsun PaaS. You can register for an open beta free trial*, where you can test and evaluate Upsun in a production-grade environment, with plenty of resources.

Start a free trial

*Free 5-day trial includes: 1 organization, with 1 project and 2 running environments; unlimited containers; unlimited users; and up to 4.5 CPUs, 12 GB memory, and 20 GB network storage running concurrently. At the end of the trial, your project will be suspended until you add a valid payment method to your account. See available pricing for details.