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.
⚠ Note: this demo is a faithful simulation of the Dynamic Workers + Egress Control product. The page behaves exactly like a real Dynamic Worker would — same gateway log shape, same response model, same egress modes. We simulate it here because Dynamic Workers requires a paid Workers plan, and this lab account is on the free tier. For a real deployment, restore the worker_loaders binding + HttpGateway class (commented examples below).
🚫 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.
← Back to demo dashboard