You can fork Mainbrella, change the prices, and sell the same kind of service we sell: Linux workspaces for AI agents. We put the accounts, billing, quotas, and workspace machinery in the repository too. Which leaves an awkward business question: why would anybody pay mainbrella.com?
I think that’s a reasonable question to ask of any hosted open-source project. If running it yourself is a serious option, the subscription has to buy something useful. For us, that something is the work of operating the service.
The part after the model answers #
Suppose you ask an agent to analyze a CSV and build a small website showing the results. The model can write a script, but something still has to install dependencies, execute it, keep the output files, and run the web server. You probably also want to open a terminal when the result looks wrong.
Mainbrella supplies that working environment. A program can start a Linux container, write files, run commands, and read the results through HTTP or our JavaScript and Python SDKs. A person can attach through SSH or the browser terminal and inspect the same workspace. Protected preview links let them open the app running inside it. The model and its API bill are separate.
E2B and Daytona serve this general need too: an agent gets an isolated environment it can operate through code. They also offer infrastructure ownership options; E2B describes self-hosting, and Daytona documents bring-your-own-compute deployments. Open source plus a hosted service is an established model. Mainbrella’s particular bet is that a fairly complete sandbox business can fit on Cloudflare’s developer platform.
That last word, business, adds quite a bit to “run this command.” Someone has to decide whose machine it is, whether they have access, how much compute they can consume, and when it must stop. Those decisions are part of the product we’re sharing.
A small cloud on a Mac #
I’ve run hundreds of containers locally on a Mac Studio using OrbStack, without trouble. It made the local option much more tangible than a “self-hostable” checkbox.
Wrangler, Cloudflare’s development tool, runs the Workers and local state; OrbStack supplies the Docker-compatible engine for the Linux containers. Mainbrella’s dev launcher starts the API and container Worker together. You can work on the control plane and the guest workload on one computer.
With the container engine running, the backend’s local development setup starts with:
npm ci
npm run db:migrate:local
npx wrangler d1 migrations apply mainbrella-preview-routes --local
npm run dev
The API is at http://localhost:8787, with its reference at /docs. Local accounts and access records are separate from production, and the app still checks entitlements. Configure local authentication and access; the included coupon tool can issue local trials without a Mainbrella payment. Starting the dev server alone doesn’t provision an account.
You pay no Mainbrella software or hosting fee for this. Your machine supplies the resources; check the terms of whichever container engine you use. It’s a useful arrangement for tinkering, testing an integration, or changing the platform itself. A laptop also sleeps, travels, and occasionally has to become a laptop again.
What changed on Cloudflare #
Cloudflare first made Containers available in public beta in June 2025. The fresh release is the September 30, 2026 redesign: runtime selection of images and machine sizes, a new scheduling policy, and filesystem snapshots in public beta. Mainbrella uses the native ctx.container API. Cloudflare’s Sandbox SDK is a related layer on this infrastructure; it isn’t a dependency of our backend.
The useful architectural detail is that a Linux container has a persistent controller outside it. Cloudflare calls that controller a Durable Object: application code with its own identity and storage. The Linux process can disappear while the controller keeps the information needed to manage its lifetime.
We add another coordinator for each customer account. Before a machine boots, that coordinator reserves its share of the account’s allowance. If the CSV agent starts five workers, they consume one shared budget. Stopping a worker doesn’t erase its customer’s usage history. This is the sort of detail that matters when someone else is paying the infrastructure bill.
The rest of the stack is similarly compact. Workers handle the API; D1, Cloudflare’s SQL database, holds account and billing data. The web client includes signup, checkout, subscription management, API keys, and the workspace dashboard. You get the code connecting these pieces, along with the containers.
For the CSV job, the filesystem is ordinary guest storage. Stopping the machine discards unsaved changes. Mainbrella can explicitly save a filesystem workspace and restore it into a new machine, using Cloudflare’s snapshots. It doesn’t resume the script’s RAM or running process. The script still needs to write useful progress to files.
There’s a trade here: the code is open, but this backend is built around Cloudflare APIs. Running it on another cloud would mean porting the infrastructure layer. Having the source gives you that option; it doesn’t make the port automatic.
You can sell the umbrella too #
Say you teach a programming course. You want each student to have a disposable Linux workspace, a browser terminal, and a link to the app they’re building. You also want a budget per student, because “the exercise took an hour” and “the machine ran all weekend” should have different consequences.
You could build those pieces, buy a hosted service, or fork Mainbrella and adapt it to the course. The fork can have your branding, your subscription prices, your Cloudflare account, and your customers. A classroom is one possible audience; the same invitation applies to an agent product or a service competing directly with ours.
The right to run it includes the right to run a business with it.
The GPL v3 license permits commercial use. Its copyleft requirements matter when you distribute covered software: a fork isn’t permission to redistribute it as a closed-source product. There is no Mainbrella software fee or revenue share for operating your own service.
There is, however, setup work. The checked-in configurations and deployment scripts contain our account, domains, and image-release locations. You’ll need to adapt those, configure your own authentication and Stripe billing, and apply the database migrations. The current release scripts assume an existing deployment of our service; a fresh fork needs its own bootstrap. Those assumptions are visible in the source, and an operator needs to understand them.
Even the prices have two parts: what you offer and what the server enforces. The web client has checkout prices; the backend policy sets concurrency, starts, compute allowance, and deadlines. Changing a number on the pricing page doesn’t change the machine budget. A fork’s operator gets to change both—and has to keep them consistent.
Free code, three different bills #
The choices are easier to compare when you follow the money and the work:
| Who runs the service? | ||
|---|---|---|
| Arrangement | What you pay for | Who operates it |
| --- | --- | --- |
| Local on your Mac | Your computer and container engine | You |
| Your Cloudflare account | Cloudflare usage and any other services you configure | You; your customers can pay you |
| mainbrella.com | A Mainbrella subscription within its plan allowances | We operate the sandbox service |
As of October 7, 2026, Cloudflare’s $5/month Workers Paid plan includes 375 vCPU-minutes, 25 GiB-hours of memory, and 200 GB-hours of disk. Those allowances are shared across the account. A small deployment might fit inside them; hundreds of busy machines won’t become free because the application is GPL. Additional usage and other services can add charges.
If you sell a fork, your customers pay you and you pay your infrastructure providers. Revenue has to cover compute, payment processing, support, and the time spent operating it. A subscription price is not a margin. Bounded sessions and account budgets help control that cost, but they don’t substitute for measuring your workload.
This is also why I think mainbrella.com can earn real income while the code remains free. A business that needs sandboxes for its own product may prefer to buy them rather than own our deployment work. With the hosted service, we handle the sandbox infrastructure, image rollout, billing integration, and platform maintenance; the customer still owns their agent’s code and results.
Self-hosting shifts those jobs to a person on your team. That can be a good decision when you want control or intend to build a business around the platform. It can be a poor use of time when your business is the CSV analysis app and the sandbox is one dependency among many. Being able to operate a service and wanting to operate it are separate things.
The subscription has to earn its place #
A hosted customer can inspect the same machinery they’re paying us to operate. If their needs change, they have source code and a path to running their own deployment. That path requires work, and it isn’t an automatic transfer of their account or saved workspaces. It is a more useful option than hoping a provider eventually adds the setting they need.
For the operator, the bargain is equally clear. We have to make the hosted service worth paying for while the alternative remains available. Someone may build a better service for a particular audience with our code. They’re welcome to try.
That’s the benefit of rain for an umbrella business: there’s work people need done. We can share the design and still charge for standing outside. The backend, web client, and self-hosting overview are open if you want to take a turn.