Upsun as a SaaS development and management platform
The Software as a Service (SaaS) model treats each customer as a tenant of the application. To use the SaaS application, each tenant is usually required to pay a subscription.
Exploring three SaaS management platform tenancy models
- Multi-tenant architecture: All customers share the same application instance and database, but their data is logically separated and isolated.
- Single-tenant architecture: Each customer has their own instance of the application and database, running in their own environment.
- Mixed-tenant architecture: This model combines both architectures above.
In this article, we'll focus on specific challenges brought about by the single-tenant model, including developing, deploying, and keeping several instances of the SaaS application up-to-date.
Just another web app
First things first: a SaaS application is, at its core, just another ordinary web application. As such, the product engineering team that works on it can’t help but benefit from the features offered by Upsun, provided we can support all the components of their tech stack—which we most likely can. Some of our clients are SaaS companies employing the multi-tenant model, benefitting from the excellent features our PaaS provides to their engineering teams.
But how can we push the boundaries by leveraging Upsun for scaling and managing single-tenant SaaS applications?
Single tenant: a fleet of web applications
Enabling organizations to run thousands of apps and websites easily is already part of our mission. The peculiar thing about a single-tenant SaaS application is that the many instances resulting from the serial deployment of the same app will all share the same codebase.
Yet, by default, each Upsun project is backed and driven by its own Git repository. At first glance, this would seem to suggest that managing a single-tenant SaaS model on Upsun might be a nightmare!
Thankfully, that is not the case.
If your SaaS is single-tenant, then the main pain point is that you need to build automation and pipelines to:
- Deploy new instances of your SaaS application every time a new subscription is purchased
- Test new features and pre-releases on production-like environments
- Roll out new releases/code changes to all the active instances of your SaaS application
We already know that Upsun helps with a lot of that. What I want to show you today is how to leverage two of our features that will make all of that even easier.
Enter source integrations and source operations
Source integrations allow you to keep your code in a third-party repository that’s then linked to your Upsun project. The result is that whatever happens on that repository is automatically reflected on the project’s own Git repository. The hidden power of this feature is that you can also link the same third-party repository to as many Upsun projects as you like.
Since, however, that feature may have limits (for instance, GitHub has a limit of 20 webhooks per repository), our very own source operations feature completes this picture. Both features can be used together and in a complementary fashion.
So, for example, you can now have 10, 100, 1000 projects all driven by the same Git repository. And that opens up countless new possibilities.
Create a new instance
A new customer comes along and buys a subscription to your SaaS application.
When using source integrations all you have to do is (a) create a new empty project, and (b) create a new integration between the repository that holds your SaaS app’s codebase and your project. This latter action will effectively deploy a new instance of your SaaS application to the newly created project.
Don’t worry, you may automate this by using either our CLI or our API. For example, you could run something as simple as the following from a CI tool:
upsun project:create --region='eu-2.platform.sh --title='A SaaS' --environments=1 --storage=5 --default-branch=main --yes
upsun integration:add --type github --repository your-org/your-repo --token TOKEN -p project_id_from_previous_command
Or you could use our API to build the functionality above directly into the software that is processing your purchases.
Similarly, with source operations, one must essentially create an empty project and then initialize the main environment with a template already configured to use source operations to pull the code down from the repository where development occurs.
Develop and test
One of our flagship features is the ability to instantly clone production into a non-production environment with all of your data included, whenever we branch off the main branch (the one that powers the production environment). That affords the developer the luxury of having a live-like environment where they can deploy and test their feature changes.
When a source integration (for example, GitHub) is active on an Upsun project, the default behavior is that a feature environment is created whenever a new pull request is issued. If more than one project is linked to the same external repository, then that happens for each of those projects, provided the integration is configured to do so on each of them.
Indeed, if you create all your source integrations according to the default settings, the result will be that every time you issue a new pull request on the repository that holds the code for your SaaS application, all the instances on Upsun connected to that repository will create a new environment.
You may or may not want new environments to be created, but you are free to configure each integration as you prefer. That said, you probably want to reserve a specific pool of your instances for testing so that you don’t end up creating too many environments every time you issue a new pull request.
You can also use source integrations to link your development repository to the instances you want to use for automated testing and instead use source operations for all your other instances, where new releases can easily be pulled down when ready and tested.
Roll out new features to production
Regardless of how many instances you have chosen to test your changes, at some point those changes will be ready. For the sake of simplicity, let’s assume you have chosen to use a micro-release model. For example, every pull request that you have is a new release candidate on its own, and merging it will result in the changes going directly to production, whether they are instances linked with source integrations or source operations.
This might seem scary, but if you keep your changes small and you have lots of automated testing, it’s actually a very productive and lean way of rolling out new changes.
As I was saying: at some point, those changes will be ready to merge. And when you do merge them, the new commits will be pushed to those instances linked via source integrations, and eventually land to the instances pulling down updates via source operations.
The result is the same either way: the new release of your SaaS application is instantly rolled out to all active instances of your application on Upsun. Job well done!
Leverage the power of ROI
Upsun is uniquely positioned to provide two more benefits you can take advantage of here at Upsun.
- You can leverage the power of the massive ROI that it will afford you while building your SaaS offering
- You can choose to get into the PaaS market yourself, via the Platform.sh OEM program, as Platform.sh powers Upsun.
And…they are not mutually exclusive. You can do both at the same time! And when you do, that’s when you are in a truly unique position—you can offer a seamless upgrade path from the SaaS version of your product to the PaaS version. In a single-tenant model, that essentially means giving your customer access to the very same Upsun project that has been behind their application’s instance all along!
How neat is that?
Why not get in touch and make it happen?
If you are in the SaaS market, Upsun is an incredible solution that will address a plethora of management platform needs. And if you are thinking of offering both a SaaS and a PaaS version of your product, then Upsun is the perfect solution.