Skip to content
Hardik Zinzuvadiya
Let's connect

ERPNext hosting, high availability and monitoring

Two application servers, a primary MariaDB with a replica ready to take over, Docker, CI/CD and Grafana alerting, with hardening as the baseline.

What this covers

  • Two application servers: one for the people using the system, one for API traffic and frequent cron
  • A primary MariaDB with a replica kept in sync and promoted when the primary fails
  • AWS, Azure or GCP — DNS, SSL, backups and scaling — or your own hardware
  • Docker images and Compose environments tuned for build and runtime, deployed by CI/CD without downtime
  • Grafana and Prometheus on every environment, alerting on symptoms users would feel, not on every metric
  • Key-only SSH, host firewalls, least-privilege database users, and backups restored on a schedule rather than only taken

How an engagement runs

  1. 01

    A first conversation

    You describe what is slow, manual or fragile. I ask questions, not for a budget, and say plainly whether it is work I should do.

  2. 02

    Scope in writing

    What changes, what does not, how we will know it worked, and what I need from you: access, a copy of the site, a person who knows the process.

  3. 03

    Build on a copy

    Work happens on a staging copy of your site. You review it there before anything touches production.

  4. 04

    Go-live with a gate

    Releases and migrations follow a rehearsed plan with a tested rollback. Nothing writes to production without approval.

  5. 05

    After go-live

    Fixes, monitoring and upgrades under support and maintenance, if you want them.

Related work

High-availability ERP infrastructureTwo application servers, a primary MariaDB with a replica promoted on failure, and Grafana alerting on every environment.Shopify to ERPNext operations suiteShopify orders become submitted Sales Orders, Invoices and Delivery Notes on a schedule, with monitors for orders and products.

Questions I get asked

What actually happens when the database server fails?
The replica is promoted and the application servers follow it. That path is the reason the replica exists, so it is exercised rather than assumed, and the runbook for it is written down per environment.
Why two application servers rather than one bigger one?
So a heavy job never slows the people using the system. User traffic sits on one; API traffic and frequent cron sit on the other, both against the same primary database.
Can you host it, or does it have to be our cloud account?
Either. It has run on AWS, Azure and GCP and on customer-owned hardware; the Docker images, pipelines and alerting are the same, and the account can stay in your name.