ERPNext horizontal scalability on AWS


How do you achieve horizontal scalability of ERPNext and Frappe on AWS?
Did you use docker or EC2 ami images inside autoscaling groups?

Our idea is to use docker and microservice architecture, where we will have our docker image with ERPNext, Frappe and our site inside docker container and ElastiCache Redis instances for caching, AmazonRDS for mariadb, Elastic File Storage for the files inside /public and /private folders.

ElastiCache, Amazon RDS and Elastic File Storage (EFS) are connected via their endpoints to the docker container. I think that I can even mount it as a shared volume…
And Docker containers will be inside ECS (Elastic Container Service). That way, I think I can get horizontal scalability for our ERP Next app.

I started working on that and I got into multiple issues with it. First one is that I can’t seem to connect to Amazon RDS from docker container.
I was also trying to use official frappe docker (still in beta) image but without any success.

Am I heading the wrong way…?
What is the best practice to get horizontal scalability for ERPNext…?

Thanks in advance


A single app and DB server properly configured can handle hundreds of concurrent users. Are you sure you need horizontal scalability?

1 Like

hmm but if not horizontal scalability i still need minimum 2 instances in two different Availability Zone to achieve high availability.

I’m also curious about this. With different docker instances, how do you setup an ERPNext architecture with separate containers for the web app, redis, database etc? Possible with Bench or does it need a more manual approach?

1 Like

If you’re doing it manually, here is one way


What’s the impact to your business if there’s down time? If you’re using multi-AZ RDS, you’re fairly fault tolerant on the database end. If one application server is capable of supporting your end users, you could setup Auto-scaling to make sure that you always have (at least) one app server running. You have to weigh the costs of a fully built-out redundant infrastructure with the costs of downtime. If an app server were to fail, you should have the processes in place to have that back online within minutes–this is acceptable to my business (without incurring the costs of additional infrastructure to support horizontal scaling/redundancy).


1 Like

Our current setup includes Amazon RDS with the Multi-AZ option for database layer and AutoScaling groups for app layer.
We have procedures to automatically replace our app EC2 instance if goes down and becomes unhealthy, but all of that doesn’t look like best possible architecture (we have the single point of failure, we cant scale horizontally etc).

@felix Thank you for the video.

It looks like your next move is to point your users to an ALB and then add more app servers behind it (through your scaling group). An ideal scenario may be to mount your ERP Next install files across the app servers using EFS–this will keep them in sync.

Are you running into performance issues with one app server? How many users are active on the system at peak times? I’d love to work through this with you. I just passed my AWS Cloud Solution Architect - Associate certification so I’m looking for real world applications and uses cases.

Thank you,



Currently you have been able to successfully carry out what you have suggested:
Point your users to an ALB and then add more application servers behind it (via its scale group).

I am interested in making it work but it has not been achieved.

I would appreciate anyone who can give us their opinions and comments on this matter.

is horizontal scaling possible with Frappe?

this is one issue that i’m facing wrt horizontal scaling with custom frappe apps, I yet don’t know how to fix it.

any inputs would be helpful!

achieved with


can use ALB instead of NLB if you’ve budget.

Recently added karpenter for autoscaling. Add or scale benches and it’ll auto scale number of nodes as per provisioner setup.

Thinking of making HPA part of helm chart so tweaking autoscaler can happen through helm values.