ERPNext Deployment on AWS: Launch ERPNext from a Pre-configured AMI

An ERPNext deployment on your own server is mostly plumbing. MariaDB, Redis, Python, Node.js, a reverse proxy, SSL and a backup job all have to be in place before you see the setup wizard, and every one of them has a version ERPNext insists on. Meetrix's ERPNext AMI does that plumbing for you on AWS. It runs ERPNext 16.11.0 on Ubuntu 24.04, created by a CloudFormation stack in 5-10 minutes.

It isn't the only sensible way to run ERPNext, and the comparison with Docker, on premise and Frappe Cloud further down says when another route is better.

ERPNext AWS: what the AMI sets up

• ERPNext 16.11.0 and its Frappe stack on one EC2 instance running Ubuntu 24.04
• A new VPC and subnet (10.0.0.0/16 and 10.0.0.0/24 by default), with SSH limited to the range you set
• A Let's Encrypt certificate requested automatically when your domain is hosted on Route 53
• Backups to an S3 bucket you name when you create the stack
• Billing on your AWS invoice: the instance plus an hourly software fee, after a 5-day free trial

It's a single instance, so there's no high availability built in. For most small and mid-sized companies running one ERPNext site, that's the right trade. If downtime during an instance failure isn't acceptable, you're looking at a multi-server Frappe setup instead.

Deploy ERPNext on AWS in six steps

How to Install ERPNext on AWS? - Quick Video Guide

1. Open the ERPNext listing on AWS Marketplace, click "Continue to Subscribe" and accept the terms.
2. Click "Continue to Configuration", choose "CloudFormation Template" and your region, then "Continue to Launch" and "Launch CloudFormation".
3. Fill in the stack parameters: Admin Email (for the certificate), DeploymentName, DomainName, InstanceType (t3.medium recommended), your EC2 keyName and the S3Bucket for backups. SSHLocation defaults to 0.0.0.0/0; set it to your own IP range.
4. Choose "Roll back all stack resources" on failure, tick the IAM acknowledgement and submit. Creation takes 5-10 minutes. A vCPU limit error on a new account means a vCPU quota increase comes first.
5. Copy PublicIp from the Outputs tab and point your domain's A record at it in Route 53.
6. Open DashboardUrl and log in as Administrator with the password admin. Change that password before anything else.

If the domain isn't on Route 53, or the automatic certificate fails, SSH in and run the standalone script:

sudo /root/certificate_generate_standalone.sh

Developer Guide

ERPNext Developer Guide

For a detailed, step-by-step guide to deploying ERPNext on AWS, check out the full Developer Guide.

Meetrix.IO

The setup wizard starts on that first login: company, currency, fiscal year, and an option to load demo data. For what each module looks like after the first login, see our ERPNext demo walkthrough.

ERPNext hosting requirements

Frappe's installation docs are specific about software and silent about hardware. For Frappe and ERPNext version 16 they list:

No RAM or CPU minimum is published. The AMI's recommended t3.medium (2 vCPU, 4 GiB) runs the whole stack, database included, for a single company site. Memory is what runs out first as you add users and background jobs like email, reports and scheduled tasks, so watch it in the first month and resize the instance if it climbs. Setting up an AWS billing alarm before you size up is a good habit too.

ERPNext on premise, Docker, Frappe Cloud or an AMI

There are four realistic ways to run ERPNext. They differ mostly in who does the maintenance.

ERPNext installation with bench

The native route. Frappe's bench CLI and its install script set up MariaDB, Redis and the rest on an Ubuntu or Debian server, then bench get-app erpnext downloads ERPNext and bench --site <site> install-app erpnext installs it on a site. It's the most flexible option and the most work: upgrades, backups and SSL are yours.

ERPNext Docker

The official frappe_docker project runs ERPNext as containers. Read the labels carefully: ERPNext's README calls its Docker quick start a disposable demo for evaluation, and frappe_docker has a separate production setup. Use that one if containers are how you run everything else.

ERPNext on premise

Either of the two routes above, on your own hardware. Pick it when the data can't leave your building or a regulator says so. Otherwise a VM in a cloud region you choose gives you the same control without the hardware refresh cycle.

Frappe Cloud

Frappe's own managed hosting handles installation, upgrades, monitoring and support. It's the least work and the least control: the server isn't in your account.

The AMI sits between bench and Frappe Cloud. It's a bench-style install already done for you, running in your own AWS account. If you're still choosing between ERP systems rather than hosting options, our ERPNext vs Odoo comparison covers that, and there's an Odoo AMI if Odoo wins.

Customizing ERPNext: Frappe apps, scripts and the REST API

ERPNext is built on the Frappe Framework, and nearly every customization goes through it:

• Custom apps. Create a separate Frappe app with bench new-app for anything substantial. Keeping it out of ERPNext's own code is what keeps upgrades painless.
• Client and Server Scripts. Small form logic in JavaScript and Python, written from the browser without a deploy. Server Scripts are off by default; a system admin enables them with bench set-config -g server_script_enabled 1.
• REST API. Every DocType is exposed at /api/resource/<DocType>. Generate an API key and secret for a user and send Authorization: token api_key:api_secret. Details are in Frappe's REST API docs.
• Webhooks. Configured in the UI, they notify another system when a document is created, updated or submitted, such as a new Sales Order.

Start with configuration (custom fields, print formats, workflows) before writing code. A surprising amount of "we need a developer" turns out to be a setting.