Hosting multiple ERPNext sites on one server

Hosting multiple ERPNext sites on one server: when one bench is the right choice

One bench can host several ERPNext sites when they share an owner and an operating model. A company with several legal entities, a test and production pair, or regional subsidiaries can often run all of them from one bench, provided one team patches, backs up and upgrades them on the same schedule. In Frappe terms, a site is a separate database and file store with its own domain, users and data, managed inside a bench directory that holds the shared code. All sites in a bench run the same copy of the Frappe Framework and the same ERPNext code, and they draw from the same set of installed apps. A bench is therefore one software version, even when it serves many companies.

That shared version is the main constraint. A major upgrade, an app update or a broken patch applies to every site in the bench at once, so a subsidiary that is not ready for a new ERPNext release holds back the rest. Teams should consider separate benches when sites need different app sets or versions, when the owners of the data differ and need independent change windows, when a regulator or auditor expects separate environments, or when one tenant's workload could starve the others of workers, Redis or database capacity. Confirm the current site, bench and app behavior against the frappe/frappe repository and the frappe_docker repository before you commit, since both change between releases.

Before you decide, write down who approves changes for each site, which apps each site needs, and how each site is backed up and restored independently. Then ask your implementation partner or internal team to show how the chosen deployment method maps site names to domains and where per-site configuration is stored. Treat a shared bench as one unit of change control: one upgrade plan, one maintenance window and one restore procedure covering every company inside it.

DNS-based versus port-based multitenancy

In DNS-based multitenancy, each site gets its own hostname, such as erp.company-a.example, and the reverse proxy and bench select the site from the Host header of each request. Every company is served on the same standard port, which keeps links, bookmarks and identity provider redirects clean. The cost is setup work per site: a DNS record, a certificate that covers the name and a proxy rule must all exist before users can reach it.

DNS records: Create one record per site, either individually or through a wildcard zone, and confirm with your DNS team how internal zones and split-horizon resolution apply.
TLS certificates: Issue a certificate for each hostname or a wildcard that matches it, and confirm how renewal works for every name in your certificate process.
Proxy routing: Configure NGINX or your chosen proxy to pass the original Host header to the bench unchanged, then test each new site by name.
Onboarding steps: A new company adds a record, a certificate and a proxy entry, so the change touches DNS, PKI and the web tier.

Before go-live, confirm that each hostname resolves as intended, that its certificate covers it and that the proxy forwards the Host header without modification.

Per-site configuration options and when each fits

This table lists the choices a team makes for each ERPNext site on a shared bench and whether each one is set per site or shared across the bench. Read each row against the trade-off column to decide which settings must be planned separately for every company or environment. The main takeaway is that the database, apps, scheduler behavior and email accounts need per-site decisions, while the bench itself stays common.

Option	Set per site or shared	Trade-off and what drives the decision
Site name and hostname	Per site	Each site is reached by its own hostname (DNS-based) or port (port-based). Choose names that match DNS records and TLS certificates, since each hostname needs its own certificate.
Database and credentials	Per site	Each site has its own database and database user. Separate credentials limit exposure between companies, but backups, restores and growth must be tracked per database.
site_config.json values	Per site	Each site keeps its own site_config.json for settings such as database details, encryption keys and mail or scheduler options. Keep the encryption key safe, since losing it can make stored credentials unreadable.
Installed apps	Per site (installed), shared (code)	The app code lives once on the bench, but each site chooses which apps to install. Install only what a company uses, and plan upgrades for every site that has the app.
Scheduler and background jobs	Per site (enable or pause), shared (workers)	Workers on the bench process jobs for all sites, while the scheduler can be paused or resumed per site. Plan job load across sites, since a busy site can slow others on the same workers.
Backup schedule and retention	Per site	Each site is backed up on its own, so restores can target one company without affecting others. Confirm backup frequency, storage location and restore testing for each site individually.
Email accounts	Per site	Outgoing and incoming email accounts are configured inside each site. Different companies usually need separate sender identities, DNS records and bounce handling.
Server scripts (server_script_enabled)	Per site	Server Scripts are disabled by default from version 15 and must be enabled with server_script_enabled. Decide per site whether custom Python is allowed, and review each enabled script during upgrades.

Setting up a second site on an existing bench

This sequence adds a new ERPNext site to a bench that already serves one, so that each company or environment gets its own hostname, apps, certificate, email settings, backups and scheduler checks. Each step closes with a check, so the second site is confirmed working before it is handed over.

Confirm bench, Frappe and app versions
Before creating anything, record the bench version, the Frappe Framework version and the version of every installed app on the existing bench, and confirm they match a version listed on Frappe's supported versions page. Check the branch of each app with the bench tooling and the Git state of the apps directory. Frappe's supported versions policy ties warranty coverage to a listed version, so an unlisted version is a finding to resolve before adding a site. The check is a written inventory that the new site will be built against, with any mismatch raised before work continues.
Create the new site with bench
From the bench directory, create the site with the bench new-site command, passing the new hostname, the database and admin options your bench version supports. Confirm the exact flags against the help output of the bench version in use, because option names can change between releases. Set the database root and admin credentials through your password process rather than typing them into shared shell history. The check is that the site directory appears under the sites folder, the site config file exists, and bench can list the new site.
Install the required apps on the new site
Install only the apps this site needs with the bench install-app command for the new site, in the same versions recorded in the first step. Install ERPNext and any companion apps in the order their dependencies require, and run the migrate step for the site after each install if your bench version requires it. Do not assume an app installed on the first site exists on the second, because each site keeps its own installed-app list. The check is that the installed-app list for the new site matches the inventory, and that the site loads its desk without errors in the logs.
Point DNS or the proxy at the new hostname
Create the DNS record for the new hostname and add it to the reverse proxy configuration in front of the bench, so requests for that name reach the same web port and are passed to the bench web service. Bench-based multitenancy routes by the Host header, so the proxy must forward that header unchanged. If you use port-based separation instead, the proxy and firewall rules change accordingly. The check is that a request to the new hostname over plain HTTP returns the new site's login page and not the default site.
Issue TLS certificates for the new hostname
Issue a certificate for the new hostname using the same process your existing site uses, whether that is bench-managed Let's Encrypt or a certificate in your proxy. Confirm the renewal path covers every hostname, because a certificate that renews for one site but not another is a common gap. Check the certificate chain and expiry date with a TLS client from outside the server. The check is that HTTPS to the new hostname presents a valid certificate for that name and the browser shows no mixed-content or redirect loop.
Set the default site and per-site settings
Decide which site answers requests that do not match a hostname, and set it deliberately with the bench set-default-site command rather than relying on the order in which sites were created. Then configure per-site settings in each site's configuration file, including outgoing email, backup options and scheduler state, using the config keys named in the Frappe documentation for your version. Keep secrets out of shared files and confirm the scheduler setting for each site matches its intended use. The check is that the default site is the one you chose, and each site's configuration shows its own email account, backup setting and scheduler state.
Verify login, background jobs and backups per site
Test each site separately rather than only the first one. Sign in as an admin on the new site, run a background job such as a scheduled report or a queued email, and confirm the worker picks it up in the logs for that site. Run a backup for the new site and confirm the database and file archives are written to the location you configured. Record the results in the handover note. The check is a signed-off list showing login, a completed background job, and a restorable backup for each site, with the default-site behavior confirmed on the proxy.

Isolation trade-offs: what one bench shares across sites

A bench is a shared runtime, not a set of separate installations. Every site on the bench runs the same ERPNext and Frappe code at the same version, uses the same installed apps, and is served by the same gunicorn web workers, background worker pools, scheduler, Redis cache and queue, and host. What each site keeps to itself is its MariaDB database schema, its sites/<site-name> directory with uploaded files and private files, its site_config.json, its users and its data. Before you add a site, confirm that every company or environment can accept the same ERPNext minor version, the same custom apps and the same upgrade date. If one company needs a different app set or a later release, that is a reason for a separate bench or server, not a reason to fork the shared one.

Shared capacity means one site can slow the others. A large month-end report, a bulk data import, or a long-running background job takes a worker slot from the pool that every site draws on, and Redis and the database connection limits are shared as well. The practical controls are per-site limits in site_config.json where the version supports them, separating heavy jobs into the long queue, scheduling imports outside business hours, and monitoring queue depth per site. Ask your partner or internal team to size the worker pools and database server for the combined load of all sites, not for the largest site alone. Test this with realistic concurrency before go-live, because the failure usually appears as slow pages on unrelated sites.

Data isolation between sites is not permission isolation inside a site. Separate sites keep one company's records out of another company's database, which is a strong boundary for tenants that must never share data. Within a single site, however, users from different legal entities still see what their roles allow, so role permissions and user permissions are a separate control that must be configured and reviewed on their own. Confirm which users have access to more than one site, how administrator accounts are provisioned on each site, and whether any shared user or service account reaches several databases. Document this model before the first site goes live, since it determines your audit evidence and your offboarding steps.

Security and operational risks on a shared bench

Several sites on one bench share a codebase, a worker pool, a database server and a set of credentials, so one mistake can reach every company hosted there. The cards below name the risks that connect these sites and the control to put in place for each before go-live.

Cross-site data exposure

Each site has its own database and files, but a wrong hostname, a missing site-specific user permission or a shared file path can still show one company's records to another. Test each site by logging in with a user from site A and requesting site B's URLs and API endpoints. Confirm that User Permissions and role restrictions cover every company, and check that the reverse proxy routes each hostname to the intended site only.

Shared secrets in site config

Each site keeps its database credentials and other settings in its own site configuration file, while the database server, Redis and mail accounts may be shared across sites. A leaked file or a shared password exposes every site that uses it. Restrict file permissions on the sites directory, use a separate database user per site, and record which credentials each site depends on so rotation does not break unrelated companies.

Default site fallback

When a request arrives for a hostname that no site claims, the bench may route it to the default site, which can show that company's login page or data to an unintended user. Set the default site deliberately, confirm what an unknown hostname returns, and make sure the default site holds no sensitive records. Document which site answers on each port if you use port-based multitenancy.

Backup and restore scope

A bench-wide backup job may capture every site, but a restore usually targets one site, and restoring it can overwrite that site's current data without touching the others. Decide whether backups run per site, confirm where files and private files are stored, and rehearse a single-site restore on a separate server. Ask your partner or hosting provider which backup scope they run and how retention is set.

Server scripts reaching the host

Server Scripts run Python inside the Frappe process, so a script enabled on one site runs with the same access as the bench itself. Starting from version 15, they are disabled by default and must be enabled with the server_script_enabled setting. Keep the setting off on shared benches unless a named administrator approves each script, and review who can create them on each site.

Monitoring each site separately

Background jobs, the scheduler, error logs and email queues are shared across sites on one bench, so a failing job or a full disk affects every company at once. Monitor per-site errors, failed scheduled jobs, queue backlogs and storage growth, and assign an owner to each site's alerts. Confirm that alerts identify the site they belong to, so an on-call engineer can tell which company is affected.

Questions buyers ask before hosting several ERPNext sites

What does it cost to host several ERPNext sites on one bench?

No fixed price applies, because cost follows the written scope. The main cost components are the design work (site naming, DNS plan, per-site configuration and isolation rules), the build and configuration on your servers, and verification of each site's backups and restores. Cost rises with the number of sites, the number of apps installed on each, the number of upgrades you expect to run across all sites together, and how much backup and monitoring coverage you want. Self-hosting ERPNext itself is free under its open-source license, so the spend sits in infrastructure, people and any external support. Ask any partner for a quote that lists each cost component separately, marks what is one-time and what recurs, and states which sites and apps are in scope.

How long does a multi-site ERPNext setup take?

The duration depends mostly on the environment and the decisions still open at the start. Teams with a clear list of companies, environments and apps usually finish the bench build faster than teams that still need to settle naming, DNS and access rules. Other drivers include approval cycles for DNS records and certificates, the availability of a database server and storage, the mail setup each site needs, and whether data migration is part of the same engagement. Ask for a timeline in the written scope that shows dependencies on your change process and identifies which steps are blocked by your teams.

What must our team provide before the work starts?

Plan to provide several items before any build begins:

DNS control for every site hostname, or a wildcard zone you manage
TLS certificates or permission to issue them through your certificate process
An outbound mail account or relay for each site that sends email
Server access, a database host, storage and network rules that match your policy
Named approvers for DNS changes, production changes and access to customer or company data

Also confirm who owns the site list and the company data each site holds, because that decides which access rules and backups apply.

Can our internal team host several ERPNext sites without a partner?

Yes, if your team has Linux administration, database operations, TLS, reverse proxy and backup skills, and can keep the system patched. The bench command line tool supports multiple sites on one bench, and the work is mostly routine once designed. The harder parts are ongoing: keeping each site's apps and version aligned, running upgrades across all sites, restoring one site without affecting the others, and watching queues and the scheduler. Check whether your team can own those tasks on a fixed calendar, and whether anyone is on call when a single site stops responding.

When should we split sites onto separate benches?

Split onto separate benches when sites need different ERPNext or app versions, different upgrade windows, stricter isolation of database access or data, or different operating teams or change approvals. Sites sharing one bench share its code, installed apps and worker processes, so one site's heavy job or faulty custom app can affect the others. Shared benches are also harder to upgrade without coordinating every company at once. Ask your partner to document each isolation trade-off, including what a shared bench cannot separate, before you decide.

Can we move one site to another bench later?

Usually yes, but it is a planned migration, not a simple copy. The usual approach is to back up the site, restore it on the target bench with matching app versions, then update DNS and check integrations, scheduled jobs, email and integration keys. Confirm with your partner how the move handles the site's files, scheduled jobs, custom apps, credentials and any external references to the old hostname. Ask for a rehearsal on a copy and a rollback plan before the cutover date.

Which security and compliance checks apply to shared sites?

Sites on one bench share a server, a database host and often a file system, so access controls and data separation need explicit design. Confirm how each site's users, roles and backups are separated, who can reach the database and the bench directory, and how secrets are stored. If an auditor will review the setup, ask for the control evidence to be defined in the scope, since DeployOpen prepares systems and evidence for assessments but does not issue audit reports or certifications.

Limits to confirm in your environment

Several sites on one bench inherit the limits of the platform underneath them. The cards below cover the version, hosting model, capacity and recovery questions that decide whether a shared host is a sound design for your companies or environments.

Supported ERPNext and Frappe version

Confirm which major version each company will run and when that version leaves support. Version 14 reached end of life on January 31, 2026, so any bench still on it needs an upgrade plan before new sites are added. Version 15 is planned for support until the end of 2027 and version 16 until the end of 2029. Check the supported versions page before you pick the version for the whole bench, because every site on it moves together during upgrades.

Whether Frappe Cloud hosts the bench

Find out where the sites will run before you write any server-side logic. Frappe Cloud public shared benches do not allow Server Scripts, so a company that depends on custom validation or API endpoints needs a dedicated or self-hosted bench. On a self-hosted bench, Server Scripts in version 15 and later are disabled by default and must be turned on with the server_script_enabled setting, which you should set per environment and document.

Site and app capacity of the host

Ask how many sites and installed apps the planned server can carry before database, Redis and worker load slow every company at once. Each site has its own database and scheduler jobs, and each extra app adds code to load and queues to process. Test with the apps each company actually uses, including any custom apps, and record the peak concurrent users per site. Treat the result as a measured limit for your hardware, not a number taken from a vendor.

Support coverage from a matching plan

Frappe's warranty coverage applies only when the customer runs a listed version and holds a Frappe Cloud support plan that matches it. A self-hosted bench is still supported by the community and your own team or partner, so the support contract needs to be written against your actual version and hosting model. Ask who answers a security fix for each version, how long that takes, and whether a partner's retainer covers the bench as a whole or per site.

Tested restores per site

A backup of the bench does not prove that one company can be restored without touching the others. Each site has its own database and files, so restore tests should pick one site, restore it to a separate host, and check invoices, stock balances and user logins against the source. Confirm how the backup tool handles one site at a time, where files are kept, how long they are retained, and who signs off the restore result before go-live.

Keeping several sites current on one bench

A bench is one set of installed apps shared by every site it serves, so an upgrade of the bench changes the code under all of your companies at once. ERPNext minor releases arrive often on each supported major: the frappe/erpnext releases page shows v15.123.0 and v16.51.1 both released in October 2026. Plan for a steady stream of small updates rather than an occasional big one, and treat each bench update as a change that touches every site, including the one serving your smallest subsidiary. Confirm the release cadence and the current supported majors on the Frappe supported versions page before you set the maintenance calendar.

Work from a staging copy of the bench first. Take a fresh backup of each site, restore the most sensitive or most complex site onto a separate bench with the same app versions, and run the migration there with bench --site <site-name> migrate followed by a check of key accounting, stock and print workflows. Keep the apps aligned: every app on the bench, including Frappe HR or any custom app, should sit on a version that matches the ERPNext major, or the migrate step can fail for one site and leave the others in a mixed state. Record the app commits in a file under version control so you can reproduce the bench exactly if a rollback is needed.

Migrate one site at a time in production, starting with a low-risk site, and only move to the next after its users have confirmed their daily work. Ask your implementation partner or internal team to confirm whether a bench-level update can be scoped to a subset of sites, and what rollback looks like once one site has run new schema changes while others have not. Schedule the window with the business owners of every company on the bench, because a failed migrate can stop all of them. Written into your runbook, this sequence turns a shared upgrade into a series of controlled, reversible steps.

How DeployOpen scopes and delivers multi-site ERPNext

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including multi-site ERPNext benches. The work starts with a written scope that defines how each company or environment is separated, then moves through build, testing and handover.

How we scope

Map each company, environment and domain to its own site, database and file storage before any build starts.
Record which sites share one bench, which apps each site installs and which accounts can reach each one.
Agree the written scope in advance, since most engagements are fixed-scope with deliverables and timelines set out in writing.

How we build

Create the bench, sites, DNS or port routing and per-site configuration in your own cloud accounts or data centers.
Test that each site resolves to the correct database, storage and default site, with isolation checks run per tenant.
Set up backups per site and confirm a restore of one site does not touch the others before go-live.

How we hand over

Deliver written documentation of the site map, routing rules, per-site settings and the reasons for each isolation choice.
Walk your platform and security teams through adding a site, removing a site and rotating site credentials.
Provide a runbook covering upgrades across all sites on the bench and the checks to run after each change.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build.
Re-test isolation when new sites, apps or domains are added to the bench.
Ask any support provider to confirm response terms and which upgrade steps are covered before you sign.

Hosting multiple ERPNext sites on one server