cloudflare-ai-web: a self-hosted chat front end for Workers AI and AI Gateway

The gap between a Workers AI binding and something a person can type into

Workers AI gives you inference behind an account ID and a token. What it does not give you is a page. Anyone who wants to try a model has to write request code, handle streaming, and render output, which is a few hours of work before the first token appears. cloudflare-ai-web fills exactly that gap: a Next.js and shadcn-ui front end, distributed as a Docker image and as a Vercel one-click deploy, that talks to Workers AI on your behalf. The intended user is a developer or small team with a Cloudflare account who wants a private chat endpoint for Workers AI models and possibly for Google models routed through AI Gateway. It is not aimed at end users who want a managed product. The README is explicit about the public instance at ai.jaze.top: quota exhaustion may make it unresponsive, and it says to deploy your own. That sentence sets the expectation for the whole project. You are not signing up for a service. You are standing up an instance.

What actually sits between the browser and the model

The repository is TypeScript with Next.js, and the deployment targets are serverless: Cloudflare and Vercel both appear in the README as supported hosts. The credentials live in server-side environment variables, CF_ACCOUNT_ID and CF_WORKERS_AI_TOKEN, and the Docker example passes them with -e flags, which means the browser never sees the Workers AI token. The AI Gateway path is the interesting part of the architecture. When CF_AI_GATEWAY_NAME is set, requests are routed through a named gateway rather than straight to the model endpoint, and CF_AI_GATEWAY_TOKEN authorizes that hop. Google models are reached through the gateway rather than through a direct Google integration on the server, which is why GOOGLE_API_KEY is listed as required only when using Google, and why the provider list is exposed to the client as NEXT_PUBLIC_CF_AI_GATEWAY_PROVIDERS. That NEXT_PUBLIC_ prefix is deliberate: the front end needs to know which providers to offer, so the provider names are compiled into the client bundle. The README lists exactly one supported provider value, google, with multiple providers separated by commas. Chat history does not leave the browser; the README states it is stored locally. So the data flow is: credentials on the server, provider list in the client, conversation text in local storage, and model traffic through Cloudflare.

The environment variables are the whole configuration surface

There is no config file and no admin panel. Everything is set through environment variables, and the README provides a table of seven. Four are conditional: CF_AI_GATEWAY_NAME, CF_AI_GATEWAY_TOKEN, GOOGLE_API_KEY, and NEXT_PUBLIC_CF_AI_GATEWAY_PROVIDERS. Two are mandatory: CF_ACCOUNT_ID and CF_WORKERS_AI_TOKEN. One, APP_PASSWORD, is optional in the table but is the difference between a private instance and an open proxy. The Docker invocation is a single command, with the account ID, the token, and a port mapping to 3000, plus --restart=always. The README's guidance for the token is specific: create it under Manage Account, Account API Tokens, Create Token, using the Workers AI template. That detail matters more than it looks. A token created from a different template may carry permissions the application does not need. For the gateway provider list, the README gives the format directly: provider names separated by commas, with google as the only documented value. If you set CF_AI_GATEWAY_NAME but forget the gateway token, the README marks CF_AI_GATEWAY_TOKEN as required when using the gateway, so the failure will be at request time rather than at startup.

Public mode is an open inference endpoint with your bill attached

The README carries a warning that deserves to be read twice: in public mode, anyone can use your inference API, and it recommends setting APP_PASSWORD to enable Access Session. This is the sharpest limitation in the project. Without APP_PASSWORD, the deployment is a shared password-less chat endpoint funded by your Cloudflare account, and the only ceiling is whatever quota and spending limits your account carries. The application does not appear, from the supplied material, to implement per-user accounts, rate limiting, or usage attribution. Access Session is a single shared password, not a user system. That has two consequences. First, you cannot tell who consumed what. Second, rotating the password rotates it for everyone at once. A second limitation is the hosting model itself. The README's own note about the demo instance explains that when quota runs out it may stop responding. On your own deployment that is your quota, but the failure mode is the same: a hard stop with no fallback model and no queue. If you need availability guarantees, a serverless front end over a metered inference API is the wrong shape.

Where it sits next to LibreChat and Open WebUI

The obvious comparison class is self-hosted multi-model chat UIs such as LibreChat and Open WebUI. The difference is not the interface, which is broadly similar in all three. It is where inference happens and what the application assumes about it. LibreChat and Open WebUI are provider-agnostic: you point them at OpenAI, Anthropic, a local Ollama server, or any OpenAI-compatible endpoint, and the deployment is a long-running container with a database behind it. cloudflare-ai-web is the inverse. Its primary backend is Workers AI, a specific Cloudflare product, and its secondary path is AI Gateway, also Cloudflare. The provider list in the README contains exactly one entry, google, and it is reachable only through the gateway. That narrowness is the point: it is why deployment is a single Docker command or a Vercel button rather than a compose stack with volumes and migrations. If your models live in Workers AI, the narrow version is less work. If your models live anywhere else, you are adapting the wrong tool, and a provider-agnostic client would have been the shorter path.

Version cadence, licence, and what an upgrade costs you

The release history shows v4.5.0 in December 2025, v4.7.0 in April 2026, and v5.0.0 in September 2026. The jump from 4.7 to 5.0 is the one to plan around: a major version bump in a Next.js application commonly carries framework or dependency changes, and the README does not document a migration procedure or a changelog in the supplied material. Upgrading therefore means reading the release notes for v5.0.0 yourself before pulling a new image. The practical upgrade cost is low in one respect and awkward in another. Low, because configuration is environment variables rather than a config file or a database schema, so a container swap carries the same seven variables forward. Awkward, because chat history lives in the browser's local storage, which means a front-end change that alters the stored format can strand existing conversations with no server-side migration path to run. The project is Apache-2.0, which permits commercial use and modification and requires that the licence and notices be preserved and that modified files be marked. This is a factual description of the licence text, not legal advice; if you plan to redistribute a modified build, have someone qualified read the terms. Note also that the README contains sponsor content, including a discount code for an unrelated subscription service. That is a funding arrangement, not a technical dependency, but it tells you the project is maintained by an individual rather than a company with a support contract.

Editorial conclusion

Adopt cloudflare-ai-web if you already hold a Cloudflare account with Workers AI enabled and want a browser chat surface for those models without writing the front end yourself. Do not adopt it if you need per-user accounts, shared conversation history, or a hosted service that stays available when someone else's quota runs out. Before deploying, confirm three things: that your CF_WORKERS_AI_TOKEN was created from the Workers AI template rather than a broader account token, that APP_PASSWORD is set, and whether you intend to route through AI Gateway, because that decision adds CF_AI_GATEWAY_NAME, CF_AI_GATEWAY_TOKEN and NEXT_PUBLIC_CF_AI_GATEWAY_PROVIDERS to the configuration.

Official sources

1. Jazee6/cloudflare-ai-web on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases