What this is: Cloudflare Dynamic Workers let you spin up isolated Workers at runtime to execute arbitrary code — AI-generated, customer-uploaded, agent-driven. Egress Control lets you decide what the spun-up code can reach on the internet. Three patterns below. Paste code, pick a pattern, hit Run.
✓ This is real. Your code is loaded into a fresh, isolated Worker at runtime via the worker_loaders binding (env.LOADER), and its network egress is genuinely enforced by the Cloudflare runtime. Scenario A uses globalOutbound: null; Scenarios B and C route every outbound fetch() through an HttpGateway WorkerEntrypoint handed to the sandbox via ctx.exports. The badge next to Run shows real or simulated — it only falls back to a simulation if the platform ever returns an error, so the demo never breaks live.
🚫 Scenario A
Block all egress
The spun-up Worker can't reach the internet at all. Any fetch() throws.
🛂 Scenario B
Allow-list one domain
Gateway intercepts every fetch. Only api.github.com is allowed through.
🔑 Scenario C
Inject credentials
Gateway adds an Authorization header from the parent's env. Child never sees the secret.
How it works
The loader Worker passes
globalOutbound: null to the Dynamic Worker. Cloudflare's runtime makes every
fetch() and
connect() call throw immediately. The child can do compute, use bindings you provide, but it cannot reach the network.
Maximum isolation.
How it works
The loader Worker passes a
HttpGateway WorkerEntrypoint as
globalOutbound. Every
fetch() from the child is routed through the gateway. The gateway checks the URL: requests to
api.github.com are forwarded; everything else returns a 403.
Custom egress policy.
How it works
Same gateway pattern as B, but the gateway also injects an
Authorization: Bearer … header from
this.env.API_TOKEN before forwarding. The Dynamic Worker code never sees the token — it just calls
fetch() normally.
Secrets stay in the parent.
Pick a scenario, edit the code if you want, then hit Run.