If you’re getting into ERPNext as an implementor or managed hosting provider, you’ve probably already spent time reading about Docker, Kubernetes, and cloud-native architecture. The internet makes all of it sound straightforward. Some of it is. Some of it, applied to ERPNext specifically, will cost you a significant amount of time and client trust if you go in without a clear picture of the tradeoffs.
This article is that picture. It’s not a tutorial — it’s a collection of observations from someone who has deployed ERPNext many times, across many configurations, for real clients with real business operations on the line.
Before talking about how to host ERPNext, it helps to understand what it’s made of. This isn’t a single tidy application — it’s a collection of moving parts that all need to work together:
None of this is exotic. But it is a specific stack with specific dependencies, and it expects those dependencies to be present and well-configured. Keep that in mind as we walk through hosting options.
A VPS is a rented Linux server in the cloud. You get root access, you install what you need, and you’re responsible for keeping it running. DigitalOcean calls them Droplets. AWS calls them EC2 instances. Google Cloud calls them Compute Engine instances. They all mean the same thing: a full Linux machine you control.
This is where you should start. Not because it’s old-fashioned, but because it forces you to understand exactly what ERPNext needs. When something breaks — and something will — you’ll know where to look, because you built the whole thing yourself.
A well-configured single VPS can comfortably handle a small-to-mid-size ERPNext deployment. Many production systems run this way for years without issue.
Managed databases are worth considering early. Services like DigitalOcean Managed MySQL/MariaDB, AWS RDS, or Google Cloud SQL take the database off your plate — backups, patching, and failover are handled for you. For a new hosting operation, this is a reasonable trade: you pay a bit more per month, and you don’t have to become a DBA on top of everything else.
Once you’re comfortable with a single-server setup, splitting components across multiple VPS instances is a natural evolution. One server for the web tier and workers, a separate managed database, a separate Redis cluster. This improves reliability and lets you scale individual components independently.
This is a solid, professional configuration for hosting ERPNext for client businesses. It isn’t glamorous, but it works, and it’s well within the operational ability of a small infrastructure team to manage.
This is where things get more nuanced, so read carefully.
Docker containers are a technology for packaging applications into self-contained, reproducible units. They genuinely are useful. But they come with a set of assumptions about how applications should behave — and ERPNext doesn’t fully meet those assumptions.
What containers assume:
What ERPNext actually does:
There is an officially-supported Docker Compose setup called frappe_docker. It’s reasonably well-maintained and can work. If you want to experiment with containers, start there — not with a hand-rolled custom setup. But understand that you’re adding a layer of complexity that requires genuine Docker expertise to operate confidently.
Honest assessment: Docker Compose for ERPNext is a legitimate deployment option for teams that already understand Docker well. It is not a simplification for teams that are new to ERPNext.
Kubernetes is an orchestration platform for running large numbers of containers across multiple servers, with automated scheduling, self-healing, and scaling. It is a serious, powerful piece of technology — and it is almost certainly the wrong choice for your first (or second, or third) ERPNext deployment.
Kubernetes was designed to solve a specific problem: running many small, stateless, well-behaved services at scale. It assumes applications follow a set of best practices sometimes called the 12-Factor App methodology — writing logs to standard output, storing no local state, starting and stopping cleanly on demand. ERPNext, for the reasons described above, does not reliably follow these practices.
When you force ERPNext into Kubernetes, you don’t eliminate the complexity of ERPNext — you add the complexity of Kubernetes on top of it. When something goes wrong, you’re debugging two unfamiliar systems simultaneously. Logs that were hard to find on a single VPS become harder still when they’re scattered across pods that may have already been rescheduled or restarted. Worker crashes that were annoying on a VPS become operational incidents in a cluster.
This is not theoretical. ERPNext deployments on Kubernetes show a consistent pattern of difficulty — well-attested across community forums, GitHub issues, and practitioner post-mortems — among teams that were not already expert in both ERPNext and Kubernetes operations. The symptoms — performance problems, process crashes, broken background jobs, mysterious errors — tend to persist long after go-live because the root causes are architectural, not easily patched.
Kubernetes makes sense for ERPNext in a narrow set of circumstances:
If you’re a new ERPNext hosting provider, Kubernetes is not your friend right now. It will cost you more time, more money, and more client trust than it will save.
One of the first things a professional hosting operation needs is the ability to know when something is wrong before a client calls to report it. This means monitoring.
ERPNext does not have native integrations with common monitoring systems like Prometheus or Grafana. Building good observability around an ERPNext deployment requires deliberate effort: log aggregation, alerting thresholds, database performance monitoring, disk space tracking, worker queue depth. This is true regardless of whether you’re on a VPS or in containers.
Plan for this from the beginning. It is much easier to build monitoring in early than to bolt it on after a client has already experienced an outage.
Start on a single VPS. Use Ubuntu LTS. Follow the official bench installation process. Get everything working completely, and understand what each component does. When things break, fix them and learn why.
Add a managed database early. Reliability and backup for a database holding someone else’s business data is not an area to cut corners. The managed service cost is almost always worth it.
When hosting for multiple clients, grow toward a multi-VPS architecture: a dedicated database tier, separate application servers per client or per environment tier. Scalable, manageable, and well-understood.
Consider Docker Compose only after you understand ERPNext well enough to diagnose problems without it. Use frappe_docker rather than building your own. Make sure someone on your team has real Docker experience before you go this route.
Defer Kubernetes until you have a specific operational problem that justifies it, a team that knows how to run it, and the time to implement it properly. That day may come. It should not be day one.
| Approach | Suitable For | Watch Out For |
|---|---|---|
| Single VPS | Getting started, small clients, learning the stack | Right-size the server; don’t go too small |
| Multiple VPS + Managed DB | Production hosting for client businesses | Solid, recommended path |
| Docker Compose (frappe_docker) | Teams with existing Docker expertise | Adds complexity; not a beginner’s shortcut |
| Kubernetes | Large-scale managed service providers | Significant expertise required; defer until justified |
The internet will tell you that containers and Kubernetes are how modern applications are deployed. That’s true in many contexts. It is not an unconditional truth, and it does not apply equally to every application.
ERPNext is a mature, capable ERP system. It is also an application that carries the architectural assumptions of an earlier era of web development. Deploying it well means understanding what it actually is — not what you might wish it were.
Start simple. Learn the system. Build operational confidence. Then evolve your infrastructure as your understanding and your client base grow. That path is slower in the short term and significantly more reliable in the long term.
