Frappe on EKS: Which services are safe to auto-scale (HPA) and which are not?

Install / Update Deployment
1

Hi everyone,

I’m planning to deploy a Frappe/ERPNext setup on Kubernetes (AWS EKS), and I’m trying to figure out which components can be safely auto-scaled using HPA and which ones should remain fixed.

In a typical Frappe deployment, we have multiple services like:

  • gunicorn (web)

  • nginx

  • redis (cache / queue)

  • scheduler

  • socketio

  • workers (worker-d, worker-l, worker-s)

My goal is to improve scalability and handle variable workloads, but I’m concerned about potential issues such as:

  • duplicate job execution

  • Redis consistency / locking issues

  • scheduler conflicts

  • websocket/session handling

  • database contention under parallel workers

So I’d like to understand:

1. Which components are generally safe to auto-scale?

For example:

  • Is it safe to scale gunicorn replicas horizontally?

  • Can nginx be scaled behind a load balancer without issues?

  • Are workers (short/default/long) safe to scale, or do they introduce risks like deadlocks or duplicate processing?

2. Which components should NOT be auto-scaled?

  • Should scheduler always run as a single instance?

  • Are there any constraints around socketio (e.g. sticky sessions or pub/sub requirements)?

  • Should Redis be kept as a single instance (or managed cluster) rather than scaled via replicas?

3. Recommended architecture patterns on Kubernetes

If anyone has experience running Frappe on EKS (or Kubernetes in general), I’d really appreciate insights on:

  • Best practices for separating queues (e.g. per worker type)

  • Whether to shard workers or limit concurrency instead of scaling

  • Any production issues you’ve faced when enabling auto-scaling

My main concern is avoiding subtle issues (like race conditions or duplicate jobs) while still benefiting from Kubernetes scaling.

Thanks in advance for any guidance!

2
  • Do not scale: scheduler
  • Scale with sticky session for pod: socketio (or keep it single)

Everything else can be scaled.

Don’t use framework workers long, default, short. Instead create your own and scale that as per need. No conflict or choke up on framework’s workers.

For all pods use resource limits. Or in high scale environments gunicorn pods consume all node resources and make the node inaccessible.

Note about HPA and gunicorn: custom_containers/docs/gunicorn-pods.md at main · castlecraft/custom_containers · GitHub

2 Likes