Which ERPNext layout fits your organization
The core trade-off is shared operations against isolation. One bench means one codebase, one Frappe and ERPNext version, and one backup and upgrade routine, while separate benches give each entity its own change calendar and failure boundary. For related companies, subsidiaries or divisions run by one finance and operations team, with similar tolerance for upgrade timing, multi-site is the sensible default. A single bench can host several sites, the first site becomes the default, and DNS-based multitenancy (enabled with bench config dns_multitenant on) or port-based multitenancy lets you add sites without adding servers. Before you commit, confirm in the Frappe multitenancy guide how your chosen mode routes hostnames and how each site's backups are taken and restored.
Separate benches are justified when the boundary is set outside your team: regulatory separation, contractual data boundaries for client tenants, or entities that must upgrade on different calendars. The reason matters because every site on a bench moves with that bench's Frappe and ERPNext version, so an upgrade one client has not approved becomes a change for all of them. Frappe's supported versions page lists version 15 as supported until the end of 2027 and version 16 until the end of 2029, so a tenant that cannot accept version 16 timing needs its own bench or a deliberately slower schedule. Ask your legal and compliance leads which data boundaries are written into contracts before you draw the line between sites and benches.
Cost is the part most often misjudged. Self-hosting ERPNext is free software, so the expense sits in people and infrastructure: each separate bench needs its own server or container set, backups, monitoring, staging and upgrade testing, plus the staff time to run them. The ERPNext pricing page lists Frappe Cloud 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. Those are list prices for managed hosting and say nothing about your own run cost. When you request quotes from an implementation partner or price your own team's time, ask for the cost of one bench per entity, the effort of a shared-bench upgrade across all sites, and who owns restore testing for each site.
Multi-site bench and single site compared
This table compares hosting several ERPNext sites on one Frappe bench against giving each site its own bench or server, across isolation, upgrades, backups, custom apps and operating effort. Read each row as a question to answer for your own tenants, since the right layout depends on how much you need to separate them. The main takeaway is that shared benches cut server count and admin work, while separate benches cost more to run but limit how far a failure, upgrade or restore reaches.
| Factor | Several sites on one bench | One site per bench or server |
|---|---|---|
| Routing model | DNS-based multitenancy names each site after the hostname that resolves to it and shares one port, enabled with bench config dns_multitenant on. Port-based multitenancy gives each extra site its own port. | Each site gets its own bench directory and its own web and worker processes, so routing is handled per server or per port without a shared site list. |
| Upgrade scope | A bench-wide upgrade moves every site on that bench together, so all tenants wait for the same code change and any blocking issue affects all of them. | Each bench can be upgraded on its own schedule, so one tenant can stay on a tested version while another moves forward. |
| Backup and restore granularity | Sites are backed up and restored individually, but a restore or migration planning exercise must still account for the shared bench configuration and apps. | Backup scope matches the bench or server, which makes restore simpler to explain to an auditor and to a single business owner. |
| Custom app sharing | Custom apps installed on the bench are available to every site, which reduces duplication but means one site's app change can affect the others. | Each site can carry its own set of custom apps, so a tenant-specific customization stays out of other sites. Duplicated apps must be maintained in each bench. |
| Failure domain | A bench-level fault in shared services or code can affect every site hosted on it. | A fault is generally confined to one bench or server, though shared infrastructure such as the database host still needs to be checked. |
| Server count and hardware | Fewer servers, with capacity shared among sites. Load from one busy site can affect response times for the others. | More servers or benches to provision, patch and monitor, with capacity sized per tenant. |
| Operator skills | Team needs Frappe bench administration, multitenancy configuration and a disciplined upgrade calendar for all sites at once. | Team still needs bench skills, and must repeat patching, backup checks and upgrades for each bench. |
| Server Scripts (version 15 and later) | Server Scripts are disabled by default from version 15 and must be enabled with server_script_enabled. Confirm the setting and who may approve scripts before sharing a bench across tenants. | The same default applies, but scripts stay within one tenant's bench, which simplifies review of who can run Python on the server. |
| Cost drivers | Lower hosting and administration cost per site. Costs rise if shared capacity must be expanded or if upgrade testing covers many tenants at once. Ask any implementer to quote the testing and coordination effort separately. | Higher server, monitoring and patching cost, recurring for each bench. Costs fall when tenants share a risk profile and can share one upgrade schedule. |
How DNS and port-based multitenancy share one bench
A single Frappe bench can host more than one ERPNext site, and the first site you create becomes the default. The real decision is how requests reach each site. DNS-based multitenancy names each site after the hostname that resolves to it, so all sites share one port and the bench routes by the incoming host name. You enable it with the dns_multitenant setting in the bench configuration. Port-based multitenancy runs each additional site on its own port, so the sites are separated by port number rather than by hostname. Both modes keep the sites on the same bench, which means they share one codebase, one set of installed apps and one upgrade path.
The choice shifts work onto your DNS, reverse proxy and certificate management. With DNS-based routing, every tenant needs a DNS record that resolves to the server, and your proxy must pass the original host header through to the bench. Each hostname also needs a certificate, so you should confirm whether you will issue one per name or use a wildcard, and who renews it. With port-based routing, the proxy and firewall must expose and map each port, and users must type a port into their browser, which many business users find awkward and some corporate networks block. Ask your team which of these operating burdens it is better placed to carry.
Before you go live, confirm the exact production setup against the Frappe multitenancy guide, including the bench configuration, the site creation commands and how the proxy should be configured. Test a site restore on a non-production copy, because backups are taken per site and you need to know that each tenant's data can be recovered independently of its neighbors.
What each layout puts in one failure domain
A multi-site bench shares most of its runtime, so a bad bench change or a broken shared service reaches every site at once. A single-site layout limits that blast radius but multiplies the number of benches, workers and upgrades you must run. Check each component below against your own tolerance for shared failure.
Bench code and Python environment
On a multi-site bench, the Frappe and ERPNext code, the apps directory and the Python virtual environment are shared by every site. One bench update or app version change moves all sites together, so a regression in one app version lands on every tenant at once. In a single-site layout each bench carries its own code and environment, so you can hold one customer on an older release while another moves forward. Ask which apps and versions each customer needs before you pick one shared bench.
MariaDB and Redis services
Both layouts can point at one MariaDB server and one Redis instance, but on a multi-site bench every site's data sits behind the same database process and the same cache. A server-level outage, a runaway query or a memory limit hit affects all sites in the same window. Separate benches let you split database and cache capacity by customer, at the cost of more processes to monitor and tune. Confirm the database version and Redis or Valkey version required for your Frappe release before you size either service.
Background workers and scheduler
Background jobs such as scheduled reports, email queues and document automation run from the bench's worker and scheduler processes. On a shared bench, one site with a long-running import or a heavy scheduled job can delay jobs for every other site in the queue. Separate benches give each customer its own queue and scheduler, which makes performance problems easier to isolate. Check how your deployment runs workers in Docker Compose or under bench production setup before you decide how many queues you need.
Per-site database and file storage
Each ERPNext site has its own database and its own sites/<site-name> folder for private and public files, backups and site configuration, even when several sites share one bench. This is the one layer that is per site in both layouts, so restoring a single site from backup is usually possible without touching the others. Plan restore tests for each site separately, and confirm that your backup tooling captures every site folder rather than only the bench directory.
Custom apps installed per bench
Custom apps are installed into the bench, so on a multi-site bench every site loads the same app versions, and an app installed for one customer is visible to the bench as a whole even if only one site enables it. Separate benches let each client run a different custom app set and a different app version, which matters when a customization is tied to one client's workflow. Review the app's compatibility with each Frappe major version before upgrading any shared bench that hosts it.
Reverse proxy and site routing
On a multi-site bench, DNS-based multitenancy lets one port serve several hostnames, with sites named after the hostnames that resolve to them and enabled through the dns_multitenant bench configuration. Port-based multitenancy gives each extra site its own port instead. In a single-site layout, each bench typically has its own proxy routing and certificates. Confirm how your reverse proxy, TLS certificates and DNS records map to each site before you commit to one routing model, because changing it later touches every customer's access path.
When multi-site or separate benches make sense
When several legal entities share a chart of accounts policy, a close calendar and a finance team, one bench hosting several sites usually keeps administration simple. Each company gets its own site and database, while one codebase, one set of installed apps and one upgrade window cover all of them. The trade-off is that every site moves to the same ERPNext and Frappe version at the same time, so one entity's testing delays everyone else.
- Shared upgrades: Every site on the bench is migrated together, so a blocking issue in one company holds back the rest.
- Shared maintenance window: Backups, restarts and bench updates affect all sites at once, which suits teams that already close books together.
- Shared custom apps: Any custom app installed on the bench is available to every site, so you must confirm that each entity can accept the same customization.
- Lower operating overhead: One server, one Redis and one set of workers serve all entities, which reduces the number of components your team patches.
- Per-site data separation: Each company keeps its own database, which helps with access boundaries but does not replace a separate environment for audit scope.
Before committing, confirm that all entities can accept the same release cadence and that your finance team can test every site in one cycle. Ask for the upgrade and rollback steps in writing before the first production migration.
An operator hosting ERPNext for several unrelated client companies faces a different problem. Clients usually have their own change calendars, data residency requirements, custom fields and contractual terms, and a shared bench forces them onto a common upgrade path. Many operators therefore separate clients by bench or by server, accepting more infrastructure in exchange for independent release timing and clearer blast radius.
- Independent release timing: Separate benches let each client accept upgrades on its own schedule, which matters when clients have different testing capacity.
- Contractual isolation: Clients with strict confidentiality terms are easier to serve when their data and customizations never share a bench with a competitor's data.
- Higher run cost: Each bench adds its own workers, scheduler, cache and backup jobs, so the infrastructure and monitoring load grows with every client.
- Customization risk: A custom app written for one client should not be installed on a shared bench where other clients can see or depend on it.
- Support boundaries: Ask whether your support contract covers each separate bench, because Frappe's warranty support depends on a matching supported version and plan.
Ask the client for their own change control rules and their data handling terms. Confirm with your operator team how many benches your monitoring, backup and upgrade routines can handle without manual steps.
A business unit under its own regulator, audit scope or internal change board may need to move on a different timeline from the rest of the group. In that case, separate benches or servers make it possible to freeze one unit's version while the others upgrade, and to keep its evidence trail distinct. The cost is that you now run two change pipelines, two sets of backups and two sets of access reviews.
- Separate version freeze: A regulated unit can stay on a validated version while other units move forward, which only works if that version is still listed as supported.
- Distinct evidence: Change tickets, test results and backup restore tests can be kept per environment, which simplifies what an auditor sees.
- Duplicated controls: Access reviews, logging, patching and backup verification must be repeated for each environment, which increases ongoing effort.
- Restricted customization: Server Scripts are disabled by default from version 15 and must be enabled explicitly, so confirm which custom logic your regulated unit actually needs before allowing it.
- Identity alignment: If the unit uses directory-based sign-in, confirm how LDAP or social login settings are configured on each bench.
Confirm with your compliance lead which controls apply to the unit and whether a shared bench would change their audit scope. DeployOpen prepares systems and evidence for assessments, but independent auditors decide what the evidence proves.
When entities need different ERPNext or Frappe versions, or install different custom apps, a shared bench cannot serve them cleanly. All sites on one bench share the same installed app versions, so a dependency required by one entity can break another. Separate benches are the practical answer, and they let you pin versions per entity with the bench tooling and your own release process.
- Version pinning: Each bench can run its own ERPNext and Frappe combination, which matters when one entity needs a feature in a later release line.
- Isolated custom apps: A custom app that changes core behavior stays on the bench where it is approved, so other entities are not affected by its updates.
- Image and dependency management: If you use containers, each entity may need its own image or build pipeline, which adds build and registry work.
- Upgrade planning per bench: Each bench needs its own migration test, which multiplies the testing effort for every new release.
- Vendor support fit: Check whether your chosen support route covers every version in use, because support windows differ by release line.
Before splitting, list every custom app and its owner, then ask whether each one could move to a shared, reviewed release. Confirm the supported version list on the vendor's support page and plan your upgrade calendar against it.
How a shared upgrade moves every site together
This sequence shows how one bench upgrade changes the code and database of every site it hosts, and where to stop before a failure reaches all tenants. Each step ends with a record that the next step depends on.
Confirm the target version is supported
Before any change, the platform owner checks Frappe's supported versions page to confirm the target release line is listed and still receives support. Frappe's policy states that customers must be on a listed version, and that warranty coverage from Frappe depends on a matching Frappe Cloud support plan. Record the target version, the support end date from that page, and whether your organization holds a plan that matches it. The output is a short written decision that names the target version and the reason for it.
Inventory every site, app and custom app
The platform owner lists each site on the bench, the apps installed on it, and the version of every custom app. Custom apps are the most common cause of upgrade failure, so note which ones depend on DocTypes, server scripts, or integrations that changed between versions. Confirm which sites rely on Server Scripts, which are disabled by default from version 15 and must be enabled with the server_script_enabled setting. The output is an inventory that maps each site to its apps and its owner.
Test custom apps on a staging copy
The developer restores a recent backup of each site onto a staging bench running the target version and runs the migration there. The team then checks custom DocTypes, print formats, scheduled jobs, and any authentication integrations such as LDAP or social login. Any failure is fixed in the custom app code and retested on a fresh copy. The output is a test log per site that records the migration result and each workflow that was checked. Do not move to production until every site on the inventory has a clean log.
Back up every site before changing the bench
The platform owner takes a full backup of every site on the bench, including the database and the uploaded files, and copies those backups to storage outside the bench server. A restore from each backup is tested on a separate machine, because an untested backup does not count as a recovery point. Keep the backup set for the whole upgrade window. The output is a list of backup files, their checksums or sizes, and a note confirming that a restore test succeeded for each site.
Update the bench to the target version
The platform owner moves the bench and its apps to the tested target version using the tested commands and the same version of every custom app. Once the code changes, every site on the bench runs the new code, even before any site has finished its migration. Depending on the commands used, migrations may also run across all sites automatically, so confirm that behavior in the staging log before production. The output is a bench reporting the target version, with the change recorded in version control.
Migrate and check each site in turn
The platform owner migrates sites one at a time, using the site name in each command, and reads the output after each migration. If a migration fails, the owner stops the sequence before the next site is touched, because the shared code is already new for all of them. Each migrated site is then checked for login, its key documents, background jobs, and error logs. The output is a sign-off for each site, with the migration log attached to the change record.
Decide how failure is handled before starting
Before the upgrade starts, the owner writes the rollback path: restore the previous bench code and each site's database from the verified backups. This path matters because one failed migration can hold up every tenant on the bench at the same time. A staged alternative puts each version group on its own bench, so a failed upgrade affects only the sites in that group. The trade-off is more servers and processes to patch and monitor. Ask your implementation partner to quote both options in writing. The output is an agreed rollback runbook and a recorded choice between a shared bench and separate benches.
Backups, restores and custom apps across sites
On a shared bench, backups and restores are handled per site, so restoring one tenant does not roll back the others, but you should confirm the exact backup and restore commands, and the flags that scope them to a single site, in the Frappe multitenancy guide and the current Frappe documentation before you write a runbook. Test the restore path on a copy of a real tenant, not only the backup job. Ask your team to record which sites share a database host, since a host-level failure affects every site on it, and to confirm how off-server copies are retained for each site. Single-site benches make this simpler because one restore touches one database and one file set, but they multiply the number of backup jobs, retention rules and restore drills you must run.
Custom apps are installed at the bench level and every site on that bench loads the same app code. A change to a custom app, a dependency upgrade or a failed bench migrate therefore affects every tenant at once, not only the one you were working on. Before you add a custom app to a shared bench, decide whether all tenants must accept its release cadence, and stage every change on a staging bench that mirrors the production apps list. Keep custom apps in version control so a rollback is a checkout, not a rebuild.
Server Scripts run Python on document events or as API endpoints. From version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. If your business logic depends on Server Scripts, confirm with Frappe whether the hosting tier you need permits them before you choose a shared or dedicated setup. Logic moved into a custom app is reviewed and deployed like code, which is usually easier to govern than scripts edited in the desk, but it also means a tenant-specific change needs its own app or a configuration option that all sites can accept.
Questions operators ask before choosing a layout
Does hosting several ERPNext sites on one bench save money?
It can reduce the number of servers you pay for, because several sites share one bench, one host and one maintenance routine. Self-hosting ERPNext is free according to the ERPNext pricing page, so your real costs are servers, storage, backups, monitoring and the staff who run them. The same page lists Frappe Cloud shared site hosting from 5 US dollars per month, and Frappe Cloud servers from 20 US dollars per month for shared instances and 125 US dollars per month for dedicated servers. Those are starting list prices, and they do not cover your upgrade testing, backup retention or support. Ask any implementation partner to quote hosting, upgrades, backups and support as separate lines, and confirm how heavy use by one tenant affects the others on the same host.
How much effort does one upgrade across shared sites take?
Every site on a bench runs the same Frappe and ERPNext code, so an upgrade moves all of them together. That keeps the codebase in one version, but it also means one change window, one test cycle and one rollback plan for every tenant. Frappe's supported versions page says version 15 is planned to be supported until the end of 2027 and version 16 until the end of 2029, so align your upgrade calendar with those dates. Before the window opens, check that each tenant's custom apps and customizations work on the target version, because one incompatible app can hold back every site on the bench. Measure the effort on a staging copy of every site rather than relying on a generic estimate.
Can we restore one tenant without affecting the others?
Usually yes, because each site normally keeps its own database and file storage, so a restore can target one site. The risk sits in the shared parts: the codebase, bench-level configuration, background workers and any app installed on the bench. A restore that brings back an older app version can break a site that has already moved on, so the restore procedure must match the versions in use. Test a single-tenant restore on staging before you need it, time it, and agree in advance who approves it while other tenants are live on the same server. Ask your partner to show the exact commands and backup scope for the Frappe version you run, and confirm that point-in-time recovery meets your data loss tolerance.
Do separate benches need separate physical servers?
No, but a shared host means shared capacity. Several benches can run on one server, and they then compete for CPU, memory, disk and database capacity unless you size and separate those resources deliberately. Separate servers give the strongest separation for resources, access control and maintenance windows. Containerized deployments with the official frappe_docker images separate services more clearly, but they do not remove the need to size the host. Consider separate servers when a tenant has a regulatory data boundary, runs heavy batch jobs, follows a different release cadence, or has a contract that requires dedicated infrastructure. Confirm with your infrastructure team how databases, Redis and backups will be split before you decide.
What skills does a team need to run multi-site ERPNext?
The team needs Linux administration, Python for bench and app work, and working knowledge of MariaDB, Redis, Nginx and Node.js. Frappe Framework v16 requires MariaDB 11.8, Redis or Valkey 6 or later, Python 3.14 and Node.js 24, according to the Frappe installation documentation, so someone must maintain those runtimes as they change. Server Scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting, so whoever writes custom logic needs to understand that setting and the review it requires. Multi-site adds tenant administration, DNS or port routing and disciplined backup checks. If those skills are not in-house, a fixed-scope implementation or a retainer can cover them, with the responsibilities written down before work starts.
Can we move a site to another bench later?
Often yes, but treat it as a migration project rather than a configuration change. Moving a site generally means restoring its database and files on the target bench, installing the same apps at compatible versions, and pointing the hostname or port at the new location. The hard parts are version drift between benches, custom apps that exist on only one bench, and data entered during the move. Plan a freeze window, a verified backup, a test restore on the target and a rollback path. Confirm the exact procedure for your Frappe and ERPNext versions in the official documentation and in a staging rehearsal, and ask any partner to put the steps and acceptance checks into the written scope.
How DeployOpen scopes and runs ERPNext layouts
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, so the site layout is chosen against your isolation, upgrade and recovery requirements before any build starts. We run the same written process whether the answer is one bench with several sites or separate benches per business unit.
How we scope
- Written scope lists which companies, sites and custom apps must share or separate a bench.
- We record the hostname or port plan, DNS responsibilities and who owns each site's data.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
- Quotes follow from that written scope, so ask for each site and bench named as a line item.
How we build
- We install the bench in your cloud account, data center or air-gapped network, not a vendor-hosted environment.
- We configure DNS-based or port-based multitenancy only where the written scope calls for it.
- Custom apps are built, version-pinned and tested against the ERPNext and Frappe versions in scope.
- Backup and restore are tested per site, so a single-site recovery is proven before go-live.
How we hand over
- Documentation covers the bench layout, site list, update sequence and rollback steps for your team.
- Runbooks state which upgrades move every site together and which need a separate change window.
- Access, secrets and backup schedules are transferred to your named owners at handover.
- Your team walks through a restore and a version update on a non-production copy before sign-off.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover version upgrades on the Frappe and ERPNext lines you have approved.
- Ask us to confirm which support windows apply to your chosen versions before each upgrade plan.
- Support scope is written, so you know who patches, who tests and who approves each change.
