Enterprise Resource Planning systems are not ordinary applications. They sit at the centre of finance, operations, inventory, HR, and reporting. When they fail, the business feels it immediately.
At Mediadesk, we approach ERPNext implementations with a simple rule:
ERP performance, security, and reliability are determined by architecture long before users log in.
This article explains how we architect ERPNext on Amazon Web Services, based on real operational needs rather than theoretical diagrams.
Architecture First, Tools Second
Many ERP projects fail not because of ERPNext itself, but because infrastructure decisions are made too late or treated as an afterthought.
Our approach is infrastructure-led and outcome-driven. We design cloud environments that are:
- Modular, so components evolve independently
- Fault-tolerant, so failures don’t become outages
- Secure by default, not patched later
- Ready to scale without disruptive rebuilds
This ensures ERPNext remains stable as usage, data, and integrations increase.
Core Architectural Principles We Apply
Before deploying anything, we align on these fundamentals.
Modularity
ERPNext is not a single workload. Application logic, database operations, storage, and access control each have different requirements. We isolate these responsibilities so growth in one area does not destabilise the system.
Fault Tolerance
Production ERP environments must survive component failures. Our architectures are designed so that no single failure results in business downtime.
Security by Default
ERP systems hold sensitive financial and personal data. Security is embedded at the network and access layers, not added as a bolt-on.
Non-Disruptive Scalability
Scaling should not require downtime, emergency migrations, or architectural redesigns. We plan for growth from day one, even for small initial deployments.
Typical ERPNext Architecture on AWS
While every deployment is tailored, a production-ready ERPNext environment generally includes the following layers.
1. Compute Layer – Application Services
ERPNext application services are deployed on dedicated compute resources sized according to:
- Number of active users
- Concurrent transactions
- Background jobs and reporting load
This layer is designed to scale independently without affecting data integrity or availability.
2. Database Layer – Data Integrity First
The database is the most critical component of any ERP system.
We design the database layer to ensure:
- High performance under load
- Reliable backups and recovery options
- Isolation from application-level failures
This separation protects financial and operational data even during application updates or scaling events.
3. Storage Layer – Documents and Attachments
ERPNext often becomes the central repository for invoices, contracts, and operational documents.
We implement persistent storage with:
- Clear data retention policies
- Regular backups
- Controlled access to prevent accidental exposure
This ensures business records remain accessible and protected long term.
4. Network & Access Control – Security Without Friction
Access to ERP systems must be tightly controlled without blocking productivity.
Our network designs typically include:
- Private internal communication between system components
- Restricted entry points for users and integrations
- Role-based access aligned with business functions
This reduces attack surface while keeping the system usable.
5. Backup, Monitoring & Observability
ERP issues rarely start as outages. They start as slow queries, resource pressure, or unusual usage patterns.
We implement:
- Automated backups with recovery validation
- Continuous health and performance monitoring
- Early alerting before issues impact users
This shifts ERP management from reactive firefighting to proactive operations.
Best Practices We Apply Across All Deployments
Regardless of company size or industry, these practices remain constant.
- Separate application and database responsibilities
- Automate backups and regularly test recovery
- Monitor continuously, not only when users complain
- Design for future growth, even if current usage is modest
ERP infrastructure should disappear into the background and not demand daily attention.