Jazee6/cloudflare-ai-web: a self-hosted multi-model chat front end for Cloudflare Workers AI

What cloudflare-ai-web actually is

This is a chat front end, not an inference engine. The models run on Cloudflare's infrastructure through Workers AI; the project supplies the interface, the streaming plumbing and the deployment packaging. According to the README, its stated purpose is to use Cloudflare Workers AI to quickly stand up a multi-model AI platform, with optional access through Cloudflare AI Gateway for models such as Gemini.

The audience is narrow and specific: people who already have a Cloudflare account and a Workers AI token, and who would rather run their own chat page than use a hosted playground. The repository is TypeScript, licensed Apache-2.0, and the homepage ai.jaze.top is described in the README as an example deployment, with a note that it may stop responding when the quota runs out and that self-deployment is suggested. That note is the honest summary of the project's positioning: the public instance is a demo, and the intended path is your own deployment.

How the pieces fit: Next.js, Workers AI and AI Gateway

The dependency list in package.json shows the mechanism. The AI SDK v7 packages (ai, @ai-sdk/react) handle streaming and the React hooks, while two provider packages sit underneath: workers-ai-provider for Workers AI and ai-gateway-provider for AI Gateway. A third, @ai-sdk/google, appears alongside GOOGLE_API_KEY in the environment table, which matches the README's statement that AI Gateway can be used to reach models like Gemini.

Data flow is straightforward. The browser talks to the Next.js app, the app calls the selected provider with credentials from server-side environment variables, and the response streams back into the chat UI. Conversations are not stored on a server: the README lists chat history as local storage, and dexie plus dexie-react-hooks in dependencies point to IndexedDB as the store. That choice removes a database from the deployment, but it also means history is tied to one browser profile on one device.

Access control is a single optional password. The environment table names APP_PASSWORD as the access password for an Access Session, and the README warns directly that in public mode anyone can use your inference API. There is no user table, no per-user quota and no role model. If you need those, this is the wrong layer.

Deploying with Docker and making the first request

The README gives a Docker command as the primary self-hosting route. It maps port 3000, restarts the container automatically, and takes the two required variables. Replace the placeholder values with your own Cloudflare account ID and a Workers AI token; the README says the token should be created from the Workers AI template under account API tokens.

docker run -d --name cloudflare-ai-web \
  -e CF_ACCOUNT_ID=YOUR_CF_ACCOUNT_ID \
  -e CF_WORKERS_AI_TOKEN=YOUR_CF_WORKERS_AI_TOKEN \
  -p 3000:3000 \
  --restart=always \
  jazee6/cloudflare-ai-web

After the container starts, open http://localhost:3000. If a model replies, credentials are wired correctly. If requests fail while the container is healthy, the token or the account ID is the first thing to check, since those are the only two required variables.

To add an access password, add APP_PASSWORD to the same command. The README's warning about public mode is the reason to do this on any host reachable from the internet.

docker run -d --name cloudflare-ai-web \
  -e CF_ACCOUNT_ID=YOUR_CF_ACCOUNT_ID \
  -e CF_WORKERS_AI_TOKEN=YOUR_CF_WORKERS_AI_TOKEN \
  -e APP_PASSWORD=YOUR_PASSWORD \
  -p 3000:3000 \
  --restart=always \
  jazee6/cloudflare-ai-web

Routing through AI Gateway means adding the gateway name, its token, and the provider list. The README states that supported providers currently include google, and that multiple providers are separated by commas.

docker run -d --name cloudflare-ai-web \
  -e CF_ACCOUNT_ID=YOUR_CF_ACCOUNT_ID \
  -e CF_WORKERS_AI_TOKEN=YOUR_CF_WORKERS_AI_TOKEN \
  -e CF_AI_GATEWAY_NAME=YOUR_GATEWAY_NAME \
  -e CF_AI_GATEWAY_TOKEN=YOUR_GATEWAY_TOKEN \
  -e NEXT_PUBLIC_CF_AI_GATEWAY_PROVIDERS=google \
  -e GOOGLE_API_KEY=YOUR_GOOGLE_API_KEY \
  -p 3000:3000 \
  --restart=always \
  jazee6/cloudflare-ai-web

The README also offers a Deploy with Vercel button, which clones the repository and prompts for the same variables during setup. Building from source is possible: the Dockerfile installs bun 1.4.1, runs bun install --frozen-lockfile, then npm run build, and the final image runs the standalone Next.js server on port 3000 as a non-root user. The package.json engines field requires Node 22 or newer.

Where the design runs out: history, secrets and the provider list

Three constraints deserve attention before you commit.

First, chat history lives in the browser. The README lists local storage as the storage model, and the Dexie dependencies confirm IndexedDB. Clearing site data, switching browsers or moving to another machine loses the conversation list. There is no export path documented in the README, and no server-side copy to fall back on. For a personal tool this is fine; for a shared team instance it is a real limitation, because two people using the same deployment do not see each other's threads.

Second, model selection is bounded by what the provider layer exposes. Workers AI models come through workers-ai-provider, and AI Gateway models come through ai-gateway-provider with NEXT_PUBLIC_CF_AI_GATEWAY_PROVIDERS. The README lists exactly one supported gateway provider, google, and states that multiple providers are comma-separated. Anyone expecting a broad catalog should read that list as it stands rather than as it might grow.

Third, the secrets model is flat. CF_WORKERS_AI_TOKEN, CF_AI_GATEWAY_TOKEN, GOOGLE_API_KEY and APP_PASSWORD are all server-side environment variables with no rotation mechanism described. A leaked Workers AI token is a leaked inference budget on your Cloudflare account. The README's own warning about public mode is the only access-control guidance it gives.

Compared with running Open WebUI against your own endpoint

The closest alternative for the same job is Open WebUI, a self-hosted chat interface that connects to OpenAI-compatible endpoints. The difference is where the model lives. Open WebUI expects you to point it at an inference server you run or pay for, such as Ollama on your own hardware or a hosted API. cloudflare-ai-web assumes the opposite: the inference is Cloudflare's, and the project's job is to be a good client for it.

That changes the operational profile. With Open WebUI you manage model weights, GPU or CPU capacity, and storage for conversations in a database. With cloudflare-ai-web you manage one container and two environment variables, and you inherit Cloudflare's model roster and pricing instead of choosing your own. Neither is strictly better. If your requirement is data residency on hardware you control, cloudflare-ai-web cannot satisfy it because the prompts leave your machine. If your requirement is a chat page running in five minutes on a free-tier-backed account, the Docker command above is shorter than any local inference setup.

A second reference point is Cloudflare's own AI playground, which the search phrases around this project mention. The playground needs no deployment at all. cloudflare-ai-web exists for the cases where you want the interface on your own domain, behind your own password, with your own gateway routing.

Maintenance, releases and what the licence permits

The repository is not archived, and the last push was on 2026-09-06, the same day v5.0.0 was released. Before that, v4.7.0 landed on 2026-04-11 and v4.5.0 on 2025-12-08, so the release cadence is irregular rather than monthly. The version in package.json matches the v5.0.0 tag, which means the tagged release and the source tree are in step.

Upgrade cost is dominated by the front-end stack. Next.js 16.3.4, React 19.2.8, the AI SDK v7 line and Tailwind 4 all move quickly, and the project tracks them closely. A container image pins whatever was built at release time, so pulling a new tag is the low-effort path; building from source means resolving those version ranges yourself. The check script in package.json (lint, format check, typecheck, test, build) is the gate the maintainers run, and it is a reasonable thing to run locally before opening a pull request.

The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. It also requires that you keep the licence and notice files and state significant changes. Note that the licence covers this project's code, not the Cloudflare services it calls or the models it reaches; those carry their own terms, and the README does not discuss them.

Editorial conclusion

Adopt cloudflare-ai-web if you already hold a Cloudflare account with Workers AI enabled and you want a chat interface you control, without writing the streaming UI yourself. Do not adopt it if you have no Cloudflare account, if you need server-side conversation history, or if you want a platform that runs models on your own hardware. Before deploying, confirm two things in the Cloudflare dashboard: that your Workers AI token was created from the Workers AI template, and whether you want to set APP_PASSWORD, because the README states that in public mode anyone can use your inference API.

Frequently asked questions

Official sources

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