Should you self-host ERPNext or run it on Frappe Cloud?
Run ERPNext on Frappe Cloud if your team is small, has limited internal operations skills, and no data residency rule is blocked by the providers and regions Frappe Cloud offers. Self-host if you need control over the server and its configuration, must run on an air-gapped or private network, or already have a platform team that can carry upgrades, backups and monitoring. ERPNext itself is free under GPL-3.0 in both models, so the decision turns on hosting, operations and warranty coverage, and license fees do not enter into it. Before you decide, list every operational task your team would own under each model and confirm who performs it.
On Frappe Cloud, Site plans start at 5 US dollars per month for a single site on shared servers, and Server plans start at 40 US dollars per month for a full virtual machine hosting multiple sites and benches, according to the Frappe Cloud pricing page. Site plans include easy upgrades and restores, monitoring, offsite backups and SSH access. Frappe describes its platform as multi-cloud, so you choose the provider and region. Frappe recommends dedicated AWS or OCI instances where uptime and durability are critical, and it positions Hetzner servers for development, testing and non-critical production. Get the region and instance type confirmed in writing against your residency and uptime requirements. Product Warranty covers bug fixes in ERPNext raised as tickets, but it excludes functional support and requires a listed version plus a matching Frappe Cloud support plan.
Self-hosting carries no license fee, but you pay for servers, storage, backups and the staff who run them. Frappe's ERPNext pricing page says self-hosting suits companies with a tech team. The frappe_docker repository provides production images and Compose files with services for MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx. Its single-file demo is marked for short-lived evaluation only, so do not run production on it. Your team owns upgrades, restores and monitoring, and without a matching Frappe Cloud support plan you get no Frappe warranty or support. Check the supported versions page for current end-of-life dates before you pick a release line, since version 14 reached end of life on January 31, 2026. Ask any implementation partner to state in writing who handles upgrades, backups and monitoring after go-live.
How the two hosting models compare on the factors that matter
This table compares self-hosted ERPNext with Frappe Cloud on licensing, published prices, upgrades, backups, monitoring, regions, access, app deployment and warranty support. Rows marked as confirmed rest on published Frappe figures, while the rest name what to confirm with Frappe or your own team before you choose. The main takeaway is that the software is the same GPL-3.0 code in both cases, so the decision turns on who runs operations and whether you need Frappe's warranty.
| Factor | Self-hosted ERPNext | Frappe Cloud |
|---|---|---|
| Software license | GPL-3.0 for ERPNext, MIT for the Frappe Framework, no paid feature tier | Same GPL-3.0 ERPNext code, hosted by Frappe as a managed service |
| Published starting prices | Self-hosting the software is free, per the ERPNext pricing page | Site plans from 5 US dollars per month, server plans from 40 US dollars per month, dedicated servers from 125 US dollars per month (Frappe Cloud pricing page) |
| Upgrades | Your team plans and runs each upgrade using Frappe's installation scripts or Docker images | Easy upgrades included in site plans, per the Frappe Cloud pricing page; confirm timing and rollback with Frappe |
| Backups and restores | You design, schedule, test and store backups and restores | Offsite backups and easy restores included in site plans; confirm retention and restore targets with Frappe |
| Monitoring and maintenance | Your team builds monitoring and handles maintenance work | Monitoring included and maintenance handled by Frappe, per the ERPNext pricing page; confirm alert scope |
| Hosting provider and region | You choose the cloud, data center or air-gapped network and own the residency decision | Multi-cloud with a choice of provider and region; Frappe suggests dedicated AWS or OCI for uptime-critical workloads |
| SSH access and custom apps | Full control of the bench, servers and custom apps | SSH access and custom app deployment included in site plans; confirm limits on server scripts for shared benches |
| Warranty support | No Frappe warranty for deployments outside an eligible Frappe Cloud plan | Product Warranty for bug fixes in Frappe apps is included with a matching support plan; functional support is not included |
| Who you depend on for security fixes | Your team applies releases, with support from certified partners if you contract them | Frappe applies platform updates, but confirm the patch window for your listed version with Frappe |
Where your data lives and who controls access
Frappe Cloud and self-hosting place ERPNext data in different hands, and the choice shapes who answers for region, network paths and access reviews. The cards below cover where the data sits, who controls the network and identities, and which compliance work stays with your organization under each model.
Choosing the cloud provider and region
On Frappe Cloud you choose the cloud provider and region for your servers. Frappe's pricing page says Hetzner suits development, testing and non-critical production, while dedicated AWS or OCI instances are recommended where uptime and durability are critical. Before you commit, confirm with Frappe which regions are offered, where backups are stored, and whether the region you need is available on the plan you are considering.
Hosting class matched to workload
The provider choice is also a workload choice. A Hetzner-hosted site may be a sound fit for a sandbox or a non-critical staging copy, but a finance or inventory system with strict uptime expectations points toward the dedicated AWS or OCI options Frappe recommends. Ask Frappe to put in writing the hosting class for each environment, so production and test copies are not placed on different tiers without a decision.
Network and access control under self-hosting
Self-hosting lets your team set the network boundary: VPC layout, firewall rules, bastion access, VPN requirements and which administrators can reach the MariaDB, Redis and Nginx services in the frappe_docker stack. Frappe Cloud gives you SSH access and custom domains, but the underlying network is managed by Frappe. Document which model you choose and who holds the keys to each layer.
Identity integration and single sign-on
ERPNext can be connected to a directory through LDAP and to external identity providers through social login keys. Decide which system is the source of truth for user accounts and how joiners, movers and leavers are removed. Confirm with Frappe or your own test team which directory and login method your environment needs, and test deprovisioning before go-live.
Compliance evidence stays with you
Under both models, your organization owns its compliance obligations. Frappe Cloud may provide hosting controls and documentation, and self-hosting leaves all of that work with your team. DeployOpen can prepare systems, controls and evidence for an assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm with Frappe which certifications, if any, apply to the hosting service you plan to use.
Confirm regional and certification details
Regional availability, data residency commitments, backup locations and certification status can change, so none should be assumed from this page. Ask Frappe for current written answers on each of these points, and record them in your vendor file. If your regulator or contract requires a specific region or certification, make that a go or no-go item in the scope agreed with any implementation partner.
Which hosting model fits your team
A small finance or operations team with no platform engineers usually gets the most from Frappe Cloud. Site plans bundle installation, upgrades, monitoring and offsite backups, so the team spends its time on configuration and process instead of servers.
- Low starting cost: The Frappe Cloud pricing page lists site plans from 5 US dollars per month, a figure that covers hosting only.
- Upgrades handled for you: Site plans include easy upgrades and restores, so a version move becomes a platform task rather than an internal project.
- Server-side code limits: Frappe Cloud public shared benches do not allow Server Scripts, so custom Python on document events may need a different plan or hosting route.
- Implementation is separate: Frappe does not implement ERPNext directly and works through certified partners, so hosting fees and configuration effort are two different line items.
Before you choose, confirm that your required customizations run without server code, and ask for a written quote that separates hosting fees from implementation work.
Banks, healthcare providers and public bodies often need the ERP to sit inside a network they control, with defined data residency and access paths. Self-hosting keeps the database, backups and administrative access inside your own cloud account, data center or air-gapped network, and your platform team sets those boundaries.
- Network placement: Self-hosting runs on infrastructure you choose, including air-gapped networks, which a managed service does not automatically provide.
- Region and provider choice: Frappe Cloud lets you pick the cloud provider and region and recommends dedicated AWS or OCI instances where uptime and durability are critical, while Hetzner suits development, testing and non-critical production.
- Evidence ownership: DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue the reports, so confirm which artifacts your assessor will accept.
- Reversal condition: If your policy accepts a managed provider in a suitable region and you can document its controls, the managed model may reduce the number of systems your team must secure.
Before you decide, request the hosting provider's current control documentation and confirm the data residency and access model in writing.
A team that already runs Linux servers, backups and CI pipelines can self-host ERPNext with the same skills. The official Docker route uses production images and Compose files with MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx services, while bench gives direct control over the Frappe installation.
- Container route: The frappe_docker repository provides production images and Compose files, and its single-file demo setup is marked for short-lived evaluation only.
- Custom code on your terms: Server Scripts are disabled by default from version 15 and must be enabled with
server_script_enabled, a setting your team controls on its own servers. - Stack versions: Frappe Framework v16 requires MariaDB 11.8, Redis or Valkey 6 or later, Python 3.14 and Node.js 24, so base images and the patch cycle must match those versions.
- Reversal condition: Without a named owner for upgrades, monitoring and restore tests, self-hosting adds those tasks to a team that is already stretched, and the managed model becomes the safer choice.
Before you commit, confirm who owns patching, backup restore testing and on-call coverage for the ERP.
Product Warranty is support from Frappe engineers who fix bugs in Frappe apps such as ERPNext and in Frappe Cloud, raised as tickets. It does not include functional support, and Frappe ties warranty coverage to a listed version and a matching Frappe Cloud support plan.
- Eligibility: Deployments outside an eligible Frappe Cloud plan do not receive warranty services or support, so self-hosting removes this coverage from Frappe.
- Version listing: Warranty requires a listed version. ERPNext version 14 reached end of life on January 31, 2026, and version 15 is planned to be supported until the end of 2027.
- Functional gaps: Warranty covers bugs, not how your processes are configured, so budget for functional help separately from internal staff or an implementation partner.
- Reversal condition: If bug fixes must come from Frappe under a contract, a matching Frappe Cloud support plan may be the simpler route. A self-hosted team can add DeployOpen retainers for support and upgrades, but those do not replace Frappe's warranty.
Before you sign, confirm the supported version and plan that match your ERPNext release, and ask Frappe to state in writing what warranty covers.
Why Frappe warranty support depends on a Frappe Cloud plan
Product Warranty only reaches deployments that sit on an eligible Frappe Cloud plan. Frappe's supported versions policy requires two things at once: your ERPNext or Frappe Framework version must be on the listed supported set, and you must hold a Frappe Cloud support plan that matches that version. A self-hosted deployment outside an eligible plan does not receive warranty services or support from Frappe. Product Warranty itself is bug fixing by Frappe engineers for apps such as ERPNext and Frappe HR and for Frappe Cloud, raised as tickets. It does not include functional support, so questions about how to configure accounting, inventory or manufacturing workflows still need an internal power user, a certified partner or a paid functional engagement.
Version status is the second check. Frappe's supported versions page records that v14 of ERPNext and Frappe Framework reached end of life on January 31, 2026, that v15 is planned to be supported until the end of 2027, and that v16 is planned until the end of 2029. Before you choose a hosting model, confirm the version you intend to install against that page, then ask Frappe in writing which support plan would cover it and whether your planned hosting model qualifies. Keep the answer with your change records, because the qualifying conditions are the ones an auditor or your own risk committee will ask about.
For a self-hosted deployment, the gap is the decision to make. Ask Frappe whether any support route exists for your servers, and ask the certified partners that Frappe works with (the ERPNext pricing page cites more than 200) what they will cover, how they handle version upgrades and bug triage, and whether their scope includes the security patches you need on your own infrastructure. Get each answer as a written scope with named deliverables, and compare it with what Frappe Cloud already includes, since that comparison, not the license, is what sets your recurring support cost.
What your team runs in each model
This table shows which operational tasks Frappe Cloud performs for you and which fall to your team when you self-host ERPNext. Where Frappe Cloud is marked to confirm, check the exact boundary in the plan terms before you rely on it. The main takeaway is that self-hosting places every operational task, including incident response, with your own staff.
| Task | Frappe Cloud | Self-hosted ERPNext |
|---|---|---|
| Installation and setup | Frappe provisions and installs the site on the server plan you choose | Your team installs with frappe_docker Compose files or the bench command line tool |
| Upgrades | Easy upgrades are included on site plans | Your team plans, tests and runs each version upgrade and migration |
| Backups and restores | Offsite backups and easy restores are included on site plans | Your team designs, schedules, tests and stores backups and restores |
| Monitoring | Monitoring is included on site plans; confirm alert routes and thresholds | Your team deploys and watches monitoring for every service in the stack |
| OS and database patching | Confirm patch scope and timing for your server plan | Your team patches the operating system, MariaDB, Redis and container images |
| Stack services and workers | Frappe manages the stack; confirm Redis and worker handling for your plan | Your team runs MariaDB, Redis, workers, scheduler, Socket.io and Nginx |
| Server scaling | Change server plans as needed; confirm how resizing works | Your team sizes VMs or containers and scales each service |
| Incident response | Product Warranty covers bug fixes raised as tickets, not functional support | No Frappe warranty applies; your team triages, or contracts external support |
| Evaluation setup | Not a self-hosting option; confirm trial terms with Frappe | The single-file demo is for short-lived evaluation only, so production needs Compose or bench |
What you pay for in each model and what drives it up
Frappe Cloud is a recurring plan fee, self-hosting is a recurring infrastructure and labor cost. On Frappe Cloud you pay per plan. Site plans, a single site with multiple apps on shared servers, start at 5 US dollars per month, and Server plans, a full virtual machine for multiple sites and benches, start at 40 US dollars per month, according to the Frappe Cloud pricing page. The ERPNext pricing page separately lists dedicated servers from 125 US dollars per month. Those are published starting points, not totals: the plan you need depends on how many sites, apps and environments you run, and the cloud provider and region you choose. Self-hosting ERPNext carries no license fee because the software is GPL-3.0, but you pay for the virtual machines or data center hardware, storage, offsite backups, the monitoring you set up, and the staff who install, patch and upgrade it. Confirm those figures in your own environment before comparing them to a plan price.
One-time costs are the same in both models, but recurring costs are not. Initial setup, data import, custom app development and configuration are one-time work in either model. The ERPNext Data Import tool handles CSV or Excel files in batches, and the documentation advises importing only a few thousand records at a time, so migration effort scales with your data volume and cleanup. On Frappe Cloud, upgrades, restores, monitoring and offsite backups are included in the site plan, which removes most recurring labor from your budget. Self-hosting shifts that labor to your team or to a partner. The recurring items that grow the bill are plan upgrades as sites multiply, support contracts, and the people hours needed for each ERPNext minor release.
Ask for a quote that separates each component, and check what warranty depends on. Frappe's supported versions page says Product Warranty requires a listed version and a matching Frappe Cloud support plan, and deployments outside an eligible plan get no warranty services. Product Warranty covers bug fixes from Frappe engineers, not functional support, so price functional help separately. Ask any implementation partner for one-time fees for setup, data import and customization, recurring fees for hosting, backups, monitoring and support, and a written statement of which items each covers. Ask Frappe Cloud for the plan, cloud provider and region behind each figure, and confirm the Product Warranty terms for your ERPNext version. Ask DeployOpen for a fixed-scope quote with deliverables and timelines written out before work starts.
Moving ERPNext from self-hosted to Frappe Cloud, and back
This sequence gets an ERPNext site from one environment to the other with a verified backup, a tested data path and a rollback plan in place before DNS changes. It also tells you what each side of the move must confirm first.
Confirm version and plan eligibility
Check that your ERPNext and Frappe Framework versions appear on the supported versions page, and confirm that the target Frappe Cloud plan carries the matching support subscription. Warranty coverage depends on that match, and deployments outside an eligible Frappe Cloud plan receive no warranty services or support. The step is done when the version, plan and support tier are written into the migration plan and signed off by the business owner. Moving back to self-hosting has the same check, because you lose warranty coverage once the site leaves an eligible plan.
Audit custom apps and Server Scripts
List every custom app, integration and Server Script on the source site. Server Scripts are disabled by default from version 15 and must be enabled through the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Move any logic that depends on them to a custom app or to a plan that supports it, and confirm this with Frappe before you commit. The output is a inventory that marks each item as portable, needs rework, or blocks the move.
Take and verify full backups
Take a full backup of the database and the files on the source environment, then restore it to a separate test site on the target platform. Your team or DeployOpen can run the restore and compare record counts, document numbers and general ledger totals against the source. Keep the source backup and a copy stored outside both environments until the cutover is closed. The check is complete when the restored test site matches the source on the agreed reconciliation points.
Migrate bulk data in batches
Load master data and transactional history that are not part of the restored database through the Data Import tool, using CSV or Excel files and the downloadable templates. The documentation advises importing only a few thousand records at a time, and child table rows must follow their parent records. Import in batches, reconcile each batch against the source, and log any rejected rows. The step is done when each batch reconciles and the import log has no unexplained rejections.
Test integrations including LDAP and social login
Test every connected system against the target site, including LDAP directory sign-in and social login through Social Login Key settings if your organization uses them. Confirm that users map to the right roles, that scheduled jobs and webhooks fire, and that outbound email and file storage work. Run these tests with named business users, not only administrators. The step is done when each integration has a documented test case that passes on the target environment.
Rehearse cutover and a tested rollback
Run a full rehearsal of the cutover on the target, timing each action and recording who executes it. Write a rollback procedure that returns users to the source environment, including how to handle transactions entered during the rehearsal. A migration without a tested rollback should not proceed, so the rehearsal must include the rollback path. The output is a signed runbook with a go or no-go checkpoint, and the rehearsal log shows the rollback worked.
Cut over DNS and freeze the source
Freeze writes on the source environment, take a final backup and restore it to the target, then point DNS for the site to the new environment. Confirm that the certificate, custom domain and login pages resolve correctly and that the post-cutover reconciliation matches the frozen source. Keep the source available in read-only mode until the rollback window in your runbook closes. The step is done when users sign in on the new environment and the reconciliation report is accepted.
Decommission the old environment
After the agreed validation period, retire the source environment, revoke its credentials and remove its scheduled jobs and integrations so it cannot write data. Archive the final backup and migration records according to your retention policy. Update your asset register, monitoring and runbooks so they point at the new environment. The step is done when the old environment is removed, access is revoked, and the archive is confirmed as restorable.
Questions buyers ask before choosing a hosting model
What does Frappe Cloud cost to run ERPNext?
Frappe Cloud starts at published prices, but the total depends on the plan type and what you add. The Frappe Cloud pricing page lists site plans, a single site with multiple apps on shared servers, from 5 US dollars per month, and server plans, a full virtual machine for multiple sites and benches, from 40 US dollars per month. The ERPNext pricing page lists Frappe Cloud servers from 20 US dollars per month for shared instances and 125 US dollars per month for dedicated servers. Costs rise with the number of sites, server size, cloud region and dedicated AWS or OCI instances, which Frappe recommends for workloads where uptime and durability are critical. Ask for a quote that lists each plan and environment separately, plus any implementation work, because implementation is scoped on its own and is not included in the hosting plan.
How much internal effort does self-hosting ERPNext take?
Self-hosting is free under GPL-3.0, but the work is paid for in staff time or services. Your team owns installation, upgrades, backups, monitoring, patching and the server estate. The requirements are specific: Frappe Framework v16 needs MariaDB 11.8, Redis or Valkey 6 or later, Python 3.14 and Node.js 24, according to the Frappe installation documentation. A production layout built with frappe_docker runs MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx, and each service needs monitoring and restart handling. Effort grows with the number of sites, custom apps, integrations and how often you apply ERPNext minor releases. Before comparing this with a managed plan, confirm who is on call, how often restores are tested and how upgrades are rehearsed.
Can a small team run ERPNext on its own servers?
A small team can, if it has a named owner with Linux, database and Python skills and time set aside for upgrades. The ERPNext pricing page says self-hosting suits companies with a tech team, and that is the test to apply first. Check whether one person can cover patching, restore tests and an urgent fault outside working hours. If not, two routes reduce the load. Frappe Cloud site plans include upgrades, restores, monitoring and offsite backups, which removes much of the routine work. A retainer with an external services firm can also cover ongoing operations. Either way, a self-hosted team carries fixes without Frappe warranty, so test the setup in staging and prove a restore before go-live.
How long does it take to move ERPNext between hosting models?
No migration duration is published for moving ERPNext between Frappe Cloud and self-hosting, so ask for a written estimate built on your own data and customizations. The main drivers are data volume, the number of sites and apps, custom scripts, integrations with external systems and the cutover window you can accept. The ERPNext Data Import tool handles CSV, Excel and public Google Sheets, and its documentation advises importing only a few thousand records at a time, which affects how long large loads take. Ask the provider for a parity test plan, a rehearsal of the cutover, a rollback procedure, a named person responsible for the switch and a statement of what the quote includes and excludes.
Does Frappe warranty cover a self-hosted ERPNext deployment?
No. Frappe's supported versions policy says customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage, and that deployments outside an eligible Frappe Cloud plan do not get warranty services or support. Product Warranty covers support from Frappe engineers for fixing bugs in Frappe apps such as ERPNext and in Frappe Cloud, raised as tickets. It does not include functional support, so even on Frappe Cloud you need your own process for how the system is used. For a self-hosted deployment, fixes come from your team, the open-source community or a services provider under a separate agreement. Confirm current terms with Frappe on the supported versions page before you decide.
Can DeployOpen run ERPNext under a fixed-scope agreement?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside a client's own infrastructure, including cloud accounts, data centers and air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. Its implementation work is built around self-hosting, so for a Frappe Cloud route, confirm in writing which tasks DeployOpen would cover on top of the Frappe Cloud plan and which remain with Frappe. The scope document should state that decision explicitly.
Which ERPNext version should a new deployment start on?
For a new deployment, the longer published support window favors version 16, but confirm dates before you commit. Frappe's supported versions page says ERPNext and Frappe Framework version 14 reached end of life on January 31, 2026, version 15 is planned for support until the end of 2027, and version 16 until the end of 2029. Version 16.0.0 of ERPNext was released on January 12, 2026, and v16.51.1 on October 15, 2026, while v15.123.0 followed on October 14, 2026. Frequent minor releases mean your upgrade routine matters as much as the starting version. Check that your hosting model can apply those minor releases on the schedule your change process requires.
What breaks when custom scripts move off Frappe Cloud?
Custom Server Scripts may not run on Frappe Cloud shared benches, so inventory them before you choose a model. 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, according to the Frappe Server Script documentation. Self-hosting gives you control to enable them, but you then own the code review, access control and change testing that come with running arbitrary Python inside the application. Ask for a list of scripts, custom apps and the plan features each one needs, and check that list against the plan you are considering.
How DeployOpen scopes, delivers and supports self-hosted ERPNext
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For ERPNext, that means the work that Frappe Cloud would otherwise carry for you is written down, owned by your team and run on infrastructure you choose.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope records which ERPNext and Frappe versions, apps and sites are in play and where they will run.
- We document which upgrade, backup, monitoring and warranty-equivalent duties move to your team if you leave Frappe Cloud.
- The scope asks for your cloud provider, region, uptime targets and data residency needs before any quote is issued.
How we build
- We set up the ERPNext deployment on your servers using the installation route agreed in scope, whether Docker Compose or bench.
- Production services such as MariaDB, Redis, background workers, the scheduler and Nginx are configured and tested together.
- Custom apps, server scripts and integrations are reviewed against your change process, including whether server scripts are enabled.
- Backup and restore procedures are tested on a copy of production data before handover, not assumed to work.
How we hand over
- You receive runbooks covering install, upgrade, backup, restore, monitoring and access control for your ERPNext environment.
- Your team gets a walkthrough of the upgrade path between ERPNext minor releases and major versions, so updates are planned, not reactive.
- Documentation maps each operational task to the person or team that owns it after the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Retainer scope should be confirmed in writing, including response expectations, since we do not publish fixed service levels.
- Ask us to confirm which functional questions fall outside retainer support, because Frappe's warranty covers bug fixes, not functional help.
