When a bench production setup on Ubuntu is the right ERPNext deployment
Choose a bench production setup on Ubuntu when your team wants ERPNext running directly on servers it controls, without containers, and is comfortable operating a Linux stack itself. ERPNext is GPL-3.0 licensed and self-hosting it is free, so the decision rests on who will run the servers, patch them and answer for them, not on licensing. The Frappe production setup guide describes the path: install bench with the --production flag, create a site with bench new-site, fetch apps with bench get-app, and install them into the site with bench --site <site> install-app. This section covers ERPNext versions 15 and 16, which are the supported majors in scope.
Teams usually pick this path when they already run Linux servers, want direct access to bench for custom apps and patching, and prefer not to maintain a container build pipeline. It suits a single-server or a small number of benches where the platform team wants to see every process. Docker Compose or Kubernetes may fit better if your standard is containers, if you need repeatable images across environments, or if your platform team already operates a cluster. Confirm which of these matches your existing operating model before you commit, because switching later means rebuilding the server layout and migrating data.
Bench production mode gives you the application layer, not the operations layer. Supervisor keeps the web, worker and scheduler processes running, NGINX serves the site, and you still own the database server, Redis, TLS, backups, log rotation, OS patching and version upgrades. Ask your partner or internal team to document who owns each of those duties, how a failed worker is detected, and how a release is tested on a copy of production before it goes live. Check the current Ubuntu release and bench version against the Frappe documentation at the time you build, since supported combinations change.
How bench compares with the other ERPNext deployment paths
This page covers the path where Frappe's bench command line tool installs ERPNext directly on a Linux server, with no containers. Your team owns the operating system, the MariaDB and Redis services, the NGINX and Supervisor configuration, the bench version and every app checkout. It is the most direct path to understand what runs where, and it gives you full control over the host, but every component you change is a change your team tests and records.
- Ownership: the OS packages, database, process supervision, TLS and each bench update or app upgrade.
- Main trade-off: maximum visibility and control, paid for with manual drift management across servers.
- Good fit: a small number of long-lived servers managed by a team already comfortable with Linux services.
- Watch for: configuration applied by hand that exists only on one host and is hard to rebuild after a failure.
- Read next: the sizing and architecture pages before you commit to a single-server layout.
Before you choose this path, confirm who will run upgrades and restores on the host and how those steps will be documented.
The Docker-based Easy Install script gives a single-server production layout with ERPNext's services started as containers. The script generates credentials and wires the database, cache, workers and proxy together, so the first working deployment takes less manual setup than a hand-built bench. Your team still owns the host, the Docker engine, backups and the upgrade process, and the script's defaults shape what you can change later.
- Ownership: the host, Docker, storage, backups and the decision to keep or replace the generated configuration.
- Main trade-off: faster first install in exchange for less direct control over individual service settings.
- Good fit: one server, a team that prefers containers, and a plan to move to a hand-built Compose setup if needs grow.
- Watch for: generated passwords that must be stored in your secrets process from day one.
- Read next: the Easy Install page, which explains site naming and when to move to Compose.
Confirm how the generated secrets, site names and volumes will be backed up and rotated before you go live.
A hand-built Docker Compose setup uses the production images and Compose files from the frappe_docker repository. Each service, including MariaDB, Redis, workers, the scheduler, Socket.io and Nginx, is defined in files your team writes and versions. Your team owns the image tags, the environment files, the volumes and the update procedure. The repository notes that its single-file demo is for short-lived evaluation only, so production use means building the layout deliberately.
- Ownership: image pinning, Compose definitions, volumes, network exposure and every upgrade step.
- Main trade-off: configuration lives in version control and is reproducible, but the team must design what the Easy Install script decided for you.
- Good fit: one or a few hosts, with infrastructure-as-code practices already in place.
- Watch for: the demo single-file setup being mistaken for a production design.
- Read next: the custom image page if you need apps beyond the core ERPNext set.
Check that your team can restore the database and site files into the Compose layout before relying on it.
The frappe/helm chart runs ERPNext on Kubernetes as deployments and jobs, with external database and cache services and ingress in front. This path suits organizations that already operate clusters and want ERPNext managed with the same release, monitoring and access practices as other workloads. Your team owns the cluster, the storage classes, the ingress and certificates, scaling decisions and the upgrade sequence. Shared storage, database high availability and backups are design decisions you must make explicitly.
- Ownership: the cluster itself, storage, external MariaDB and Redis, ingress, secrets and release upgrades.
- Main trade-off: strong fit with existing platform tooling, at the cost of more moving parts to design and operate.
- Good fit: an existing Kubernetes platform team and a need to run several environments the same way.
- Watch for: storage that must support shared access across pods and database operations that stay outside the chart.
- Read next: the Helm chart page for deployments, jobs and worker scaling.
Confirm that your platform team, not only the application team, will own the upgrade and restore runbooks.
Configuration choices that shape a bench production install
This table compares the decisions you make before running bench on Ubuntu and what each one changes later. Read each row for the situation where the option fits and the work it creates when you revisit it. The main takeaway is that the Ubuntu release, the ERPNext major version and the app list are the hardest to change after go-live, so settle them first.
| Decision | Option and when it fits | What it changes later |
|---|---|---|
| Ubuntu release and host sizing | A release your organization already patches on a fixed cycle, sized with the sizing guidance for your data volume and user count | Moving to a newer release means a rebuild or in-place OS upgrade, then re-running bench setup. Confirm supported release pairings with the Frappe production setup guide before you choose. |
| Single server versus separate database host | One server for web, workers, Redis and MariaDB when user count and data are modest and you accept a shared failure domain | A separate database host adds network configuration, credentials and backup coordination, but lets you scale and restore the database independently. |
| ERPNext major version (15 or 16) | Version 15 is supported until the end of 2027, and version 16 until the end of 2029, according to Frappe's supported versions page. Choose 16 for a longer support runway if your apps support it. | Major upgrades bring breaking changes and app compatibility checks. Each major version is a separate upgrade project, so plan the next one from day one. |
| Which apps to install | ERPNext alone for core accounting, stock and manufacturing, or ERPNext with Frappe HR when you need HR and payroll on the same bench | Each extra app is a separate branch to pin, test and upgrade. Adding an app after go-live means a migration on every site it touches. |
| Site naming and default site | A fully qualified production domain chosen before the first install, and an explicit default site if the bench will host more than one site | Renaming a site later is a support task with DNS, certificate and configuration changes. Site names also appear in backups and scripts, so choose them once. |
| TLS approach | Let's Encrypt issued through bench for a single public site, or certificates managed by an upstream proxy when your edge already terminates TLS | Certificate renewal becomes an operations task either way. Changing the approach later affects the NGINX configuration and how the site is reached from outside. |
| Process supervision and reverse proxy | Supervisor and NGINX generated by bench for a conventional Linux host that your team already runs | Config is generated from the bench, so manual edits are overwritten on regeneration. Keep local changes under version control and document them. |
Installing ERPNext on Ubuntu with bench, step by step
This sequence takes a clean Ubuntu server to a running ERPNext site in production mode, with each step closed by a check that confirms the service it added is working before the next one starts.
Prepare the Ubuntu host and dependencies
Your systems or platform team creates the server in your own cloud account or data center, applies your baseline hardening, and installs the system packages that bench depends on, including Python, Node.js, Redis, MariaDB and the tooling needed to build front-end assets. Confirm the exact supported Ubuntu release and package list in the Frappe production setup guide before you start, because the prerequisites change between Frappe versions. The step is complete when the database server accepts a local connection, Redis responds to a ping, and the expected Python and Node.js versions report correctly from the shell.
Install bench with the production flag
Install the bench command line tool, then run the production setup so bench configures Supervisor and NGINX for the bench directory. The production flag is what separates this path from a development install, so run it as the dedicated frappe user rather than as root. The step is complete when the bench directory exists and the Supervisor and NGINX configuration files for it are in place, which you can confirm by checking that the supervisor service is active and that the NGINX configuration test passes.
Create the site with bench new-site
Create the ERPNext site with bench new-site, which provisions a database for it and sets the administrator credentials. Record the site name, the database name and the administrator password in your secrets store at this point, not in a shell history or a ticket. Site naming matters because it becomes the hostname NGINX routes on, so agree it with your DNS owner first. The step is complete when bench reports that the site was created and the site's directory appears under the sites folder of the bench.
Fetch the ERPNext app with bench get-app
Download the ERPNext application into the bench with bench get-app, pinning the branch or tag that matches the Frappe version you have chosen. Pinning keeps the server reproducible and makes later upgrades a deliberate step. Any other apps you need, such as HR or custom company apps, are fetched the same way in this step. The step is complete when the app directories are present under the apps folder and the bench's apps list shows them, which you can check with bench list-apps.
Install the apps on the site
Install the fetched apps onto the site with bench --site install-app, once for each app, in the dependency order the app documentation gives. The command creates the DocTypes, roles and default data for each app inside the site's database. Run the migration afterward if the install instructions call for it. The step is complete when bench --site list-apps shows ERPNext on the site and the site's login page loads over the NGINX address you configured.
Verify the web, worker and scheduler processes
Check that Supervisor is running the web workers, the background workers for each queue, and the scheduler, since ERPNext depends on all three. Background jobs such as email, scheduled reports and recurring documents run in these processes, not in the web requests a user sees. Use the Supervisor status command to confirm every program is in the running state, and confirm that a test background job completes. The step is complete when no program is in a restart loop and the scheduler is enabled for the site.
Confirm NGINX serves the site over the expected address
Test the NGINX configuration, reload it, and confirm that the site responds on the hostname your DNS owner set, from a machine on the network path your users will use. Check that the static assets load, since a missing asset build is a common cause of a blank page after a fresh install. Record which operations remain yours after this point: TLS certificates and renewal, backups, log rotation, the Redis and MariaDB tuning, monitoring, and every future upgrade. The step is complete when the site loads with its assets, a test login succeeds, and the operating list is recorded with named owners.
Operations that stay with your team after go-live
A bench install on Ubuntu gives you a working ERPNext, but the platform keeps running only if someone owns the routine work around it. The cards below cover the recurring tasks that fall to your team once the site is live, and the checks that show whether each one is working.
OS and Frappe patching
ERPNext v15 and v16 both receive frequent minor releases, so your team needs a fixed rhythm for applying them to the bench, the Frappe Framework and the Ubuntu host. Plan each update in a staging copy of the site first, run the migrate step, and confirm that custom apps and scripts still load. Ask your partner or vendor which minor releases contain fixes you must take, and record which version each environment runs.
Backups and restore testing
A backup that has never been restored is an assumption, not a recovery plan. Schedule regular database and file backups for each site, store copies away from the server, and restore them into a separate environment on a fixed schedule. Check that attachments, private files and the site configuration come back with the database, and time the restore so you know your real recovery window.
Supervisor and worker health
In a bench production setup, Supervisor keeps the web workers, background queue workers, the scheduler and socket.io running. A process that crashes quietly can stop scheduled jobs, email sending or report generation while the login page still loads. Set alerts on Supervisor process states, review the worker logs after each restart, and confirm that the scheduler is enabled for every production site.
TLS certificate renewal
Certificates issued for NGINX through bench, or through another ACME client, expire on a schedule your team must watch. Confirm that the renewal job runs, that the reload step reaches NGINX, and that the certificate covers every custom domain attached to a site. Test renewal before expiry, and make sure someone is alerted when a renewal fails, because a lapsed certificate blocks browser access to the whole ERP.
Log and storage growth
Logs, backups, uploaded files and database tables grow without anyone deciding that they should. Set log rotation for NGINX, Supervisor and the bench logs, watch disk usage on the database and file volumes, and review which records and files your retention policy requires you to keep. Growth trends matter more than current usage, so track them monthly and raise capacity before the disk fills.
Upgrades before end of life
Each ERPNext major version has a published end of life date, and running an unsupported version leaves you without security fixes. Track the supported versions page, plan each major upgrade as a project with its own staging run and rollback plan, and check custom apps against the new version before you start. Keep in mind that Frappe Cloud warranty coverage depends on running a listed version, which matters if you buy support elsewhere.
Securing the server, logins and server scripts
The main security decisions on a bench-based ERPNext server are which features are switched on, where the login path goes, and which services are reachable from the network. Server Scripts are disabled by default from version 15, and they must be turned on with the server_script_enabled setting before anyone can use them. Keep that setting off unless you have a reviewed need, because a Server Script runs Python with access to your documents. Confirm the default behavior for the exact version you install, and restrict who holds the System Manager role, since that role is what lets a user create or edit scripts. If you enable scripts, review them through your change process and keep them in version control alongside your customizations.
For sign-in, ERPNext supports LDAP against Active Directory or OpenLDAP through LDAP Settings, including SSL/TLS options and automatic mapping of LDAP groups to ERPNext roles at each login. Plan the group-to-role mapping before go-live, because a broad directory group can grant more ERPNext access than intended, and the mapping is re-applied at every login. Social Login Key covers Google, Microsoft, GitHub, Facebook, Frappe and custom OAuth or OpenID Connect endpoints. Decide which identity provider is authoritative for ERPNext accounts and disable local password login for staff where your policy allows. Confirm the exact LDAP and OAuth settings against the ERPNext LDAP integration documentation for your version.
Operationally, the database and cache are the components most often exposed by mistake. MariaDB and Redis should listen only on the private interface or the loopback address, and the host firewall should allow only the web ports and SSH from approved networks. Store database passwords, the site configuration and any OAuth client secrets outside the web root, with file permissions that limit reads to the bench service user. Rotate the Administrator password at install time and do not leave it in shell history or ticket notes. Keep named admin accounts for people, and review who holds administrative roles at each access review. Ask your team to confirm the firewall and bind addresses on the running server, not only in the configuration files.
Limits to confirm in your environment before you commit
A bench install is only as supportable as the version, operating system and app set underneath it. These checks decide whether the release you pick will stay supported for the life of the system, and each one should be confirmed in writing before the build starts.
Ubuntu, Python and Node versions
Each ERPNext and Frappe release states which Ubuntu, Python and Node.js versions it supports, and bench will not build cleanly outside them. Confirm the exact combination for your target release in the bench and Frappe production setup documentation, then check that your server image, package mirror and any hardened base image provide those versions. A mismatch found after go-live usually means a rebuild of the bench environment on a new host.
Release on the supported list
Version 14 reached end of life on January 31, 2026, so a new bench should not target it. Check the supported versions page for the release you plan to run, and confirm the date when that release will stop receiving support. Plan your upgrade path before go-live, because a major upgrade later is a separate project with its own testing window.
Frappe Cloud warranty scope
Warranty coverage from Frappe applies to customers who run a listed version and hold a matching Frappe Cloud support plan. A self-hosted bench on your own servers is not covered by that warranty just because it runs the same code. Ask your DeployOpen contact and Frappe what support you will have from each party, and write down who responds to a production incident.
Custom app compatibility
Every custom or third-party app must declare support for the target ERPNext major version, and its dependencies must resolve against the same Frappe release. Check each app's repository branch, its required app list and any migration patches it ships. Apps that have not been updated for the target release will block the install-app step or break after upgrade, so confirm them before you fetch anything with bench get-app.
Server-side script policy
From version 15, Server Scripts are disabled by default and must be turned on with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them at all. If your customizations rely on Server Scripts, confirm that your self-hosted bench allows them, and decide who can enable them, since they run Python inside the application.
Questions buyers ask before running ERPNext on their own Ubuntu server
What does it cost to self-host ERPNext on Ubuntu?
The ERPNext software is free to self-host, so the cost is the people and infrastructure around it. The ERPNext pricing page states that self-hosting is free, and it also lists Frappe Cloud as a hosted alternative with server prices from 20 US dollars per month for shared instances and 125 US dollars per month for dedicated servers. Your own costs fall into four groups: the Ubuntu servers, a database and backup storage, the staff time to install, patch and monitor the system, and the time to test upgrades. Infrastructure is recurring. Setup effort is largely one-time, while patching, backups and upgrades recur for the life of the system. Ask any partner for a quote that separates one-time build work from recurring support, and state which servers, backups and monitoring are included.
How long does a bench production setup take, and what drives it?
The duration depends on how much the build includes beyond a single site with ERPNext installed. The core sequence is installing bench with the production flag, creating a site, fetching apps, installing them on the site, and then configuring Supervisor and NGINX. Effort rises with the number of apps, the state of your server images, the TLS and domain requirements, the backup and monitoring design, and how much data must be loaded. Data migration often takes the longest because records must be cleaned and checked. Ask for a timeline tied to a written scope, with each milestone listed, rather than a single number.
What skills does the internal team need to run bench in production?
Your team needs Linux administration skills, comfort with the command line, and working knowledge of a relational database, Redis, Supervisor and NGINX. They also need to understand how Frappe runs background workers and the scheduler, because a site that loads but does not process queued jobs will fail quietly. Someone must own the server, the database backups, certificate renewal and the upgrade calendar. Engineers should be able to read logs, restart services safely and restore a backup to a test host. If those skills are missing, the gap should be named in the scope before work starts.
Can one administrator run ERPNext on bench alone?
One capable administrator can run a small, single-site deployment, but the arrangement carries key-person risk. A single person has to handle patches, security updates, backup verification, monitoring alerts and version upgrades, and no one else can cover absences. Plan for a second person who can restore a backup and follow the runbook. Also decide who handles business-side questions about account settings, roles and data changes, since those are not infrastructure tasks. If your organization cannot cover absences, a support retainer can supply the second pair of hands.
When should we hire a partner instead of building bench ourselves?
Hire a partner when the build involves custom apps, data migration from another system, integrations with banks or payment providers, or a compliance review that needs documented controls. A partner is also useful when your team lacks time for a first production install or cannot commit to a recurring upgrade schedule. Partners help most when the scope is fixed in writing before work starts. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope.
How is a partner quote built from a written scope?
A quote follows from the written scope, so the scope must name the work precisely. Expect it to list the servers and environments, the apps to install, the TLS and domain setup, the backup and restore test, monitoring, data migration volume and sources, user access and login integration, documentation and handover, and any post-go-live support. Each item drives effort, so vague scope produces wide ranges. DeployOpen does not publish a price list. Ask for the scope, deliverables, timeline and the split between one-time and recurring work, and check that each assumption about your environment is written down.
What should we confirm about our environment before starting?
Confirm the Ubuntu release and its support status with your operating system vendor, the database and Redis versions your ERPNext release requires, and the supported versions listed on the Frappe support page before you pick a release line. Check that your servers meet the sizing your user count needs, that DNS and certificate authority access exist, that outbound email can be sent, and that backups have a tested restore path. Also confirm whether Server Scripts are needed, because they are disabled by default from version 15 and must be enabled deliberately.
Where to read the official bench and production guidance
Start with the Frappe production setup guide, which is the primary reference for this build. It covers installing bench with the production flag, creating a site with bench new-site, fetching apps with bench get-app, and installing them per site with bench --site install-app. Read it against the exact Frappe and ERPNext version you plan to run, because the command set and the supervisor and NGINX steps can change between major releases. Your runbook should cite the guide version you followed so a later reviewer can reproduce the build.
Next, read the frappe/erpnext README, which lists the install methods the project supports: Frappe Cloud, Docker Compose, and a manual install with the bench command line tool. Use it to confirm that the bench path is still the one the project documents for self-hosting, and to compare it with the Docker-based options before you commit your team to hand-managed services. The same README is the place to check prerequisites that your Ubuntu baseline must meet before you start.
Finally, check the supported versions page before choosing a release line. It lists the end-of-life dates for each major version and the support window for the current ones. Confirm which version is still supported on the date you go live, and plan for the minor release cadence that the release notes show for each line. Ask your implementation partner, and your own team, to write down who applies security and minor updates, and on what schedule, before the first production deployment.
How DeployOpen scopes, builds and supports a bench production ERPNext
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a bench production ERPNext runs on servers you control. We start from a written scope that names the Linux host, the Frappe and ERPNext versions, the apps and the operations you intend to keep in-house.
How we scope
- Confirm the ERPNext and Frappe major version you intend to run and check it against the supported versions list before build starts.
- Record the Ubuntu release, server count, database placement, and whether you need a separate Redis and worker host.
- List every app to install, including any custom apps, and decide which server-script and customization needs apply.
- Agree in writing who owns backups, Supervisor restarts, NGINX certificates, patching and upgrades after go-live.
How we build
- Install bench in production mode, create the site, and fetch and install apps in a repeatable sequence we document.
- Configure Supervisor programs and the NGINX front end, then verify that web, worker, scheduler and socket.io processes all restart cleanly.
- Test backup and restore on a copy of the site, and record the commands and timings your team will reuse.
- Run security checks on login, role permissions, TLS settings and exposed services before the site is accepted.
How we hand over
- Deliver a runbook covering the bench directory layout, site configuration, service names and log locations for your operators.
- Walk your administrators through routine tasks such as bench update, migrations, scheduled jobs and cache clearing.
- Provide a list of open items, including any step that depends on your network, DNS, mail relay or identity provider.
- Document the upgrade path, including how each minor and major ERPNext release would be tested on a staging bench first.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, so patching and version moves do not depend on one person.
- Ask any partner for a quote that separates one-time setup effort from recurring operations, monitoring and upgrade work.
- Confirm with your own team which operations stay in-house after handover, since bench production mode leaves them with you.
