On Page Navigation
On Page Navigation
Frappe Cloud runs the infrastructure well. It does not decide when to upgrade you, check your custom apps against the new release first, or prove that your backups actually restore. We cover that layer for whatever you run on it, whether that is ERPNext, Frappe HR, Helpdesk, or an app your own team wrote: planned upgrades, verified backups, uptime and job queue monitoring, staging, and someone to call when production breaks. The plan is included in the price.
Built to stay upgraded and recoverable
Plenty of providers will put a Frappe site on a server and call it hosting. The difference shows up on the day a version upgrade breaks a custom app, or the day somebody needs last Tuesday's data back. We run the unglamorous work that decides those outcomes: compatibility checks before upgrades, restores that get tested on a schedule instead of assumed, and a written record of what is installed and why. None of it is exciting. All of it is why the bad days stay short. Where the instance is running ERPNext, this sits alongside the implementation and support side of that work.
Day to day it looks like very little happening, which is rather the point. Backups run and are restored somewhere safe to prove they work. Updates are staged and checked against your custom apps before they touch the live site. Certificates renew without anyone having to remember them. Resource use is watched, so growth becomes a planned conversation rather than a Monday outage. And when you do need something, you ask a person who already knows what is installed on your instance and why it is there.
Almost every provider takes backups. Far fewer have ever restored one. We treat an untested backup as an unproven claim, so restores get run into a throwaway site on a schedule and the elapsed time gets written down. You find out that recovery works on a quiet Tuesday rather than during an outage.
Upgrades rarely break Frappe itself. They break the app somebody wrote three years ago that nobody has looked at since. We keep an inventory of what you run and check each piece against the target release before an upgrade is scheduled, which is why our upgrades tend to be uneventful.
A staging site that has not been refreshed in six months tests nothing. Yours gets rebuilt from production on a schedule, so when a change passes there, what you have is evidence and not a hopeful signal. Every upgrade and every app install goes through it before production sees anything.
Because we resell Frappe Cloud, the platform plan and the management arrive as one number on one invoice. There is no hourly billing, so asking a question costs you nothing. If your usage grows past what your tier covers, you hear the new figure before anything changes rather than after.
Monitoring that shouts about everything gets ignored within a month, which makes it worse than no monitoring at all. We take first look, group related noise, and tune thresholds against how your instance actually behaves. What arrives in your inbox needs a decision, with the background already gathered.
The Frappe Cloud account carries your name, not ours. We work in it with access you granted and can revoke this afternoon. Every app version, backup setting, and restore result is written down and handed over as we go, so leaving us is paperwork, not a rescue project.
Why teams stop self-managing
Most Frappe instances are looked after by whoever set them up, in the gaps between their real job. That works until an upgrade goes wrong or somebody needs a restore in a hurry. Here is how the arrangement compares to a subscription where keeping the instance healthy is the actual job. One subscription covers the instance regardless of which of the Frappe applications you have running on it.
Self-managed instances postpone upgrades until something forces the issue, and by then the jump spans several releases at once. We upgrade on a planned cadence, which keeps each step small enough to test properly beforehand.
Backups running is not the same as backups working. We restore into a throwaway site on a schedule and record how long it took, so your recovery time is a number you already know.
Failed background jobs are silent. Reports stop arriving and emails sit unsent for weeks before anybody connects the two. Queue depth and failures are monitored here, and we go after the cause, not just the backlog.
When your one technical person is on holiday, a self-managed instance has no escalation path at all. A subscription puts a team behind it, and production problems jump ahead of the queue on either tier.
Paying for headroom you never touch is a cost, and hitting the ceiling during month end is a much bigger one. We watch real usage against your plan and say when to move, in either direction.
In-house changes live in somebody's memory. When something breaks, the first question is what changed, and nobody can answer it. We keep a record of apps, versions, and configuration changes, so investigation starts with facts.
Built for teams running real operations
This suits organisations already live on Frappe, whether that is ERPNext, one of the official apps, or something built in house, where people work in it daily and an outage stops something that matters. If your instance is a pilot with three users, you do not need this yet. If real work runs through it, the cost of one bad upgrade already exceeds the subscription. And if you have not committed to self hosting at all, there is a fair argument for not starting, because on Zoho the hosting question never arises. For a smaller business the managed Zoho route is a simpler place to be, and we would say so rather than sell you infrastructure you do not want.
How we work with you
Onboarding is deliberately unexciting. We take stock of what you actually have, fix whatever is already wrong before agreeing to keep it running, then settle into a rhythm of planned upgrades, verified backups, and monitoring you never have to look at yourself.
1
Before agreeing to run anything, we look at what exists. Which apps are installed and at what versions, how backups are configured, whether anybody has ever restored one, what the job queue looks like, and how close the current plan is to its limits. You get that written up whether or not you proceed, because knowing the state of your own instance is worth having either way.
2
Whatever the audit turns up gets sorted before the subscription settles into routine. That usually means bringing app versions back into line, reconfiguring backups and running the first real restore, standing up a staging site that mirrors production, and clearing whatever has piled up in the failed job queue. It is included, not a separate onboarding fee.
3
From there it becomes a rhythm. Upgrades get scheduled with you and tested on staging first. Restores get proven quarterly. Monitoring runs continuously and we take first look at whatever it finds. Once a month you get a short written summary of what was upgraded, what alerted, what we changed, and what we suggest next.
Pricing
Standalone Service
DETAILS
Standalone Service
DETAILS
Testimonials
Everything we manage
