Many businesses in a box under this brella

October 15, 2026 · Andrew Arrow

Put an AI receptionist on a bike shop's phone number, and it needs more than a voice. It needs the repair price list, Saturday's opening hours, and a way to pick up changes next week. A small web app for the owner would be handy too. Each requirement could become another vendor signup. I'd like to make it one MainBrella project.

We already have three of the businesses behind that project in our code: Linux computers for agents, a conversational app builder, and voice calls. We're planning three more: web scraping, background jobs, and a vector database with managed knowledge bases. The reason this seems manageable is how much they can share.

Those company names describe the customer problem we're taking on. Matching every feature, integration, and operating guarantee would be a much larger undertaking. For the shop, a useful receptionist with its own repair information is a reasonable first job.

The three businesses already in the box

Agent Linux boxes give code somewhere to run. MainBrella's execution API starts commands, retains output, and lets a client reconnect to a stream. Around that are file access, terminals, previews, custom images, and saved workspaces, running on Cloudflare Containers. This is the E2B category: an agent can install a package, run a test, and inspect the result in a Linux environment. Saved workspaces preserve files; restoring one starts fresh processes.

Vibe coding puts an application around that computer. Describe a frontend in Builder, and an agent writes files, installs dependencies, checks the build, and starts a preview. It saves source and Git history so the next edit can continue from earlier work. The build agent uses Workers AI for inference and Workflows to coordinate the work. Lovable is the familiar comparison; our current scope is a frontend builder with saved revisions and previews.

Voice calls add a different way to use an agent. The October 15 changes include a receptionist, browser and text tests, inbound Twilio calls, transcripts, and metered usage. Workers AI handles speech recognition, the language model, and speech generation; a Durable Object holds each call's conversation. Twilio supplies the phone connection. The voice article covers the implementation and its limits: reception and callback intake are implemented, while booking, transfers, and outbound calls still need integrations.

For the bike shop, today's receptionist gets its facts from saved instructions. These are the actual Voice settings with sample shop details. Teaching it to retrieve those facts from an uploaded price list or the shop's website is one of the next useful additions.

Adding a service without adding another wallet

The voice billing code has a small detail I like. Its first two imports are from prepaid billing and Builder's pricing module:

import { accountBillingRequest } from './prepaid-billing';
import {
  buildInferenceChargeMicroUsd,
  buildTokenCostMicroUsd,
  readBuildTokenUsage,
} from './build-pricing';

The names still say build, but Voice uses the same pricing helpers and account billing service. Before paid inference, it reserves money in the owner's wallet. When usage is reported, it settles the charge. Voice needs its own meters for audio, characters, tokens, and phone minutes; the customer doesn't need another balance.

Accounts, authentication, API keys, prepaid funding, ownership checks, storage accounting, and the browser control panel are already here. Workers run the APIs, D1 keeps application records, R2 holds larger artifacts, and Durable Objects coordinate account and runtime state. The application infrastructure lives in our Cloudflare account. Stripe handles payments, and Twilio handles telephone service.

Hosted funding starts at $5 with no monthly subscription. New services would get their own usage meters and draw from that balance. A crawl, a query, and a minute of compute cost different amounts, so each needs a price the customer can understand. The account wallet is shared today; one developer API key across every capability is still API work ahead. Builder and Voice currently use browser sessions.

Scraping websites: Firecrawl

A developer building a research agent wants a URL turned into usable information. Firecrawl sells that job as an API: websites become Markdown or structured data. For our shop, the first use would be reading the repairs and opening-hours pages without making the owner paste them into a prompt.

Cloudflare's Browser Run crawl endpoint already follows links and returns HTML, Markdown, or JSON. Its JSON extraction endpoint can work from a supplied schema. We'd add account-owned crawl jobs in D1, retained results in R2, and Queues or Workflows for processing and scheduled refreshes. MainBrella would handle job status, result retrieval, limits, and metering.

Getting a browser response is only part of what we'd sell. Customers need to know which pages succeeded, which changed, and which failed. A crawl that silently turns a blocked page into an empty document makes a lousy knowledge source. Browser Run respects robots.txt and doesn't bypass CAPTCHA or other bot protections, so difficult sites would remain outside the first product's promise.

I'd build this first. Public documentation and customer-owned sites give us a useful starting workload, and both Builder and Linux agents could use the results. Reliable extraction, saved results, and an honest failure report would make a worthwhile beta.

Vector search and knowledge bases: Pinecone

Reading the shop's website once won't help much if every call has to read it all again. The next service would store the information and retrieve the relevant passages when someone asks a question. A question about fixing a puncture should find the repair policy even if the document calls it a “flat tire.” Vector search uses numerical representations of text to find that kind of similarity.

Pinecone offers a managed vector database. On Cloudflare, Vectorize supplies vector storage and queries, and Workers AI can generate embeddings. We could expose insert, query, filter, and delete operations for developers who want to manage their own retrieval pipeline. For the bike shop, I'd start higher up: upload documents, wait for indexing, and search a knowledge base.

AI Search provides ingestion, indexing, and retrieval, including hybrid search that combines semantic and keyword matching. Cloudflare documents creating a separate instance for each tenant, including R2-backed instances scoped to the tenant's files. MainBrella would choose the instance from the authenticated account and check ownership before searching. A request's knowledge-base name can't be allowed to choose somebody else's documents.

The product work includes showing when an upload becomes searchable, keeping sources attached to answers, and making updates and deletion work. We'd need to test retrieval against the questions customers ask; having a vector index doesn't establish answer quality or Pinecone feature parity. I'd ship managed knowledge bases second because they would immediately give Voice, Builder-created apps, and hosted agents the same source of business facts.

Let the services share their work

With those additions, the shop could crawl its website into a knowledge base and use it from the receptionist and the owner's app. A Linux agent could run custom processing against the same material. The diagram also includes a background job to keep the information fresh. It shows a planned composition; today's Voice system still reads the instructions the owner saves.

The customer should be able to use any of these independently. Someone who only needs a scrape API shouldn't have to build an app first. But when they do need several services, they should be able to reuse a document, identify its owner, and see its charges in one place. That is where a shared account becomes more useful than six separate subscriptions.

Background jobs: Trigger.dev

The shop changes its Saturday hours. Somebody now has to fetch the page again, update the knowledge base, and report a failure if either step breaks. That's the job behind Trigger.dev: background work with retries, scheduling, queues, and progress you can inspect after closing your laptop.

MainBrella already configures a BuildWorkflow binding and has a container execution API. A general jobs product would use Workflows to coordinate steps, Containers to run customer JavaScript or Python, Queues and Durable Objects to manage admission, Cron Triggers to drive schedules, and R2 to retain outputs. Workflows also supports waiting for an event, which could let an agent pause for an owner's approval.

This is the largest engineering job of the three. Durable Workflow steps don't make the memory of an arbitrary Python process survive a container restart. We'd need saved checkpoints, versioned job definitions, and rules for retrying side effects. If a job sends a customer message and crashes before recording success, rerunning the command can send it twice. The application needs a receipt it can check.

There are deployment constraints too. Workflows currently can't live inside Workers for Platforms namespaces, so I'd keep orchestration in MainBrella's shared Worker and run customer code in isolated runtimes. Our checked-in egress-policy and secrets-vault flags are disabled. General customer jobs need properly qualified secret handling, network controls, and isolation before launch.

I'd build this third, while using narrower workflows internally for the first two services. Running a command is already possible. Selling a job that finishes reliably requires the recovery behavior to be part of the product.

You can run the business too

The web client and backend are GPLv3. You can inspect them, modify them, run them in your own Cloudflare account, and sell a service around them, following the license's requirements when distributing covered software. You pay your infrastructure bill; we don't charge a software fee for running a fork. You're welcome to compete with MainBrella.

A fork could concentrate on one audience: agent computers for a programming course, a receptionist for repair shops, or, once built, a scraper for a particular kind of public document. It gets the account and billing code along with the product. Setup still means provisioning your resources, replacing our domains and bindings, configuring authentication and payments, and applying migrations. The deployment runbook is a starting point; the repository doesn't automatically launch a company from an empty account.

A commercial deployment also needs the appropriate infrastructure agreement. Cloudflare offers products for multi-tenant platforms, while its self-serve terms restrict selling third parties access to its services without written permission. We'd confirm the terms for each offering. Adding value in our application doesn't by itself settle that contractual question. These company comparisons guide our own implementations; reusing another project's code would bring its own license requirements.

Six is a starting list. If a business can run on Cloudflare's infrastructure, I want MainBrella to help someone build and operate it with accounts, access controls, metering, and a customer interface already available to adapt. The runtime still has to fit the workload, and new products still take engineering.

I want the bike shop's developer to spend their time on the shop's software. They can pay us to operate the shared services, or take the source and run their own. Keeping both routes useful is the business I want to build: each new capability should give our customers more they can do, and give the next person starting a company less they have to build again.