{"slug": "we-built-elektric-on-cloudflare-workers", "title": "We Built Elektric on Cloudflare Workers", "summary": "Elektric runs most of its server-side application logic on a Cloudflare Worker named `elektric-api`, which handles the full AI request lifecycle — authentication, classification, routing policy selection, provider capacity, model calls to OpenAI, Anthropic and Google, response normalization and telemetry — alongside the company's website, documentation and frontend via Workers Static Assets. Elektric also uses Cloudflare Workers AI internally, where a Qwen model classifies incoming requests by category and difficulty to drive routing decisions without answering the customer's prompt, and Workers AI supports Knowledge retrieval query rewriting and document conversion. Provider traffic generally flows through Cloudflare AI Gateway, while Elektric retains its own model routing logic.", "body_md": "When we started building Elektric, we knew the hard part would not simply be calling an AI model.\n\nElektric sits between an application and a constantly changing ecosystem of models and providers. A single request can involve authentication, classification, routing, context, provider selection, fallback, streaming, usage tracking, billing, and telemetry before the answer ever reaches the developer.\n\nWe wanted an infrastructure stack that could support all of those pieces without turning Elektric into a collection of loosely connected services that we would have to operate independently.\n\nThat led us to Cloudflare.\n\nToday, most of Elektric’s server-side application logic runs through a Cloudflare Worker. Around it, we use Cloudflare services for relational data, object storage, AI classification, provider transport, Knowledge retrieval, stateful coordination, asynchronous jobs, browser tools, email, and scheduled maintenance.\n\nCloudflare does not provide Elektric’s model routing or decide which model should answer a request. That logic is ours. What Cloudflare gives us is a set of infrastructure primitives that let us build those systems within one coherent platform.\n\n## Workers sit at the center\n\nThe main Elektric service is a Cloudflare Worker called `elektric-api`.\n\nIt handles both our public API and application endpoints. The same deployment also serves the Elektric website, documentation, blog, and application frontend through Workers Static Assets. A separate Worker handles the `www` redirect.\n\nMore importantly, Workers is where the core AI request lifecycle comes together.\n\nWhen an ordinary chat request reaches Elektric, the Worker can authenticate the project, validate the request, apply project limits, classify the work, select a routing policy, prepare Context, check model compatibility, consult health and billing information, acquire provider capacity, call the selected model, normalize the response, and record the result.\n\nThat is a lot of responsibility for one request path, but it is also exactly why the architecture works well for us. Instead of deploying a separate routing service, authentication service, context service, streaming gateway, provider proxy, and telemetry service, the orchestration can live inside one application runtime.\n\nThe answering model still runs at OpenAI, Anthropic, or Google. Other systems such as Stripe and Google OAuth remain external as well. Cloudflare does not somehow make the entire outside world disappear. But most of the logic that turns an application request into an AI request lives together inside Elektric’s Worker.\n\n## We use AI inside the infrastructure itself\n\nOne of the more interesting parts of the architecture is that models are not only used to produce the final answer.\n\nElektric also uses Cloudflare Workers AI internally.\n\nFor ordinary text routing, a Qwen model running through Workers AI helps classify a request by category and difficulty. A separate classification determines whether private Knowledge may be relevant. The classifier returns structured metadata to Elektric; it does not answer the customer’s prompt.\n\nThat distinction is important.\n\nSuppose a developer sends:\n\n“Help me diagnose a concurrency bug in this payment service.”\n\nThe internal model may classify that as hard coding work. Elektric then uses that classification to determine which part of its routing policy applies.\n\nThe model performing the classification and the model eventually answering the request are two different layers.\n\nWe also use Workers AI in parts of Knowledge retrieval, including rewriting retrieval queries, and for document conversion in supported paths. This means AI itself becomes an infrastructure primitive inside Elektric, not merely the destination at the end of the request.\n\n## AI Gateway connects us to the model providers\n\nOnce Elektric selects an answering model, provider traffic generally goes through Cloudflare AI Gateway.\n\nOur OpenAI, Anthropic, and Google adapters each translate Elektric’s internal request format into the provider-specific format required upstream. Their responses are then normalized back into one interface for the application.\n\nAI Gateway gives us a common transport layer for those provider calls, including authentication and correlation metadata.\n\nBut the distinction between AI Gateway and Elektric is important: **Cloudflare transports the request. Elektric decides where it should go.**\n\nThe classification system, candidate pools, model eligibility rules, health checks, and fallback decisions are implemented by Elektric. We are not delegating our routing policy to AI Gateway.\n\nThat separation is useful because provider transport and model selection are different problems.\n\nGateway gives us one place through which we can communicate with several model providers. Elektric then builds its own decision layer on top.\n\n## Different data belongs in different places\n\nAI infrastructure produces many different kinds of data, and forcing all of it into one storage system would make very little sense.\n\nElektric primarily uses D1 for structured application and operational state.\n\nOur application database stores things like accounts, projects, API keys, billing information, Conversation, Memory, Knowledge metadata, files, jobs, and other application records. Separate D1 databases are used for telemetry and an independent deletion ledger. A Model Lab database is also configured separately.\n\nTelemetry is particularly important for routing.\n\nElektric records requests and individual provider attempts separately. That means one customer request can be connected to its selected model, actual execution model, fallback behavior, latency, token usage, cost calculations, and failure information.\n\nThat request-to-attempt relationship matters because one Elektric request can involve more than one provider attempt.\n\nR2 handles a different kind of data.\n\nWe use R2 for file bodies and other object-like data, including temporary uploads, generated assets, asynchronous job payloads, blog images, and benchmark evidence. Our Model Lab artifacts can also be preserved there, including corpora, candidate answers, judging results, and reports.\n\nThe distinction is simple: D1 is useful for structured state we need to query and relate. R2 is useful for larger durable objects.\n\nWe do not currently use Workers KV in the application.\n\n## Knowledge is its own infrastructure system\n\nWhen a project enables Knowledge, the architecture expands again.\n\nElektric stores document and upload metadata in D1 and sends the material into Cloudflare AI Search for managed ingestion and retrieval. When the application needs relevant Knowledge, Elektric can rewrite the query using Workers AI, search the scoped Knowledge index, select the relevant chunks, and add that information to the model’s context before execution.\n\nWe deliberately keep Conversation, Memory, and Knowledge separate.\n\nConversation provides recent thread history.\n\nMemory provides durable information about a user.\n\nKnowledge retrieves relevant information from organizational or project material.\n\nThose systems can all contribute to the context given to the answering model, but they represent different kinds of information and have different persistence and retrieval behavior.\n\nThat separation matters because the model underneath the application can change while the application’s context remains stable.\n\n## Durable Objects handle the state that should not be stateless\n\nWorkers are a natural fit for request handling, but some infrastructure problems require coordination across requests.\n\nThat is where we use Durable Objects.\n\nElektric currently uses them for three distinct jobs: per-project admission and limits, provider-capacity coordination, and realtime sessions.\n\nProvider capacity is a good example.\n\nBefore executing a model request, Elektric can coordinate capacity for the relevant provider and model family. Repeated failures can affect the state maintained by that coordination layer, while successful execution can clear previous failure state.\n\nThis works alongside, rather than replacing, our D1-based health system.\n\nD1 gives us historical operational evidence. Durable Objects give us a place for coordinated state around active requests.\n\n## Streaming changes the architecture\n\nAI responses are not ordinary HTTP responses.\n\nDevelopers expect streaming, and different model providers represent streaming events differently.\n\nElektric’s provider adapters normalize those different streams into a common internal event format before the Worker exposes them through the public API.\n\nStreaming also changes what fallback can do.\n\nIf the initial execution fails early enough, Elektric can attempt an eligible fallback. Once the prepared response stream has been committed, however, Elektric does not switch models in the middle of an answer.\n\nThat sounds like a small implementation detail. In practice, it is one of many examples of why AI infrastructure needs logic above a simple provider proxy.\n\n## Cloudflare also handles the less glamorous parts\n\nAI infrastructure is mostly discussed in terms of models, but production applications contain a large amount of work that has nothing glamorous about it.\n\nElektric uses Cloudflare Workflows for asynchronous provider jobs such as video operations. Cron Triggers run maintenance every five minutes, including cleanup, job recovery, billing reconciliation, notifications, and monitoring. Browser Run supports rendered-page retrieval for research tools. Cloudflare’s Email Service handles authentication emails, blog subscriptions, and notifications.\n\nThis matters more than it sounds.\n\nThe attraction of the platform is not any single one of these products. It is that we can compose them around the same Worker application without creating a new infrastructure stack for every feature we add.\n\n## The economics make experimentation easy\n\nThere was another practical reason Cloudflare worked well for us: it is remarkably inexpensive to start building on.\n\nEarly in a product’s life, infrastructure usage is unpredictable. You are constantly adding things, testing ideas, throwing some of them away, and discovering that the innocent-looking feature you built on Tuesday now needs a database, object storage, background jobs, scheduled work, and an AI model by Friday. We wanted to be able to experiment without every new primitive immediately creating another meaningful fixed cost.\n\nCloudflare’s pricing model makes that unusually easy. Workers can be used on the Free plan with up to 100,000 requests per day, while the Workers Paid plan starts at $5 per month. The paid plan also includes initial usage across Workers and several related platform services, and Cloudflare does not add separate data-transfer or bandwidth charges to Workers.\n\nThe same pattern extends to much of the stack we use. D1’s Free plan includes 5 million rows read and 100,000 rows written per day, along with 5 GB of storage. On the paid Workers plan, the included monthly allocation rises to 25 billion rows read and 50 million rows written before usage charges begin. D1 also scales to zero, so there is no database compute capacity sitting around generating a bill when nothing is querying it.\n\nR2 gives us another example. The free tier includes 10 GB-month of storage, one million Class A operations, and 10 million Class B operations each month. Standard storage beyond that is currently $0.015 per GB-month, and R2 does not charge for data transferred out to the Internet.\n\nThat last part is particularly attractive for infrastructure that moves files and generated assets around. Object storage on other large cloud platforms can include separate data-transfer charges. Amazon S3, for example, currently gives customers the first 100 GB per month of Internet data transfer out across AWS services for free and then charges for additional outbound transfer depending on the region and usage. R2’s pricing simply lists Internet egress as free.\n\nThe AI pieces are similarly approachable. AI Gateway’s core features are currently free, including its core analytics, caching, and rate-limiting capabilities. Workers AI includes 10,000 Neurons of inference per day at no charge on both Free and Paid Workers plans, with usage beyond that on the paid plan billed according to model consumption.\n\nWhat stood out to us was the economics of the whole system.\n\nWe could start with a Worker, add relational storage with D1, object storage with R2, internal inference with Workers AI, provider transport through AI Gateway, then layer on Durable Objects, Workflows, scheduled jobs, and other primitives as the product became more sophisticated. Many of those services either have meaningful included usage or only begin charging materially as the application starts using them.\n\nThat matters for a company like Elektric because experimentation is part of building the infrastructure. We can try a new internal classifier, add another telemetry table, preserve benchmark evidence in R2, introduce a background workflow, or build a new context capability without first deciding whether the experiment deserves its own server, database cluster, networking layer, or monthly infrastructure commitment.\n\nAs the system grows, usage obviously stops being free. But the cost curve starts close to zero and rises with the product rather than forcing us to provision a large infrastructure footprint in advance.\n\nFor us, that has been one of Cloudflare’s less glamorous but most useful properties: **it is cheap to try things.**\n\nAnd when you are still figuring out what the right AI infrastructure should look like, being able to try a lot of things is worth quite a bit.\n\n## The Model Lab uses the same foundation\n\nThe routing system only becomes useful if we have evidence about the models underneath it.\n\nThat is the purpose of Elektric’s Model Lab.\n\nOur evaluation system can run candidate models through the same provider adapter infrastructure, collect responses and costs, judge results using task-specific benchmarks, and preserve evaluation evidence. Some benchmark artifacts are stored in R2, while Model Lab also has D1 persistence implemented for structured evaluation data.\n\nThe important architectural separation is that evaluation does not automatically change production routing.\n\nBenchmarks provide evidence.\n\nElektric decides how that evidence should change routing policy.\n\nThat gives us the ability to compare new models against the models already being used underneath an application and update the policy when the tradeoff improves.\n\n## Cloudflare does not build Elektric for us\n\nThis is probably the most important distinction in the architecture.\n\nCloudflare provides many of the primitives, but it does not provide the system Elektric is building.\n\nCloudflare does not define our six routing categories. It does not decide whether a request is easy or hard. It does not maintain our routing tables. It does not define which models belong in which pools. It does not normalize every provider into our public interface. It does not decide when a fallback should happen. It does not design our benchmarks or determine how Context should be assembled.\n\nThose systems are Elektric.\n\nCloudflare gives us compute, storage, model infrastructure, provider transport, stateful coordination, background execution, and other building blocks.\n\nThat is the relationship we wanted.\n\nWe did not want an AI platform that made every architectural decision for us. We wanted infrastructure that gave us strong primitives while leaving us free to build the intelligence layer ourselves.\n\n## Why the architecture fits Elektric\n\nElektric’s job is ultimately one of coordination.\n\nA request arrives from an application. We need to understand it, decide which model should handle it, assemble the right context, communicate with different providers, recover from failures when possible, normalize the answer, account for what happened, and keep the developer-facing interface stable while everything underneath continues to change.\n\nCloudflare gives us a platform where many of those pieces can live together.\n\nWorkers gives us the main execution environment. Workers AI gives us models we can use inside the infrastructure itself. AI Gateway gives us a common provider transport. D1 gives us structured application and operational state. R2 gives us object storage. AI Search supports Knowledge. Durable Objects give us coordinated state where we need it. Workflows and Cron handle work that should not live inside the synchronous request.\n\nNone of those products alone is the reason we built Elektric on Cloudflare.\n\nThe reason is how they fit together.\n\nWe can keep the application interface simple while building a fairly sophisticated system underneath it, and we can add new infrastructure capabilities without having to create an entirely new operational stack every time.\n\nFor a company whose goal is to hide the complexity of AI infrastructure from developers, that is a useful property for our own infrastructure to have.", "url": "https://wpnews.pro/news/we-built-elektric-on-cloudflare-workers", "canonical_source": "https://elektric.ai/blog/why-we-built-elektric-on-cloudflare", "published_at": "2026-10-23 18:14:09+00:00", "updated_at": "2026-10-23 18:43:22.512069+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-agents", "ai-tools", "large-language-models", "mlops"], "entities": ["Elektric", "Cloudflare", "Cloudflare Workers", "Cloudflare Workers AI", "Cloudflare AI Gateway", "Qwen", "OpenAI", "Anthropic"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/we-built-elektric-on-cloudflare-workers", "markdown": "https://wpnews.pro/news/we-built-elektric-on-cloudflare-workers.md", "text": "https://wpnews.pro/news/we-built-elektric-on-cloudflare-workers.txt", "jsonld": "https://wpnews.pro/news/we-built-elektric-on-cloudflare-workers.jsonld"}}