[KongchangAI]
· 2 min read· 1,250 words

Open-Source AI Phone Receptionist: Built on Cloudflare, Ready to Launch a Startup

Open-Source AI Phone Receptionist: Built on Cloudflare, Ready to Launch a Startup

Developer open-sources AI phone receptionist MainBrella on Cloudflare's full stack, validating serverless replication of core call center capabilities.

A developer shared on Reddit the open-source AI phone receptionist MainBrella, built on Cloudflare's full stack, to test how much of a call center service like Bland AI can be replicated with serverless capabilities. The answer: core parts are feasible—Deepgram Flux for ASR, Llama 3.3 70B via Workers AI for reasoning, Deepgram Aura-1 for TTS, Durable Objects for state, Twilio for telephony, and D1 for transcripts. It supports answering, service intros, callback collection, and transcript storage, but outbound calls, scheduling, warm transfer, and CRM sync need development. GPLv3 open-source, Cloudflare paid plans from $5/month, suited for MVP validation and small-business startups. The developer also poses two open questions: which industry to target first and what features to add before charging.

A developer shared on Reddit an open-source AI phone receptionist built entirely on Cloudflare's full-stack infrastructure, integrated into the open-source project MainBrella. The project attempts to answer a question: how much of an AI call center service like Bland AI can be replicated using Cloudflare's existing capabilities?

Reddit original post screenshot

The answer: the core parts can basically all be done.

Tech Stack: All Three Layers of Inference Run on Cloudflare

The technical architecture of this AI receptionist is quite compact, with each component using mature and low-cost options.

Speech recognition uses Deepgram Flux, responsible for converting the caller's speech to text. Conversation reasoning is handled by Llama 3.3 70B, called through Cloudflare Workers AI, processing intent understanding and generating responses. Speech synthesis uses Deepgram Aura-1 to turn text responses into natural speech.

Call state management is handled by Cloudflare Durable Objects, with each phone conversation having its own independent state instance to avoid concurrency conflicts. Twilio handles connection to the real telephone network, allowing the AI to answer actual calls. After the call ends, transcripts are stored in the Cloudflare D1 database.

The cleverness of this combination lies in the fact that it doesn't rely on any self-hosted GPU servers or complex orchestration systems. Workers AI provides inference capability, Durable Objects solves the stateful session problem, and D1 fills in persistent storage. The developer has pushed Cloudflare's serverless capabilities to the extreme.

Cloudflare Durable Objects is the key to understanding this architecture. It is a stateful serverless object with strong consistency — each instance has only one unique copy in Cloudflare's network, and all requests are routed to the same instance for processing. This solves the pain point of traditional serverless functions being "stateless": for a phone call lasting several minutes that needs to maintain context and may be interrupted or transferred at any time, state must persist stably across multiple events. Durable Objects allows each call to have an independent instance, ensuring session isolation while naturally avoiding concurrent write conflicts, and can also leverage its built-in storage and WebSocket capabilities for real-time bidirectional streaming. Compared to maintaining your own Redis + session lock solution, it abstracts distributed state management into a nearly local object.

Cloudflare Workers AI is the inference foundation of this solution. It charges by "neurons" or call volume, rather than requiring you to prepay for GPU hours, making it very suitable for low-traffic, long-tail voice reception scenarios. It provides a set of out-of-the-box open-source models (such as Llama 3.3 70B) that can be called through simple APIs, with relatively controllable latency at edge nodes. The trade-off is that model selection, fine-tuning, and context windows are limited by the platform, and cannot achieve deep optimization like self-hosted vLLM. For an MVP, this "good enough with nearly zero ops" trade-off is reasonable.

What It Can Do Now, and What It Can't

The implemented features cover the core scenarios of a phone receptionist: answering calls, introducing business services and hours, collecting callback information, and saving call transcripts. You can also configure the receptionist in the browser and test conversations before binding a phone number.

However, the developer himself admits this is not yet a complete replacement for Bland. Outbound calls, appointment scheduling, real-time transfer to human agents, CRM sync updates, and other features still need to be developed independently. Production-level performance also requires more testing and validation.

This candid disclosure is actually important. It delineates the project's true boundaries: suitable as an MVP validation and small-scale deployment, but still some engineering distance from an enterprise-level call center.

Outbound calls, appointment scheduling, and real-time warm transfer — the reason these three missing features are critical is that they each correspond to three core values of a call center. Outbound means proactive outreach, such as follow-ups, reminders, and confirmations, typically requiring compliance with telecommunications regulations in various countries (such as TCPA in the US), and engineering-wise involves call queues and retry strategies. Scheduling seems simple but actually requires bidirectional calendar sync, handling timezone conflicts, concurrent bookings and cancellations — a classic case of "business logic being heavier than AI." Real-time warm transfer has extremely high latency and reliability requirements, needing to query agent status while maintaining the call and passing context along — any lag directly harms user experience. Therefore, by listing these as "not yet implemented" rather than "planned," the developer is honestly signaling: the current version is better suited for handling asynchronous, non-urgent call logging rather than replacing a full call center.

Startup Possibilities Under an Open-Source Model

Both frontend and backend are open-sourced under GPLv3, meaning you can fork it, deploy your own version, or even build a business around it.

The developer's envisioned scenario is very specific: providing AI phone reception services for independent bike shops, plumbers, and small repair shops. These businesses typically don't have dedicated receptionists but do need someone who can answer common questions and record incoming call information. Rather than building infrastructure from scratch, it's better to spend energy finding customers and solving their specific pain points.

The cost structure is also worth noting. Cloudflare Workers paid plan starts at $5 per month, with AI inference, Twilio calls, and additional infrastructure billed by usage. Running your own copy doesn't require paying MainBrella any software licensing fees. For individual developers or small teams, the startup cost is pushed to a very low level.

A Few Questions Worth Thinking About

This project raises two open questions that have reference value for anyone wanting to do something similar.

The first is industry selection. Different industries have very different phone reception needs. Bike shops might care about inventory and repair scheduling, plumbers need emergency dispatch, and clinics involve appointments and insurance information. Which industry first embraces AI receptionists depends on that industry's dependence on phone calls and openness to new technology.

The second is the prerequisite for charging. Before charging customers, which features must be completed? If it can't even handle appointments, businesses may find it hard to pay for it. But if it only solves the basic problem of "never missing a call," the current version already has some value.

From a technical perspective, this project demonstrates a viable paradigm for serverless AI applications: composing a complete product using APIs rather than training and deploying models yourself. For those wanting to quickly validate AI voice application ideas, MainBrella provides a reference starting point.

One-line Summary

A developer open-sourced the AI phone receptionist MainBrella on Cloudflare's full stack, validating the feasibility of replicating core call center capabilities with serverless composition.

Paragraph Summary

A developer shared on Reddit the open-source AI phone receptionist MainBrella, built on Cloudflare's full stack, attempting to verify how much of a call center service like Bland AI can be replicated with existing serverless capabilities. The answer: the core parts are basically feasible. Speech recognition uses Deepgram Flux, conversation reasoning uses Llama 3.3 70B (via Workers AI), speech synthesis uses Deepgram Aura-1, state management uses Durable Objects, phone access uses Twilio, and transcripts are stored in D1. Currently it supports answering calls, service introductions, callback information collection, and transcript storage, but outbound calls, scheduling, real-time transfer, and CRM sync still need to be built. The project is GPLv3 open-source front and back end, with Cloudflare paid plans starting at $5 per month, suitable for individuals or small teams doing MVP validation and entrepreneurship targeting independent small businesses. The developer also raises two open questions: which industry to enter first, and which features must be completed before charging.

#open-source AI receptionist#Cloudflare Workers AI#AI phone call center#MainBrella#serverless AI#Deepgram#Twilio#AI voice assistant#startup MVP
Share:

Related articles