A Dev's Guide to Building a Cloud Version of Your Open Source Software [Part 1]

As a developer, I am super impressed by the number of great open-source projects popping around. I think of (an open-source alternative to Firebase), (open-source headless CMS), (open-source search engine), (open-source product analytics tool), and so many others. For me, these are the tools that most developers will use in the future.

One common method to make those products financially sustainable is to provide a managed version. Meaning, you can enjoy using their product without the hassle of managing the product updates, the backups, the security, and the scaling. It is exactly what did with its cloud version - and it is pretty convenient to use their product in production. However, building a cloud version takes months (sometimes years).

What takes time? Hiring platform engineers, building the infrastructure, testing it, monitoring it... All of that takes a considerable amount of time and effort. Luckily, at Qovery, we provide the infrastructure stack that every open-source project needs to build 90% of their cloud-managed version. The remaining 10% are the UI and the business model logic. In this 6-part article series, I will attempt to explain how to build a cloud-managed version of AppWrite. Let’s go!

7-Part Article Series:

• Part 1: Introduction and architecture
• Part 2: Build our AppWrite cloud backend and integrate it with the Qovery API
• Part 3: Build our AppWrite cloud frontend and combine it with our cloud backend
• Part 4: Monitor our AppWrite cloud version
• Part 5: Integrate the payment system with Stripe (optional)
• Part 6: Integrate email notification with Courier (optional)
• Part 7: Give your customer a production, staging, and dev environment (optional)

Before getting started

Motivation

Since I launched in 2019, I have talked to dozens of founders from great open-source software companies. Most of them were looking to build their cloud-managed service at some point. Some of them even asked me for feedback on building one and asked me to use Qovery as a white-label technology when they discovered it was a full-time job. Qovery is a product simplifying app deployment and infrastructure management on AWS. Time flies, and as Qovery evolves, it is now possible for any open-source project to use Qovery as a white-label technology to provide a cloud version of an open-source project. No hidden cost. Just pick the plan that fits you best and build your cloud version in days instead of months. My team will be proud to help you in your success.

Why AppWrite

is quite representative of a “modern web open-source project”. In this guide, AppWrite is used as a demo project to demonstrate the concept of building a cloud-managed version for an open-source web project. AppWrite is written in PHP for the backend and JS for the frontend. It provides a user-friendly web interface connected to a web API, and it stores the data in MariaDB and Redis databases. The idea is: if it works for AppWrite, then it is good to work for any other web open-source project with a similar technical stack. Feel free to if you have any concerns.

Technologies

AppWrite is a Backend as a Service open-source software. It is similar to Supabase and Firebase to create a backend in a few minutes.

Our goal is to provide a fully managed cloud version of AppWrite. Meaning we need to deliver to our customers a way to order their AppWrite instance and use it, while the maintenance is handled by us. It is the most common managed version out there - think MongoDB Atlas. To achieve this, we will use the following technologies:

• : We will use to run the latest version of AppWrite.
• : AppWrite is using a MariaDB server for managing persistent database data.
• : AppWrite uses a Redis server for managing cache, queues, and scheduled tasks.
• : We will host AppWrite on AWS EKS (Kubernetes), Redis (in-memory database), and MariaDB (AWS RDS) for each customer on AWS.
• : Qovery will create an environment composed of AppWrite, Redis, and MariaDB for each customer on our AWS account.
• : Low-code GraphQL backend to manage our customers’ data.
• : JS frontend framework to provide a web interface to our customers.
• : database to store our customers’ data
• : To manage the auth of our customers.
• : To charge our customers.
• : To send an email and Slack notifications to our customers.

This bunch of technologies combined enable us to build a cloud version for AppWrite. Let’s take a deeper look at how all of them are interconnected.

Architecture

This schema represents the different layers composing the cloud version of AppWrite. From top to bottom, we will give the details of each layer.

User flow 1: Customer request an AppWrite instance

Here is what happens when the customer requests a cloud AppWrite instance:

1. The customer connects on cloud.appwrite.com (fake domain to represent “AppWrite cloud frontend”).
2. The customer requests a new AppWrite instance.
3. The AppWrite cloud backend calls the Qovery API to create an .
4. The AppWrite cloud backend calls the Qovery API to create a MariaDB database.
5. The AppWrite cloud backend calls the Qovery API to create a Redis database.
6. The AppWrite cloud backend calls the Qovery API to create an AppWrite application.
7. The AppWrite cloud backend calls the Qovery API to bind the AppWrite application to the MariaDB and Redis databases.
8. The AppWrite cloud backend calls the Qovery API to start the Environment.
9. The Qovery API returns the temporary URL to the AppWrite cloud backend.
10. The customer receives the URL of his instance via the AppWrite cloud frontend.
11. The customer can use his AppWrite instance.

User flow 2: customer deletes an AppWrite instance

Let’s say our customer now wants to delete his cloud AppWrite instance; this is what happens:

1. The customer connects on cloud.appwrite.com (fake domain to represent “AppWrite cloud frontend”).
2. The customer removes his AppWrite instance.
3. The AppWrite cloud backend calls the Qovery API to delete the customer .
4. Qovery deletes the AppWrite application, MariaDB, and Redis databases.

We can add other steps like payment (part 5), notifications (part 6), and everything you want - they are not required to make our cloud version functional. Let’s now take a deeper look at the infrastructure.

AppWrite cloud frontend and backend (control plane)

The AppWrite cloud frontend and backend are the two components that we have to build from scratch. It includes our business logic and customer management system. We will use for the backend and for the frontend. We will connect the frontend to the backend via a API. The advantage of using Hasura instead of coding our web backend is that we have access to many features (Auth0, Stripe support...) right away. Saving days of work. The goal here is to provide to the customers a web interface to:

• Create, update, stop, restart, delete AppWrite instances.
• Configure their custom domain.
• Charge our customers and let them pay for their subscriptions

Qovery and AWS

is the simplest way to deploy apps and manage your infrastructure on AWS. We will use Qovery as an Infrastructure as Code (IaC) API.

Qovery provides a production-ready infrastructure on our AWS account in 30 minutes that we will use to host our customers’ instances. The provides a high-level abstraction to create for each customer an isolated including:

1. An AppWrite app instance with the possibility to scale it horizontally.
2. A MariaDB database.
3. A Redis database.
4. An HTTPS endpoint.
5. The option to bind a custom domain with TLS.
6. A secure API to manage Environment variables and Secrets.

Each Environment is isolated and will be accessible for only one customer. And as admin, Qovery provides a web interface to manage all our customers’ instances and troubleshoot any of their issues.

Curious to know more about how Qovery works? Take a look at .

Qovery and other cloud providers

Qovery supports , , and . In this guide, we will focus on AWS to make it simpler. But keep in mind that you can use another supported cloud provider. You can even imagine a feature where your customers can choose the cloud provider of their choice. This is exactly what “MongoDB Atlas” and “Hasura Cloud” do.

Side note: Qovery will support and for S1 2022.

MariaDB - Data persistence and backup

Our customers expect us to provide a reliable service and manage the database backups by using a cloud version. For AppWrite, MariaDB is the persistent database and needs to be backed up. Four options with pros and cons do exist:

1st option: single-tenant MariaDB container

Pros:

• Cheap
• Fast to spawn
• Physical isolation per customer
• Decent performance

Cons:

• You have to manage the backups

2nd option: multi-tenant MariaDB container

Pros:

• The cheapest option (1 container divided by the number of customers means higher margins)
• Fast to spawn

Cons:

• You have to manage the backups
• No physical isolation per customer
• The more you have customers, the poorest the performance is.
• Potential security breaches as many customers are using the same database instance.

3rd option: single-tenant managed MariaDB database (AWS RDS MariaDB)

Pros:

• Backup managed by AWS (point-in-time recovery included)
• Physical isolation per customer (security++)
• The most performant
• Scalable (managed by AWS)

Cons:

• The most expensive option (~$11 per instance for the cheapest one on AWS US-EAST-2)

4th option: multi-tenant managed MariaDB database (AWS RDS MariaDB)

Pros:

• Backup managed by AWS (point-in-time recovery included)
• Higher performance than container version
• Scalable (managed by AWS)
• Expensive for a few customers, but the more customers you have, the cheaper it is.

Cons:

• The most expensive option (~$11 per instance for the cheapest one on AWS us-east-2)
• Potential security breaches as many customers are using the same database instance.

We will pick the third option (single-tenant with managed MariaDB database) to create a state-of-the-art cloud version, but you are free to choose the one you want for your customer. Do not forget your customer expects you to take care of their business.

Side note: AppWrite uses Redis as a caching system. Then, we will use a Redis container instance which is the cheapest.

Contributors

Here is the list of contributors to this first part:

• Ricardo Sueiras - Principal Advocate in OSS at AWS
• Raman Sharma - VP Product Marketing at DigitalOcean
• Anton Babenko - AWS Community Hero and Hashicorp Ambassador
• Javier Viola Villanueva - Simulation Network Lead at Parity
• Ziad Ghalleb - Product Marketing Manager at Gitguardian
• Oliver Juhl - CTO and co-founder at Medusa
• Yann Irbah - SRE at Fewlines
• Laurent Doguin - ex VP Developer Relation at Clever Cloud
• Qovery Team and our community ambassadors (Aggis, Stun3r, Kartik)

Thank you to our contributors for their review and suggestions.

What’s next

Thank you all for taking the time to read until the end. We will build our AppWrite cloud backend and integrate it into the Qovery API in the next part.