Executor Cloudflare MCP Server
Provides read-only access to the Cloudflare API (accounts, zones, Workers, D1, R2, etc.) via a curated OpenAPI spec, allowing AI agents to query Cloudflare resources without mutating them.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Executor Cloudflare MCP Serverlist available tools on my Executor instance"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Executor on Cloudflare
Deploy Executor (an open-source integration layer for AI agents) to your own Cloudflare account, private behind Cloudflare Access, and update its version remotely. Uses Alchemy to declare the resource graph, including the Access application and policy.
Deploy the whole graph with one command; private once
bun run verifypasses.Agents and CLIs reach
/mcpwith an Access service token, no browser.Update the pinned Executor version by redeploying, locally or via an approval-gated tool callable from the endpoint.
Updating Executor's version
The Executor version is pinned in scripts/bootstrap.ts. Updating means changing
that pin and redeploying. Two ways:
# From the machine: override the pin and redeploy.
EXECUTOR_REVISION=<full-commit-sha> bun run deployRemotely: self_edit is a small server that runs where the repo and Cloudflare
credentials live. You register it with Executor so it's callable from the gated
/mcp endpoint. When called, it changes the pin, rebuilds that revision, and
redeploys — the build and deploy run on that machine, not inside the Worker. So
an update can be triggered from any client that can reach the endpoint, not just
from the deploy machine directly. Every call is approval-gated. Walkthrough:
docs/self-edit.md.
self_edit edits any file in this repo and redeploys, so it covers more than
version bumps, but version updates are its purpose. Across an update, D1, R2, the
Durable Object, the secret, the hostname, and Access are preserved.
Related MCP server: AI Backend MCP Server
What deploy sets up
One command provisions the whole graph in code, so there's no "deploy, copy the Access audience by hand, deploy again" step. All resources are created in your account (deployment still pulls from GitHub and npm):
Resource | Purpose |
Worker + web assets | console, API, |
D1 | application data |
R2 | specs and plugin blobs |
Durable Object | MCP sessions |
Encryption secret | at-rest key (generated; Worker secret) |
Custom hostname | stable origin you own |
Access app + email policy | browser sign-in |
Access service token + policy | headless agents/CLIs |
workers.dev and preview URLs are off.
Prerequisites
Bun 1.3+ and Git
A Cloudflare account where you can create Workers, D1, R2, Durable Objects, Worker secrets, custom hostnames, and Zero Trust Access apps/policies/tokens
A hostname in a zone on that account (e.g.
executor.example.com)A Zero Trust team domain (e.g.
your-team.cloudflareaccess.com)
Setup
About 5 minutes once the prerequisites are ready (account enablement, Zero Trust onboarding, and the first Executor build can take longer). POSIX shell; on Windows use WSL.
git clone https://github.com/acoyfellow/executor-cloudflare
cd executor-cloudflare
bun install
cp .env.example .env # then edit it; the variables and examples are in that file
bunx alchemy login
bun run deploydeploy checks out the pinned Executor commit under vendor/, builds it, and
applies the stack:
Done: 8 succeeded
{ url: "https://executor.example.com", mcpUrl: "https://executor.example.com/mcp" }It also writes the generated Access service-token credentials to .env.mcp
(git-ignored). Re-running with unchanged config reuses the data resources; the
Worker and assets may update. Review the plan before applying; changed config or
lost Alchemy state can replace resources.
Verify
bun run verifyAnonymous request blocked by Cloudflare Access (302).This only proves anonymous requests are turned away. Also open the URL in a private window, sign in with the allowed email, and confirm the console loads.
Connect an agent
Agents reach /mcp with the Access service token the stack wrote to
.env.mcp (no browser). The client id/secret are a bearer credential to the
endpoint; anyone holding them gets the same access. See
docs/connect-clients.md. Quick check:
bun --env-file=.env.mcp run scripts/verify-mcp.ts
# -> Headless MCP initialize succeeded (200). No browser involved.Architecture
See docs/architecture.md. Executor's sandboxed catalog
tools can only call what they connect to; they can't deploy. self_edit is a
separate server running where the repo and credentials live; registering it lets
Executor call it through /mcp, but the build and redeploy happen on that
machine, not in the Worker:
agents --> <your-host>/mcp --> catalog tools (sandboxed; can't deploy)
self_edit (registered) --> server on the deploy
machine: edit pin,
rebuild, redeploy
operator --> self_edit (local) --> same server, called directlyself_edit rejects paths resolving outside this repo (tested) and requires a
bearer token. Deployment runs code from this repo, so repo-write is effectively
code execution with the deploy process's Cloudflare credentials. The path check
and approval prompt are controls, not a sandbox. There is no auto-approve mode.
Teardown
bun run destroy # can delete D1/R2 data — don't run it on data you needDevelopment
bun run check # tests + typecheck, no Cloudflare credentials neededvendor/, .env, .env.mcp, and Alchemy state are git-ignored.
Security
Cloudflare Access authenticates requests to the hostname; an unguessable URL is never relied on for privacy. Access admits a client but doesn't authorize individual tools.
Catalog tools get only their configured bindings; they have no deploy path.
self_editis high-authority (repo write plus deploy), guarded by a path check, a bearer token, and an approval prompt, not a sandbox.Don't commit
.env,.env.mcp, or Alchemy state. Treat MCP arguments andself_editdiffs as sensitive in logs. SeeSECURITY.md.
Limitations
An example, not a product; use a non-production account until you've reviewed it.
Treat
destroyas destructive; D1/R2/Access retention isn't fully characterized.Pins one Executor revision and one Alchemy version.
No unattended self-edit, and no production observability or scale envelope.
Setup is tested on macOS/Linux; Windows is untested (use WSL).
Layout
alchemy.run.ts resource graph (Worker, D1, R2, DO, secret, Access)
src/config.ts validated .env inputs
scripts/bootstrap.ts pin + build vendored Executor (the version lives here)
scripts/verify*.ts anonymous-access + headless-MCP checks
scripts/mcp-bridge.ts stdio-to-HTTP bridge for local MCP clients
scripts/self-edit-* edit-and-redeploy tool (core, local stdio, catalog HTTP)
docs/ · test/ architecture/self-edit/connect · config + boundary testsLicense
MIT
This server cannot be installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Latest Blog Posts
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/acoyfellow/executor-cloudflare'
If you have feedback or need assistance with the MCP directory API, please join our Discord server