Frappe Cloud vs Self-Hosted ERPNext on Ubuntu: Which One I Recommend, and When
DevOps — — Ali Raza
A practitioner's comparison of Frappe Cloud and self-hosted ERPNext on Ubuntu 24.04, with a decision checklist and the ops practices self-hosting demands.
"Should we host on Frappe Cloud or on our own server?" comes up on almost every audit call I run, usually inside the first ten minutes. Over the years my answer has settled into a default and a short list of exceptions. The default is Frappe Cloud. The exceptions are real, and I have built on both sides of the line often enough to know where it sits.
Frappe Cloud is the managed hosting service run by Frappe Technologies, the company that builds ERPNext and the Frappe Framework. That matters more than it sounds. The people who wrote bench are the people running your bench, and when a release breaks something they usually know before you file a ticket.
What you get in practice: sites provisioned in minutes, automated daily backups with off-site copies, TLS certificates handled for you, MariaDB and Redis tuned by people who tune them all day, and updates you approve from a dashboard instead of running from an SSH session. The Marketplace installs apps like HRMS or Payments without a command line, and private benches let you deploy your own custom apps straight from a GitHub repository. Pricing is on published plans, so a buyer can put a number in the budget before talking to anyone.
What you give up is the box. There is no root access, no apt install of your own, no hand-edited Nginx config, no MariaDB parameter you can change yourself. If a custom app needs a system package or an unusual Python dependency, that is a conversation with support rather than a five-minute change. For most businesses running ERPNext with some custom fields, a few Server Scripts and a couple of reports, this constraint never comes up.
Self-hosting means a Linux server you own or rent, and in 2026 that means Ubuntu 24.04 LTS. The stack is bench or frappe_docker, Nginx in front, MariaDB, Redis for cache and queues, background workers and the scheduler under supervisor, and certbot for certificates. I published a step-by-step guide for installing ERPNext v16 on Ubuntu 24.04 on my GitHub, from bench setup to production deployment, because I was tired of every new server starting from scattered forum threads.
The pitch for self-hosting is control, and control is worth paying for in specific situations. The first is compliance and data residency. Healthcare privacy was a hard constraint on the Gainhis clinic network in Saudi Arabia, and the Saudi personal data protection law is not the only regime that cares where patient records physically sit. A Spanish trading company I work with lives under GDPR. A municipality like Fraijanes in Guatemala holds citizen and revenue data, and public-sector buyers often prefer infrastructure the institution itself controls. Frappe Cloud runs in a set of regions; whether one of them satisfies your lawyers is something you verify, not assume, and when the answer is no, a server in the right country is the simplest way to make the question go away.
The second is customisation depth. The Alkhidmat Foundation HR platform is 60-plus custom DocTypes, a ZKTeco biometric integration, a React self-service portal and a Vue/Ionic PWA on top of Frappe HRMS. Custom apps of that depth can run on a Frappe Cloud private bench, but every system-level dependency, worker tuning decision and integration with devices on the client's own network is friction there and trivial on a server you administer.
The third is cost at scale. Frappe Cloud prices by plan tier, and the tiers are fair for a site of ordinary size. Once you run several companies, a large stock ledger, heavy scheduled jobs or many concurrent users, a single well-specified VPS or dedicated server gets cheaper per unit of work than the equivalent managed plan. The catch is that the hardware saving is only real if nobody is being paid to babysit the machine. Bookfyd, the tutoring marketplace, runs on a lean self-hosted stack behind Nginx on Ubuntu because it is a custom Frappe backend with a React frontend and a tight budget, and the ops load of a single site like that is small.
Now the part vendors skip. When you self-host, you own everything Frappe Cloud was doing quietly: backups, monitoring, security patching, upgrades, disk space, certificate renewal, MariaDB when it runs out of buffer pool. None of it is hard. All of it is relentless, and the first time it matters is the first time it is missing.
These are the practices I put on every self-hosted ERPNext server before the client ever logs in:
- Backups leave the machine. bench --site yoursite backup --with-files on a cron schedule, then rclone or restic pushes the dump and the files to object storage with another provider or in another region. A backup on the same disk as the database is not a backup. - site_config.json travels with the backup. It holds the encryption_key; without it, every stored password, API secret and OAuth credential in the restored database is unreadable. - Restores are rehearsed. Once a month, restore the latest dump into a scratch site with bench --site test.localhost restore, log in, open a few DocTypes, run a report. - A staging site takes every upgrade first. Restore the latest production backup into staging, run bench update or bench migrate there, test the flows the business actually depends on, then schedule production in a maintenance window. I once locked a table during live appointment booking by skipping this step. Once was enough. - Monitoring watches the things that fail. An external uptime check on the site, alerts on disk usage, the MariaDB slow query log turned on, the Error Log DocType reviewed weekly, and a Sentry DSN in site config so exceptions reach you before users do. Watch Redis memory too; cache and queues share a host. - Security updates are automatic and boring. unattended-upgrades for Ubuntu security patches, ufw allowing only SSH, 80 and 443, key-based SSH only, fail2ban, and a fixed day every month for the framework and app updates that cannot be automatic. - Customisations live in a custom app, not in production. Fields as fixtures, workflows exported, data changes as patches. If it is not in the repository, it does not exist.
If that list reads as obvious, self-hosting is probably right for you. If it reads as a second job, it is one.
This is the checklist I actually walk buyers through:
- Company size. A small team on a single company with standard modules: Frappe Cloud, almost without exception. Multiple companies, large transaction volumes or heavy background jobs: cost out both honestly. - Compliance. Any regulatory requirement about where data sits, who can access the host, or infrastructure-level audit logging: self-host in the right jurisdiction, or get written confirmation that a specific Frappe Cloud region meets it. - In-house IT. Nobody who knows Linux beyond restarting a service: Frappe Cloud, or self-host only with a retainer that covers ops. A sysadmin who already runs Ubuntu servers for you: self-hosting is cheap to add. - Customisation depth. Configuration, custom fields, Server Scripts and reports: Frappe Cloud. Custom apps with system dependencies, on-premise device integrations or unusual worker tuning: self-host. - Integrations. Cloud APIs such as payment gateways or WhatsApp: either works. Devices inside the client's network, like biometric terminals or label printers: a server the network can reach is simpler.
Two answers I give that surprise people. First, the decision is not permanent. A Frappe Cloud site backup restores onto a self-hosted bench, and the reverse is true too, so you can start managed and move when scale or compliance demands it. That lowers the stakes on getting it perfect at kickoff.
Second, hosting is a line item in my Blueprint, not an afterthought. Every fixed-scope implementation I quote states where the site will live, who owns the backups, and what the monthly ops picture looks like after go-live, because a fixed quote that leaves hosting vague is not a fixed quote. For clients who self-host, the retainer usually covers exactly the list above: backup checks, the staging upgrade cycle, monitoring alerts and the monthly patch window. For clients on Frappe Cloud the retainer is lighter and spends its hours on the ERP itself.
If you are weighing these two options right now, book the free 45-minute audit call. We will go through your compliance situation, your IT capacity and how deep your customisation really needs to be, and you will leave with a written Blueprint and a fixed quote that states the hosting decision in plain terms.