Skip to content

Worker templates

Last updated View as MarkdownAgent setup

These templates are starting points for Workers invoked by Forward policies. You can adapt them or write your own Worker using the GatewayMiddleware.handle(request, context, next) entrypoint. Each script implements one task.

Template What it does
Send a Slack notification Send a background notification when a selected request completes.
Capture a screenshot Capture a public page in an independent browser and save the image to R2.
Capture a downloaded file Save a bounded copy of an attachment to R2 while returning the download to the user.
Watermark HTML pages Add a visible user label to an HTML response.
Store headers and bodies as JSON Archive selected headers and bounded JSON request and response bodies in R2.
Display a coaching page Return an explanatory page without contacting the original destination.
Redact a JSON field Replace a specific field in an application request before sending it upstream.

Use a template

Follow Set up Forward, replace the pass-through script with a template, and configure its bindings. Deploy the Worker before selecting it in a Forward policy. Each template lists a test and the traffic scope it expects.

The gateway-workers skill ↗︎ provides guidance for coding agents on the named entrypoint, Gateway context, and validation.

Every TypeScript template includes import type declarations for GatewayMiddlewareContext and GatewayMiddlewareNext from @cloudflare/zt-types ↗︎. Install this package as a development dependency in your Worker project before using a template. Each template includes the installation command.

The package supplies Gateway types. Continue to import the runtime WorkerEntrypoint class from cloudflare:workers. The import type declarations are removed when TypeScript compiles. The JavaScript version omits them and the type annotations, so it does not need @cloudflare/zt-types.

Begin with a test host and test user group. Page loads produce multiple HTTP requests, so scope notifications and screenshots to a specific method and path, rather than every request to a domain. Keep capture buckets private and configure R2 lifecycle rules for retention. Capture only data your organization permits you to store.

Background examples use this.ctx.waitUntil(). They return the user's response without awaiting the background operation. A background failure is logged and does not change the returned response. Background work has limited execution time. Use Queues or Workflows when you need durable processing.

Body capture uses cloned streams. A slow capture consumer can cause a clone to buffer data while the other consumer advances. The examples limit captured bytes, but cloning is not a guarantee of constant memory use or zero impact on traffic. Keep capture policies narrow and test representative body sizes and transfer speeds.

Was this helpful?