# frappe press: the open-source platform behind Frappe Cloud > Press is the software that runs Frappe Cloud, and it is published in full rather than kept private, which is unusual for the infrastructure of a commercial hosting product. The readme explains why it exists in a paragraph of history: an internal platform built for one product grew into a self-service service for many, and the customers who were using it asked for control they did not have. **frappe/press** — Full service cloud hosting for the Frappe stack - powers Frappe Cloud - Repository: https://github.com/frappe/press - Website: https://frappe.io/cloud - Stars: 573 · Forks: 429 - Language: Python - License: AGPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/frappe-press ## What the project is Press is described as a full service cloud hosting platform for the Frappe stack, and it powers Frappe Cloud. The readme's own summary is that it is a one hundred percent open source cloud hosting for the Frappe stack. That last phrase is the interesting one, because the software is the infrastructure of a commercial hosting product. Publishing it in full is a strategic choice rather than an accident, and it is worth understanding what it buys. A hosted platform has a particular kind of lock-in, and it is not the lock-in of a proprietary API. It is the lock-in of an operations team: the customers cannot see how their site is deployed, they cannot deploy it themselves, and if the vendor raises prices or changes the terms there is no alternative. Publishing the whole platform says that the customers are free to leave, and that is a much stronger position than a promise in the terms of service. It also means the platform is a development site, because every change a customer asks for has to be made somewhere, and making it in the open means the next customer gets it. For a hosting product with a self-service tier, that is the difference between a platform that accumulates features and one that accumulates patches. The stack it hosts is the Frappe framework, which is a full-stack web application framework written in Python and JavaScript, providing a database abstraction layer, user authentication, and a REST interface, and it is the framework behind a well known open-source business application suite. The interface layer is a separate Vue-based component library built for single-page applications on top of that framework. The project is licensed under the Affero General Public Licence, which is the copyleft licence with the network clause, and that is the natural choice for infrastructure a vendor runs as a service: the licence requires that users who interact with it over a network are offered its source. The development branch is the default one, and the release history shows a very high patch rate, with several releases in a single week in the version numbering, which is what a live hosting platform looks like in its version numbers. The site, the documentation, a public chat group, a discussion forum, and a pre-commit hook for contributors round out the picture of a project that expects to be developed in public. ## The history, and why the platform looks the way it does The motivation section is the most valuable part of the readme, because it explains the product in terms of two specific failures of the thing that came before it. The original setup was an internal cloud platform with a name of its own, built to automate creating and hosting sites when customers signed up on the company's website. It was built primarily to host the flagship business application product, and it was an internal tool: good at one job, built for one product. Then two things happened, and the readme separates them cleanly. The first is scope. As the customers' needs evolved, they began asking to host custom applications, and that was not a priority for the internal platform, which had been designed around hosting one product on one framework. So the internal platform was the wrong shape, and a general one was needed. The second is control, and this one is the more interesting reason. The customers lacked full control over their servers: no remote shell access, no ability to manage updates, and limited flexibility in interacting with their environment. That list is worth dwelling on, because it is a list of things a hosting customer assumes are ordinary and which a platform built for a single product simply does not provide. The reason is structural. An internal platform that deploys one product knows exactly what the deployment looks like, so it can hide the machinery. A platform hosting arbitrary applications cannot make those assumptions, and once it stops making them it has to give the customer the access, the update controls, and the configuration surface that the deployment needs. And the conclusion the readme draws is that this led to launching the self-service cloud platform, built to give customers complete control over their hosting experience. So the product is a direct answer to two specific complaints, and the feature list can be read as the answer. The self-service part is the dashboard and the marketplace. The control part is remote access, update management, and the environment interaction. Every feature in the list traces back to one of those two sentences, which is a good sign for a readme that explains itself rather than listing adjectives. ## The features, and the one that explains the others The key features list has six entries, and they are best read as one idea with six faces. The first is multitenancy, and the way it is described tells you the interesting part. Multiple sites live on a single platform, each with its own application version, and they can be updated independently with minimal downtime even for large sites. That is the technical centre of the whole product. Independent updates per site on a shared platform is not a scheduling nicety; it is the difference between a platform where a security patch ships to everyone within a day and one where it ships to nobody for a month because a single large customer is mid-deployment. And the phrase about minimal downtime even for large sites is the hard part: an update on a big site means moving a live application to a new version without dropping requests, which is the same problem every zero-downtime deployment system solves and which most of them solve badly. The second feature is the dashboard, a single interface for managing applications, servers, sites, billing, backups, and updates, with real-time insight into what is happening. The third is permissions, with granular access controls and the ability for a team owner to manage roles and resources, so that people see only the parts relevant to their role. The fourth is simplified management, which lists automated backups, real-time monitoring, role-based access, and easy scaling. The fifth is billing, with daily or monthly subscriptions, flexible payment methods, wallet credits, and integration with the company's own business application suite, which is a nice touch for a company that already has a system of record and can reconcile against it. And the sixth is the marketplace, where developers list their applications with flexible pricing models, and the platform performs compatibility checks, and sales and payouts are handled. The compatibility check in that last one is the detail that shows the marketplace is not a directory. A marketplace where anything can be listed is a marketplace where a customer installs something that does not work on their site, and a check that catches the incompatibility before the install is a check that requires the platform to know what it is checking, which means the multitenancy model has to be understood in enough detail to evaluate a deployment against it. ## Under the hood: the agent, containers and configuration management The under the hood section lists the components, and the list explains the architecture better than a diagram would. The first two are the framework and the interface library, which are the application's own stack. The interesting one is the third: the agent, described as a Flask application designed to work alongside the platform, which provides a command line interface for the platform to communicate with the sites and the benches. That single sentence carries a lot of design. The platform does not reach into a server to run commands over a remote shell. Instead, an agent runs on the server, and the platform talks to the agent through its command line interface. The agent is the only thing with access to the site, and every operation the platform performs goes through it. That architecture has a long list of consequences. A platform that shells into a server has to be trusted with credentials and with a remote execution protocol, and the trust boundary is wherever the platform's code runs. A platform that talks to a per-server agent has a narrow, well defined interface, and the agent is the component you have to make secure. Operations become idempotent and retryable, because a command that fails halfway can be re-run. And the platform can be updated without touching the servers, because the protocol between them is stable even when the platform is not. The bench is the other piece of vocabulary worth explaining, because it is specific to this stack. A bench is the unit of a deployment: a directory holding a site's application, its configuration, and its dependencies, with a process manager running the application and background workers. It is the thing you deploy, and it is the thing the agent manages. The screenshot gallery includes one of a bench group update, which is the operation of updating a group of benches together, and that is the multi-tenancy story visible in a picture. Then there are the two tools that do the actual work, and the readme describes them in their own terms rather than as a choice. Containers, which are the units the platform deploys, and an IT automation tool for the management, configuration and deployment of systems and applications, which is how the same configuration reaches a hundred servers without somebody typing it a hundred times. The combination is the standard arrangement for a hosting platform: containers for the workload, configuration management for the machine, and an agent on the machine as the only privileged path between the two. Nothing about it is novel, and putting the three together in a way that a self-service product can drive is the actual work. ## The repository, and what a mature service project looks like The top level of the repository is long, and it is a good catalogue of the practices of a project that has been running a commercial service for a while. There are the code quality tools, and there are more of them than a small project would have. A coverage configuration and a coverage service badge. A type checker configuration for Python. A linter configuration for Python. A configuration for a JavaScript linter and formatter that is not the one most people use. A spell checker configuration, which matters for a project with a documentation site, a user interface in several languages, and a marketplace with developer listings. A commit message linter configuration and a separate document of the commit guidelines, which together mean that the change log is generated rather than written. Then there are the security tools, and this is the part that stands out. There is a baseline file for secret detection, which is the record of the secrets the scanner has already been shown, so that the existing ones do not fail the build forever. There is a file telling the semantic scanner what to ignore, and a separate file of custom scanner rules written for this project specifically. A project that writes its own rules for a static analyser is a project that has had the analyser find something general-purpose tools miss, and that is worth doing precisely in the code of a hosting platform. And then there are the files that are pure process. A file that tells the version control system to ignore certain revisions when attributing blame, which is what you do after a bulk reformat and it is a kindness to your colleagues. A file that says who owns which part of the code. A configuration for a merge automation tool, which is how a large team stops a pull request from sitting for a week. And two files that are instructions for coding agents, which is a project telling an assistant how to work in this codebase. There are also two files with unusual names that speak to how a design-led team works: one called for the taste of the project, and one about how to test the interface. The first is almost certainly a document of design preferences, the kind of thing a studio writes down so that the argument is had once and then referred to. The second is a guide to interface testing, which is what a project with a large interface needs when the interface is tested by a person and a screen reader rather than by an assertion. And the directories show the deployment surface: a directory for the platform itself, one for the dashboard, one for shared libraries, one for deployment, one for debugging, one for the documentation, one for the change log, and one for building on architectures other than the developer's own, which is the arm builds directory. ## The build, and the three stylesheets The package manifest is for the front end, and it is worth reading because the build script tells you how the product is put together. The package is private and is an ES module project, and the scripts are grouped into four rough families. The development scripts run the dashboard's development server and the test suite, with the watch script pointing at the development one. The build scripts set the production environment variable and then call a build-all script, which itself fans out into four steps: building the application, and building three stylesheets. The three stylesheets are the interesting part. Each one runs the utility-first CSS compiler over a different input file and writes to a different output file, and each has its own configuration file. The inputs are the email styles, the marketplace styles, and, interestingly, the marketplace styles again for the other surface, with the configuration coming from the templates directory for that surface. Three separate builds with three separate configurations is a deliberate answer to a question that is easy to get wrong. The platform has at least three distinct rendered surfaces: the dashboard, the marketplace, and the self-service pages, and the email templates. They are served from different places, they are built at different times, and they have different requirements. A shared stylesheet would mean that a change to the marketplace's colours also changes the dashboard's, and a shared configuration would mean the email template inherits a container query setting that does not apply to it. Three builds cost a few seconds of build time and buy independence. The email build is the one that shows the constraint. A stylesheet for an email is compiled in a different way from a stylesheet for a browser, and the compatibility package in the development dependencies is there because the build has to work with a postcss version that the compiler expects. The testing setup is the other thing worth naming. There are end-to-end tests with a browser automation runner, and three scripts for them: the normal one, one that runs with a visible browser so you can watch the failure, and one that opens the report. Having the headed variant as a first class script is a small piece of pragmatism that saves a lot of time when a test fails in a way the report does not explain. And the documentation has its own three scripts for a documentation site generator, with a development server, a build, and a preview. The fact that the documentation is a site with a preview command means the documentation is written to be read in a browser, which is what a hosting product's documentation for self-hosters needs to be. The last script is the one that explains the repository structure. The postinstall hook changes into the dashboard directory and installs its dependencies, which means the dashboard is a separate project with its own dependencies, and the top level coordinates the two rather than merging them. ## Conclusion Press fits an organisation that wants the whole Frappe Cloud platform rather than the hosted product, and it fits a Frappe developer who wants to see how a multi-tenant site platform is put together, since the code is public. It does not fit somebody who just wants a site hosted. Verify first that the self-hosting path is documented for your environment, since the readme sends you to a setup guide rather than to a list of steps, that the agent can reach every server you intend to onboard, because it is the component that talks to the sites and the benches, and that the parts of the platform you will actually use are the ones the upstream team maintains, since the project is a live product rather than a stable library. ## FAQ ### What is the Frappe Press project? It is the open-source platform behind Frappe Cloud, providing multitenancy with independent per-site updates, a dashboard for managing applications, servers, sites, billing, backups and updates, granular permissions, automated backups and monitoring, subscription billing with wallet credits, and a marketplace for application developers. ### Why was Frappe Press built? Because the company previously hosted customer sites on an internal platform built primarily for its flagship business application product. Customers asked to host custom applications, which that platform was not designed for, and they lacked control over their servers, with no remote shell access, no ability to manage updates and limited flexibility, which led to a self-service platform. ### What is the agent in the Frappe Press architecture? It is a Flask application that runs alongside the platform and provides a command line interface for the platform to communicate with the sites and the benches. The platform never reaches into a server directly, so the agent is the only privileged path to a host, which keeps the trust boundary narrow and makes operations retryable. ### How is the Frappe Press front end built? With a production build that fans out into four steps: building the dashboard application and compiling three separate stylesheets, for the email templates, the marketplace, and the self-service pages. Each stylesheet has its own configuration file, which keeps the three rendered surfaces independent of each other rather than sharing one set of rules. ### What security tooling does the Frappe Press repository use? A secret detection baseline that records the findings already accepted, an ignore list for the semantic analyser, and a file of custom analyser rules written for this project specifically. There is also a coverage configuration, a type checker configuration, linter configurations for both languages, a spell checker configuration, and a commit message linter with a separate document of the commit guidelines. ## Sources - [frappe/press on GitHub](https://github.com/frappe/press) - [License: AGPL-3.0](https://github.com/frappe/press/blob/develop/LICENSE) - [Project website](https://frappe.io/cloud) - [README](https://github.com/frappe/press/blob/develop/README.md) - [Releases](https://github.com/frappe/press/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/frappe-press