Understanding Appsmith with Serverless Architecture

Appsmith is a turnkey solution for building internal apps in the cloud. It’s a complete workbench for creating graphical interfaces and tools that connect to your existing data sources. As organizations continue to embrace cloud-native solutions, Appsmith remains at the forefront, providing a robust and scalable platform for building dynamic and efficient internal applications. 

Appsmith is deployed as a single Docker container with a single volume for storing persistent data and also houses all five processes in one image via Supervisord. We call this the “modular monolithic” architecture. A single Docker container powers the whole application, making it easy to install. All dependencies inside the container are under our control, which makes updates easy to implement for developers and more reliable for end users.

What does Appsmith’s deployment architecture look like?

Appsmith is based on industry-standard technologies to provide front-end and back-end functionality organized in a single codebase. We deploy as a single Docker container that encapsulates:

1. The Appsmith Java back-end process
2. The NGINX server
3. The real-time service (RTS)
4. The MongoDB server
5. The Redis server

Appsmith has a dedicated web interface for monitoring Appsmith processes called Supervisor. You can access the Supervisor dashboard by navigating your browser to the Supervisor path/supervisor. You can do this locally with http://localhost/supervisor. Or you can access the Supervisor remotely through your server’s domain/IP address. For example, if your server’s IP address is 192.0.2.0, you could find the Supervisor at 192.0.2.0/supervisor.

This all seems very tight. How can we decouple it? 

So, the fact that this is a monolithic modular architecture doesn’t mean that we can not split them, and that’s what makes Appsmith even more unique, which allows us to run it on a serverless and stateless architecture. Let's review one example of self-hosting Appsmith on Google Cloud Platform with Cloud Run, a serverless/stateless product.

For this particular case, we are separating the filesystem using Cloud Filestore, Cloud Memorystore for Redis, Cloud SQL for PostgreSQL, and MongoDB Atlas for the MongoDB Instance. All we have to do to make this happen is define the correct environment variables for our docker image, and Appsmith will understand that it is running on a serverless architecture. Follow the following video or read our docs for a step-by-step guide. 

This is just one example, and you could achieve this easily on AWS (We announced support for AWS DocumentDB in November), Azure, Kubernetes, or your own On-Premise instances. The principle is the same. 

Kubernetes support

These single-container and decoupled approaches have also made supporting Appsmith on Kubernetes much easier. This was a highly demanded feature in our community, and the reasoning resonated with us well enough that we prioritized Kubernetes support.

Rolling deployments are one of the primary reasons for using Kubernetes (scalability aside). Containers can be dynamically upgraded or de-provisioned and reprovisioned with updated code, with enough containers always online to meet current demand, resulting in zero downtime.

An Appsmith upgrade can take up to 20 seconds — okay for most users, but too long in high-availability scenarios — and can still fail in edge cases. With Kubernetes, nodes that fail to upgrade or become unresponsive are unused and can be deprovisioned or troubleshooted. Our single-container approach makes managing an Appsmith Kubernetes cluster far more straightforward than if all components were hosted in separate containers, giving our users additional reliability through redundancy.

We also make this easier as we provide a Helm package to make Appsmith running on Kubernetes a breeze: 

helm repo add appsmith https://helm.appsmith.com

Conclusion

In conclusion, Appsmith's "modular monolithic" architecture, encapsulated in a single Docker container, provides a straightforward and easily deployable solution for building internal apps in the cloud. However, the versatility of Appsmith extends beyond its initial architecture, allowing users to decouple and run it on a serverless and stateless infrastructure.

By exploring an example deployment on Google Cloud Platform with Cloud Run, we demonstrated how to leverage various cloud services such as Cloud Filestore, Cloud Memorystore for Redis, Cloud SQL for PostgreSQL, and MongoDB Atlas for MongoDB. The key lies in defining the appropriate environment variables for the Docker image, enabling Appsmith to adapt to a serverless environment seamlessly.

This flexibility is not limited to Google Cloud Platform; users can replicate the process on AWS, Azure, Kubernetes, or even on their own On-Premise instances. Appsmith's commitment to adaptability ensures that the core principles remain consistent regardless of the underlying infrastructure, empowering developers to choose the environment that best suits their needs.

In essence, Appsmith's capacity to transition from a monolithic to a decoupled, serverless architecture underscores its commitment to meeting diverse deployment requirements.