All posts

Frappe Cloud keynote: V2 rebuilds the platform around virtual machines

· Aarav Jhawar · 8 min read · Updated

Frappe Cloud scale figures shown during the Frappe Cloud V2 keynote
Summarize this article

Frappe Cloud now hosts 30,000 sites for 5,600 customers and handles 2,000 deployments a day. Its users have installed 9,000 custom apps, and another 1,000 sites are created each day. At Frappeverse Mumbai 2026, Aditya Ganpat Hase, founder of Frappe Cloud, used that scale to explain why the team chose a rewrite.

Frappe Cloud V2 replaces a central Press application and shared database infrastructure with virtual machines and three focused components: Pilot manages Frappe sites, Atlas manages infrastructure, and Central handles the customer-facing cloud experience.

V2 remains new and experimental. Pilot is ready to use today as a replacement for Bench, and the existing Frappe Compute service remains available on V1. Frappe is targeting January 2027 for V2. The team showed enough of the interfaces to make the architecture concrete without presenting the wider platform as finished.

Reliability forced an architectural reset

Growth has changed the kind of problems Frappe Cloud needs to solve. Hase said customers added 900 custom apps in July alone, roughly the same number the platform had taken two years to accumulate earlier. More apps mean more builds, migrations and deployments moving through the same system.

The current architecture concentrates much of that work in Press. One application handles sign-ups, builds, deployments, backups, updates, billing and payments. It serves 30,000 sites and processes 2,000 deployments each day. Over time, each operational problem acquired a fix, and each fix added more complexity to the same application.

Databases created a second pressure point. Hase said about 90 percent of Frappe Cloud's downtime issues came from databases, and more than 60 percent of those database issues came from multi-tenancy. Sharing large MariaDB servers keeps entry prices low, but it also exposes sites to noisy neighbours. The team can identify an unusually demanding site, yet moving it away from other tenants can still take hours or days.

Frappe's answer is to give each customer a virtual machine and move backups, updates and other operations into that VM. Work that Press tracks globally today becomes local to the customer's environment. It also removes Docker from the Frappe-site deployment path presented in the keynote.

This is the core V2 bet: simpler isolation should improve uptime and performance while reducing the number of platform-wide failure points. It is encouraging to see reliability drive the rewrite. The team is not hiding the operational limits of the current design, and it has chosen a more understandable primitive for the next one.

Pilot brings Cloud's operating tools to self-hosted Frappe

Tanmoy Sarkar, an engineer at Frappe, introduced Pilot as a lightweight, self-hostable replacement for Bench. It manages the Frappe server, Redis, realtime services and sites through one interface. A Pilot installation uses roughly 40 to 45 MB of memory, has almost no prerequisites, and can be installed with a single script. A setup wizard can connect to an existing database or configure one automatically.

Pilot also addresses a long-standing gap between Frappe Cloud and self-hosting. Cloud customers received managed backups, monitoring and security tooling, while self-hosters still had to assemble much of that operating stack themselves. Pilot packages those capabilities into the same tool that Frappe Cloud V2 will use.

Pilot's site-creation interface lets users choose compatible Frappe apps from the marketplace while creating a site.

Aradhya Tripathi, an engineer working on Frappe Cloud's build system, demonstrated the new workflow. The marketplace now appears at the site level, so users can choose versions of apps that are compatible with their Frappe version while creating a site. Every Pilot instance keeps a local cache of the common marketplace repository, and app developers can list an app through a pull request.

Deployments change more substantially. The current pipeline builds a Docker image, pushes it, pulls it to the server and then migrates the site. Tripathi said the build and migration stages can each take 10 to 20 minutes. Pilot pulls app updates directly, restarts the services and runs the migration. Tripathi estimated that path to be roughly five to six times faster than the current deployment pipeline.

Marketplace CI checks a Frappe app for known migration blockers before it can be deployed through Pilot.

Marketplace CI moves another class of failures earlier. A marketplace app with blocking findings cannot be merged or deployed. Custom apps run through the same checks and receive advance warnings about known problems. The rules draw on migration failures Frappe has already encountered in production. Developers get a specific problem to fix before a migration starts, and the cloud support team avoids a preventable failed deployment.

Pilot does not assume that every failure can be predicted. Its interactive migration flow lets an operator skip a failed patch, restore a backup, or connect to the server over SSH, fix the problem and continue. A migration problem no longer requires rebuilding and redeploying everything from the beginning. Backups can also be skipped when an operator is prepared to resolve the migration interactively.

Pilot displays server CPU, load average, memory and disk analytics without requiring a separate monitoring stack.

Monitoring, security and development tools follow the same approach. Pilot includes server and site analytics, configurable resource thresholds and notifications. It also provides a firewall, a web application firewall with default protections against most known SQL injection and cross-site scripting attacks, a database analyser and a SQL playground. The goal is a consistent operating interface in development, on a self-hosted server and on Frappe Cloud.

Tripathi said Bench has now been officially archived and the team's development effort has moved to Pilot. Frappe is already using Pilot internally and wants users to try it and report problems. It is the part of the V2 story that people can act on now, even as the wider cloud architecture remains in development.

Atlas turns Frappe Cloud into a general-purpose VM platform

Ayush Chaudhari, an engineer at Frappe, presented Atlas, the infrastructure layer beneath Pilot. Frappe Cloud has historically rented virtual machines from providers including AWS, Hetzner and DigitalOcean. Frappe Compute, introduced earlier in 2026, added virtual machines running on bare-metal servers managed by Frappe itself. Chaudhari said most new virtual machines are now being created on that infrastructure.

Atlas develops that direction into a first-class part of V2. It groups Frappe-managed hardware into regional clusters and provisions virtual machines within them. Pilot can run on one of those VMs, but Frappe is not the only workload. Customers will receive full access through SSH and VPN and can start with a plain Ubuntu VM or a prepared image for another application, including WordPress.

The Atlas architecture places Pilot and other workloads on virtual machines inside regional clusters managed through Central.

The diagram shown on stage was refreshingly legible. Central sits above multiple Atlas clusters, each cluster contains virtual machines, and each VM can run Pilot or another workload. Backups, networking and VM lifecycle management move into Frappe's own infrastructure layer instead of being passed through to an upstream cloud provider.

The team also wants customers to bring their own servers into an Atlas cluster. Chaudhari described that capability as still “cooking,” so it belongs to the V2 direction rather than the list of available features. Current Frappe Compute on V1 is ready; the broader Atlas experience belongs to the V2 direction, which Frappe is targeting for January 2027.

Central separates a simple site from a fleet of servers

Prathamesh Kurunkar, an engineer at Frappe, called Central the front door to Frappe Cloud V2. Pilot deals with sites and apps, Atlas deals with infrastructure, and Central contains accounts, teams, permissions, billing and payments.

Central has two different experiences because Frappe Cloud serves two different kinds of users. Someone trying ERPNext, CRM or Helpdesk may only want a site. For that user, the proposed in-app cloud interface brings domains, plans, billing and marketplace apps into the Frappe site itself. There is no reason to learn the infrastructure console merely to run one product.

Partners and operators with many servers need a wider view. Central's orchestration interface can select a provider, region and plan, deploy a server through Atlas, and display servers on a map or in a list. It also surfaces load averages and resource use and allows operators to resize or remove a server.

Central's map view shows servers by region and exposes their resource state for fleet operators.

The team is rebuilding identity and access management as well. The current system ties a team's identity too closely to an email account. Central will introduce explicit team roles and clearer permission boundaries, which should make a shared cloud account more practical for implementation partners and larger customer teams.

Billing is getting the same reset. Kurunkar said billing generates roughly 2,000 support tickets each year. He also pointed to incorrect balances, missing tax invoices and unclear payment lifecycles in V1. Central will use a wallet ledger to show credits and debits, and invoices will break usage down by server. Billing starts when a server is created and stops when it is removed.

Central's invoice demonstration breaks charges down by server under a pay-for-what-you-use model.

Fallback payment methods are intended to keep sites running when a primary card expires or fails. Budget allocation and billing groups are planned for partners who need to control spending and separate costs by customer. These features were demonstrated or described as part of Central; they are not part of the current V1 release.

Central is also where Frappe plans to offer managed services. The keynote named object storage, email delivery, PDF rendering and hosted AI inference. That would move Frappe Cloud beyond hosting Frappe sites and closer to a general-purpose cloud for teams building on the framework.

What is available now

The keynote closed with a useful separation between today's products and next year's platform. Pilot is ready to use as a Bench replacement, though the team is still asking for feedback. Frappe Compute's current V1 bare-metal service is also available. Frappe is targeting January 2027 for V2, with Pilot, Atlas and Central forming the architecture shown in the keynote.

There is plenty left to prove before then, particularly around migrations, permissions, billing and operating a wider range of workloads. But the direction is coherent. Frappe Cloud is reducing central coordination, giving customers clearer isolation and bringing its production tooling to self-hosters. Pilot provides an early way to test that direction while the rest of V2 is built.

For more detail, watch the Day 2 Track 1 livestream from the start of the Frappe Cloud keynote.

Try Crator for free!Try out Crator for FREE

Get a free one week trial of the product, try out agents, play with your custom ERPNext deployments, and understand how Crator works