When the ERPNext Easy Install script fits a single production server
The Easy Install script fits a team that wants ERPNext running on one server in containers without building images or writing Compose files by hand. The ERPNext README lists three routes: Frappe Cloud, Docker Compose, and a manual install with the bench command line tool. The Easy Install script is the Docker-based route, and it builds on the frappe_docker project, which provides production images and Compose files for ERPNext with services for MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx. Whether the script suits you depends on what it sets up on your host, so read its current documentation before you commit.
Do not confuse the single-file demo setup in frappe_docker with a production install. The project marks that demo for short-lived evaluation only, and the same caution applies to any quick-start path. The question for this section is narrower: does the script's output match a production single server? Confirm which services it starts, where data volumes live, how the site name is set and whether it pins image versions. Also confirm how the generated passwords are stored and whether they appear only once in the terminal, since that determines how you record them in your secrets process.
The script is a reasonable fit when one company runs on one host, your team is comfortable operating Docker, and you accept that backups, TLS, upgrades and any scaling remain your work. Plan to move to a hand-built Compose setup when you need custom apps baked into the image, a separate database server, or a proxy layout the script does not produce. A partner can scope either path in writing, and the quote should name who handles backups, restores and version upgrades after go-live.
How the Easy Install route compares with the other ERPNext install routes
Frappe Cloud is the hosted option, operated by Frappe, and it suits organizations that want to avoid running servers, patching hosts and managing workers and the scheduler themselves. The ERPNext pricing page lists shared site hosting from 5 US dollars per month, shared servers from 20 US dollars per month and dedicated servers from 125 US dollars per month, so recurring cost depends mainly on the tier you choose and any support plan you add.
- Operations: Frappe runs the hosting layer, so your team focuses on configuration, data and users.
- Warranty: Frappe's supported versions policy ties warranty coverage to a listed version and a matching Frappe Cloud support plan.
- Customization limits: Server Scripts are disabled by default from version 15, and public shared benches do not allow them, so custom server logic may require a different hosting tier.
- Data location and terms: Hosting regions and contract terms follow the plan you select, so confirm them before you compare this route with a self-hosted one.
Check whether your custom code, integrations and data location requirements fit the hosting tier before you commit to this route.
The Easy Install script targets a single server running ERPNext in Docker containers. It makes many setup decisions for you, so a small team can reach a working instance quickly. It sits between a hosted service and a hand-built Compose project, but its defaults belong to the script, so confirm them in the frappe_docker repository for the release you plan to run.
- Fast start: One script creates the containers, and the site name and generated passwords become the first items your team must record and protect.
- Limited layout choices: Service arrangement, proxy behavior and certificate handling are largely set by the script, so later changes usually require Compose knowledge.
- Single host: All services share one server, so capacity planning, backups and recovery from host failure remain your responsibility.
- Evaluation caution: The frappe_docker single-file demo is marked for short-lived evaluation only, so confirm whether the script's output is the production layout before go-live.
Before go-live, confirm the script version, how it handles credentials and the production guidance in the repository.
A hand-built Compose setup starts from the production images and Compose files in frappe_docker. Your platform team chooses each service, version, volume, network and reverse proxy. This route suits teams that already run Docker in production and want the same review, pinning and backup practices they apply to other services. The work shifts from running a script to owning a stack.
- Service control: You decide how MariaDB, Redis, workers, the scheduler, Socket.io and Nginx are deployed, restarted and scaled.
- Version pinning: Image tags and app versions go under your change control, which matters because ERPNext publishes minor releases frequently on both supported major versions.
- Proxy and TLS: You select the reverse proxy and certificate approach that matches your network standards.
- Ongoing effort: Your team owns upgrades, drift between Compose files and the running stack, and regular restore tests, so plan for skilled operator time.
Confirm the current Compose files, image names and required environment variables in the frappe_docker repository before you write your own stack.
A manual bench install runs ERPNext directly on Linux with the bench command line tool, without containers. It gives the most direct control over the Python environment, process layout and host configuration. Choose it when your standards prohibit containers or when your team already runs Linux services with Supervisor and NGINX. The trade-off is that every operational task falls to your team.
- Host control: Packages, runtime versions and system services are managed on the server itself.
- Process management: Web, worker and scheduler processes are configured and supervised by your team.
- Upgrade work: Major version moves and app updates run through bench commands and need a tested runbook.
- Skill profile: This route works best for teams comfortable with Linux administration and troubleshooting without a packaged stack.
Check the current bench installation steps in the ERPNext README before you size the server and draft your runbook.
What the script installs and which services run on the server
The Easy Install script builds a Docker-based stack modeled on the production setups documented in frappe_docker. Each service has a distinct job, and together they serve web requests, run background jobs and keep real-time updates flowing. Confirm the exact service list the script generates for the release you choose before you plan backups and monitoring.
MariaDB database
MariaDB stores every ERPNext site's records, including ledger entries, stock movements and document history. It is the stateful service you must back up, size and protect first. Check where its data volume lives on the host, how the generated database credentials are stored, and whether your backup tool can capture a consistent dump of each site.
Redis cache and queue
Redis holds cached data and the job queues that ERPNext uses for background work. Losing it does not destroy business records, but it interrupts queued jobs and slows pages until the cache rebuilds. Confirm that the Redis instances are not exposed on a public interface and that restarts do not silently drop queued email or report jobs.
Background workers
Workers pick up queued jobs such as report generation, email sending and bulk document updates, so slow tasks do not block users. The script runs them as separate containers. Check how many queues are active, whether long reports have enough worker capacity, and where worker logs are collected.
Scheduler
The scheduler runs recurring jobs on a timer, including periodic tasks that the apps register. It must run as a single instance, because duplicate schedulers can repeat jobs such as recurring invoices or reminders. Confirm that only one scheduler container is active after any scale or restart operation.
Socket.io real-time service
Socket.io pushes live updates to the browser, such as notifications and document change alerts, over a persistent connection. If it is not reachable through the proxy, pages still load but live updates fail silently. Verify WebSocket upgrade headers on your reverse proxy and check that the service follows the same site names as the web tier.
Nginx entry point
Nginx receives browser traffic, serves static assets and routes requests to the web workers and Socket.io. It is also where TLS termination usually happens, so the certificate, host header and timeout settings are decided here. Confirm which ports the script publishes, whether the default site responds on the server address, and how certificate renewal will work.
What happens to the generated passwords and where they live
The Easy Install script generates credentials for the database and the initial Administrator account during installation, and those generated values are the only record of them unless you capture them. Treat them as production secrets from the first minute. Before you end the session, copy the database password and the Administrator password into your organization's secrets system, along with the site name and the date they were set. Then change the Administrator password through the ERPNext login flow so that only you hold the working value. Plan database credential rotation as a scheduled change, because changing a password inside MariaDB does not update the environment values the containers were started with. Name an owner for each secret so that rotation has someone accountable for it.
The larger exposure is where the values end up on screen and on disk. Anything printed to the terminal can persist in scrollback, session recordings and log collectors, and any value typed or pasted as a command argument can persist in shell history. Generated values written to plain files in the install directory are readable by anyone with access to that directory, and they can be copied into backups or repository clones without anyone noticing. Before you rely on the install, confirm against the frappe_docker repository and your own test run which files the script creates, which values it prints, what permissions those files receive, and whether the credentials reach the containers as environment variables, since docker inspect displays those to anyone with Docker access. Restrict or remove those files once the values are stored.
How to run the Easy Install script on one server
This sequence takes a single Linux host from preparation to a logged-in ERPNext site with its containers, scheduler and outbound email checked. Each step ends with a check, so the platform team knows what state the server is in before handing it to the business.
Prepare a Linux host with Docker
The platform or IT administrator prepares a Linux server with Docker and the Compose plugin installed, confirms the operating system and Docker versions listed in the frappe_docker README, and checks that the disk has headroom for images, database volumes and backups. Create the DNS record for the site name so it points to this host, and open ports 80 and 443 to users. Done when the Docker and Compose version commands return,
df -hshows free space on the Docker data directory, and the DNS name resolves to the server.Review the install script before running it
Download the Easy Install script to a file instead of piping it straight into a shell, and read it from start to finish. List every image it pulls, every volume it creates, every port it binds and every file it writes, and confirm the source is the frappe_docker project and not the single-file demo setup, which is marked for short-lived evaluation only. Compare the script with the version of the repository you intend to use. Done when your reviewer can name each image, port and volume and has signed off the change.
Choose the site name and release line
Pick the fully qualified site name that users will type into the browser, and make sure it matches the DNS record from the first step. Check the Frappe supported versions page to select a release line that is still supported, since version 14 reached end of life on January 31, 2026. Confirm in the repository how the site name is used in the database, volumes and proxy configuration before you rely on changing it later. Done when the site name and release tag are written in the change record.
Run the install and record credentials
Run the reviewed script with the chosen site name and release, and keep the terminal output for the change record. The script generates passwords for the ERPNext Administrator account and the database, so copy them into your team's password vault immediately. Confirm from the script and README where the credentials are also stored on disk, and restrict read access to that file to the administrators who need it. Done when the script exits without errors and both credentials are in the vault.
Confirm every container is healthy
Run
docker compose psfrom the project directory the script created, and confirm the file name and project name against the repository. The database, Redis, web, worker, scheduler, Socket.io and Nginx services should be running, and the one-time configuration and site creation jobs should show as completed without errors. Review the logs of each service for repeated restarts or database connection failures. Done when every long-running service is up and every one-time job has exited successfully.Log in and verify scheduler and email
Sign in as Administrator over HTTPS, change the generated password, and confirm the certificate is trusted by your browsers. Check that the scheduler is running in the system health views, then review the Scheduled Job Log for failed jobs. Send a test message from an Email Account configured with your outbound SMTP server and confirm it arrives, then check the Error Log for new entries. Done when login works, scheduled jobs run without failures and a test email is delivered. Record any gaps as items to resolve before users go live.
Which configuration choices fit the Easy Install route and which need Compose
This table compares common production settings across the Easy Install script and a hand-built Compose file. Confirm each entry against the current frappe_docker files before you commit, because script behavior changes between releases. If a choice you need is marked as a Compose job, plan for that work from the start.
| Configuration choice | Easy Install script | Hand-built Compose file |
|---|---|---|
| TLS termination | Confirm which proxy and certificate options the script configures and whether it issues certificates. | Usually your own reverse proxy or load balancer in front of the Nginx service, with certificates you manage. |
| External database | Typically runs MariaDB as a container on the same host. Confirm whether an external database can be pointed to. | Set database host and credentials through environment or override files, and operate the external server yourself. |
| Backup location and schedule | Confirm whether backups are scheduled by default and where they are written on the host. | Define the backup job and volumes yourself, then copy backups off the host on a schedule you control. |
| Outbound email settings | Usually configured after install in ERPNext email account settings. Confirm any prompts the script asks. | Same ERPNext settings, plus any SMTP relay you run. Keep relay credentials out of images and version control. |
| Custom apps | Limited to the apps the script installs. Confirm before adding your own apps. | Build a custom image from your apps list and reference that image in the Compose file. |
| Scaling workers | Worker containers follow the default layout. Confirm which replica counts you can change safely. | Add or replicate worker services for each queue, with resource limits you set for your server. |
| Site naming and extra sites | One site is created during setup. Confirm whether additional sites are supported without manual steps. | Create sites with bench commands in the backend container, and route each hostname through your proxy. |
| Generated passwords and secrets | Generated during setup. Record them in your secrets store and confirm where the script writes them. | You supply values through env files or a secrets store. Rotation and storage are your responsibility. |
Signs the single-server script has outgrown your needs
The Easy Install script suits one server running one site with its own generated credentials. The triggers below show when that shape stops fitting, and each one points to a Compose or Kubernetes option that gives you separate control over the part that is now constrained.
Custom app images
If your team needs Frappe HR, India Compliance or in-house apps baked into the release, the stock image no longer matches what you run. A hand-built Compose setup lets you build an image from your own app list and pin its tag. Check that every app version is compatible with the ERPNext branch you chose before you start the build.
Separate database hosts
The script runs MariaDB and Redis on the same host as the application. When database load, backup windows or patching need to be isolated, you need external database services and a Compose file that points the backend at them. Confirm who owns database backups and restore tests once the database leaves the server.
More background workers
Month-end jobs, scheduled reports and email queues can starve the default workers on a single machine. Splitting the short, default and long queues into their own containers lets you scale each one. Watch queue backlog and job duration before adding capacity, so you add workers where the delay actually sits.
Multiple sites and environments
Separate companies, a staging copy and a production site often need different apps, versions and change windows. Running them through one generated setup mixes their lifecycles. A Kubernetes deployment or separate Compose stacks give each environment its own release, so an upgrade in staging does not touch production.
CI-built images and change control
When releases must pass tests, carry an audit trail and roll back cleanly, pulling a generic image and editing containers by hand becomes hard to defend. Build images in CI, tag them immutably and deploy the same artifact through each environment. Ask your change board what evidence it needs for each release before choosing the pipeline.
Ingress and credential policy
Generated passwords and a fixed reverse proxy layout may not meet your secrets rotation rules or your network routing standards. Moving to a Compose file you own lets you manage secrets in your vault and place TLS termination where your architecture requires. Confirm which credentials must be rotated, who holds them and how they reach the containers.
Security and operations you own after the install
The Easy Install script gets ERPNext running on one server, but keeping it secure and current is your job from the first day. Plan a regular update routine from the start. The frappe/erpnext releases page shows that both supported major versions, v15 and v16, receive frequent minor releases, so the question is not whether updates arrive but who applies them, in which window, and after a test on a copy of the site. Before you commit to a version, check Frappe's supported versions page, because Frappe's policy ties warranty coverage to running a listed version and holding a matching Frappe Cloud support plan. If you self-host without that plan, confirm with your own legal and procurement team what support you actually have and who answers for a failed upgrade.
Backups and certificates are the next two items on the list. Backups must cover the database and the site files together, and a backup you have never restored is only a guess, so schedule a test restore into a separate server and time it. Confirm how the Easy Install setup stores its volumes and where copies go off the host. TLS is handled by the proxy the script configures, so write down how certificates renew, who gets the alert when renewal fails, and what happens to the site when the certificate lapses. Also confirm that the Docker host does not expose the MariaDB or Redis ports to any network beyond the Compose network, and check that from outside the host, not only in the config file.
Admin account hygiene and monitoring close the list. The Administrator account created during setup should have a password held in your secrets store, and day-to-day work should run through named users with roles that match their job, with two-factor authentication enabled for anyone who can change accounting or user permissions. Review those roles on a schedule. For monitoring, watch host disk, the background worker and scheduler containers, failed background jobs, and the health of the public URL, and send alerts to a team that is on call. Ask your partner or internal team to document each of these checks and owners before go-live, since the script will not do it for you.
Questions teams ask before running the ERPNext Easy Install script
How much does it cost to run ERPNext with the Easy Install script?
The software license costs nothing, but running ERPNext still carries real costs in labor, hosting and support. The ERPNext pricing page states that self-hosting ERPNext is free, so the license adds nothing to your bill. What you pay for is the server or cloud account the script runs on, the people who install, configure, back up and patch it, and any support contract you choose. For comparison, the same pricing page lists Frappe Cloud shared site hosting from 5 US dollars per month and dedicated servers from 125 US dollars per month, a managed option with its own terms. When you request a quote, ask for infrastructure, one-time setup, recurring operations and support hours to be priced as separate lines.
How long does it take to get a production ERPNext running?
No supplied figure gives a duration for this script, so confirm the timeline against your own environment before you set a date. Elapsed time depends on how quickly a suitable server becomes available, how many apps you add beyond ERPNext, the volume of data you load and how many reviews your security team requires. The script covers only one stage. The longer stages usually sit around it: DNS and HTTPS, identity integration, outbound email, a restore test of your backups and the first data import. The Frappe documentation advises importing only a few thousand records at a time, which means large histories take several passes. Ask any implementation partner for a written schedule with milestones tied to these stages.
What does my team need to provide before installing ERPNext?
Your team provides the infrastructure and the decisions the script cannot make for you. Prepare these items before the install:
- A Linux server or virtual machine in infrastructure you control, sized for your data volume and user count
- A DNS name for the site and a plan for HTTPS certificates
- An outbound mail service for notifications and password resets
- Backup storage with a restore procedure you have tested
- Named owners for admin access, version upgrades and incident response
Confirm the current system requirements in the frappe_docker repository before you order hardware, since the install depends on the Docker runtime and the services it starts.
Can a small IT team install and run ERPNext alone?
A small team can complete the install, but running ERPNext in production is a sustained commitment, so judge it on capacity rather than on whether the command succeeds. The script starts the containers for the application and its supporting services. Your team then owns upgrades, backups, monitoring, access control and security patching for the full stack. ERPNext publishes frequent minor releases, as the frappe/erpnext releases page shows, so someone must track them and test each one. If nobody on the team has operated Docker Compose stacks or administered a Frappe site, plan training time or bring in a partner for the first months of operation.
When should I bring in an implementation partner for ERPNext?
Bring in a partner when the work goes beyond starting a server, such as process design, data migration, custom apps, or integration with identity providers and banking systems. The ERPNext pricing page states that implementation is available through certified partners, so ask any firm to show its certification in writing. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers, and a quote follows from the written scope.
Is the Easy Install script suitable for production use?
The script can be the starting point for production, but you must confirm which mode it installs before you load business data. The frappe_docker repository provides production Docker images and Compose files for ERPNext, with services for MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx. The same repository marks its single-file demo setup for short-lived evaluation only. Check the script's README to see which setup it uses and whether it starts every service you need. Then verify your own backup, restore, TLS, monitoring and upgrade procedures, because a script does not decide those for you. Server Scripts are disabled by default from version 15, so enable them only after review.
How do I move from the Easy Install script to a hand-built Compose setup later?
Treat the move as a data and configuration migration, and confirm each step against the frappe_docker repository before you start. Begin with a verified backup, then record the site name, installed apps, environment settings and secrets, because the new stack must present the same site identity to find its data. Build the Compose services from the production files, with volumes you can back up independently. Restore into a staging copy, run the database migration your version requires, then check background jobs, scheduled tasks and email. Cut over DNS during a window agreed with users, and keep the old stack running until the new one has passed a full restore test.
Which ERPNext version should a new install use?
Choose a version that is still listed as supported on Frappe's supported versions page. The page states that ERPNext and Frappe Framework version 14 reached end of life on January 31, 2026, that version 15 is planned to be supported until the end of 2027, and that version 16 is planned until the end of 2029. Frappe's policy also says customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe, so self-hosted teams should weigh that when choosing. Pin the minor release you test and schedule upgrades well before a version leaves support. Confirm the current status on the page, since support dates can change.
Limits to confirm in your environment before go-live
The Easy Install script moves quickly from a blank server to a running site, which makes it easy to skip the checks that decide whether the setup is supportable. The cards below cover the limits to confirm with the vendor and the tests to run yourself before any live company data goes in.
Supported Linux and Docker versions
Confirm which Linux distribution, kernel and Docker Engine versions the script and the images have been tested against before you provision the server. Ask whether the Compose plugin version it expects is the one your package manager ships. A host outside the tested matrix can fail in ways that look like ERPNext bugs, so record the exact OS and Docker versions in your build notes.
Minimum resources for your data volume
Ask what CPU, memory and disk the single-server layout assumes, then compare that with your expected user count, transaction volume and attachment growth. The bundled MariaDB, Redis and worker containers share one host, so the buffer pool and worker counts compete for memory. Load a copy of realistic data and watch memory and disk I/O before you sign off on the server size.
Release listed on supported versions
Check that the ERPNext and Frappe version you plan to install appears on Frappe's supported versions page and is still inside its support window. Version 14 has already reached end of life, so a new install on it would start with no vendor support path. Confirm the date your chosen version leaves support, since that date sets when you must plan an upgrade.
Script behavior on upgrades
Ask how the script handles reruns, image tag changes and upgrades to an existing site, and whether it overwrites the generated Compose file or environment values. Find out which steps need manual migration commands and which are automatic. Test an upgrade on a cloned server before you apply it to production, and keep the previous image tags so you can roll back.
Data restore testing
A backup that has never been restored is not a tested backup. Confirm where the script stores database dumps and uploaded files, how often it runs them, and whether it encrypts them. Restore a dump into a separate host, log in, open a sample invoice and confirm that attachments and scheduled jobs come back. Record the time the restore took so you know your recovery window.
How DeployOpen scopes and delivers an ERPNext install on your server
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including ERPNext installs built on the Easy Install script. We agree the scope in writing first, then build and hand over the single-server setup in your cloud account, data center or air-gapped network.
How we scope
- Engagements are fixed-scope, with the server, networking, domain and site list agreed in writing before work starts.
- We confirm whether the Compose setup suits your user count, data volume and growth, or whether a hand-built Compose or Kubernetes design is needed.
- Your quote follows from the written scope, so ask for each item (server build, TLS, backups, hardening, handover) to be priced separately.
How we build
- We install the Easy Install script on a server you provide and record the generated passwords in your approved secrets store.
- We set the site name to your production domain, then verify the first login, scheduler, background workers and email sending.
- We configure backups of the database and site files and test a restore onto a separate host before go-live.
How we hand over
- You receive a runbook covering the Compose files, environment settings, container versions and the exact upgrade steps used.
- We document where secrets, backups and logs live, and which person on your team owns each recurring task.
- We walk your operators through restart, backup verification and the criteria that would trigger a move to a hand-built setup.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the install.
- Retainer work can cover minor release updates to ERPNext, which Frappe publishes frequently, and tested rollbacks.
- Ask for the support hours, response expectations and upgrade responsibilities to be written into the retainer before signing.
