Skip to content
WebShield Docs

Functions (Workers)

A Cloudflare Workers project on WebShield with no rewrites — wrangler.jsonc, Durable Objects, D1, KV and cron. Deploys, D1 migrations, KV imports, returning data to a point in time, your own domain behind the WAF.

A function is a Cloudflare Workers project that runs here exactly as written: the same wrangler.jsonc, the same code, the same bindings. Requests to a function get the same protection as requests to an app — the WAF, rate limits, bans and bot protection if you turned it on.

A function lives in a project under Services → Apps: when adding one, choose Function (Workers). It is in beta.

  • fetch and scheduled handlers (cron from triggers.crons);
  • Durable Objects with SQLite storage and alarms;
  • D1 and KV;
  • queues;
  • variables: vars from the config plus the variables set in the dashboard.

Containers and Sandbox are not supported.

You need the project directory with wrangler.jsonc or wrangler.json in it; wrangler.toml will not do — convert it to JSON. If there is a package.json, dependencies are installed by the package manager whose lock file we find (npm, pnpm or yarn), and the build script runs if it is declared. Then the project is deployed by the Wrangler config.

Terminal window
webshield apps deploy --project shop --app api

An archive from your computer on the Deployments tab and an https link to a .tar.gz work too (more on the ways to deploy in Apps). The new version starts answering within ten seconds after the deployment turns Live.

Variables. The Variables tab is what the Worker gets in env on top of vars from the config. They are stored encrypted, so secrets go here as well. References to the project databases work too: DATABASE_URL = ${{db.url}}. Variables are part of a deployment, so after editing them press Redeploy: the function is rebuilt from the same archive with the new values. From the terminal — webshield apps env set … --redeploy.

Rollback. Roll back to this on an earlier deployment switches the code within seconds, the data stays as it is. The earlier version comes back with the variables it had.

Hostnames are attached on the Hostnames tab, the same way as for an app. Inside the Worker request.url holds your hostname, not our address.

The Log tab shows the output of the function for the last 7 days: console.log and uncaught exceptions of handlers with their stack. On such an exception a visitor gets a 500 response with no details — the error text and the stack are visible only to you.

D1 databases and KV namespaces are declared in wrangler.jsonc as usual. From outside they are reached with the CLI. The commands run from the project directory: they need wrangler.jsonc, the migrations directory and the key files.

Terminal window
webshield apps d1 migrate --app api app-db # apply new migrations from migrations/
webshield apps d1 migrations --app api app-db # which are applied
webshield apps d1 execute --app api app-db --command "SELECT count(*) FROM users"
webshield apps d1 execute --app api app-db --file seed.sql
webshield apps kv import --app api CACHE seed/keys.json # Wrangler bulk format
webshield apps kv delete-keys --app api CACHE old-keys.json

app-db is the database_name from wrangler.jsonc, CACHE is the id of the KV namespace. The key file must be inside the directory and get into the archive (not be excluded by .gitignore). The function must already be deployed. One SQL request is up to 100 KB: load large data sets with migrations.

The history of operations and their output is on the Data tab.

The data of a function — Durable Objects, D1, KV, queues and alarms — can be returned to any moment of the last 7 days. The code stays as deployed.

Data tab → Return data to a moment, or from the terminal:

Terminal window
webshield apps window --app api # from and to which moment
webshield apps restore --app api --time 2026-10-21T15:00:00+03:00

While the restore runs, the function is stopped and answers 503. The history is kept: if you went to the wrong moment, return the data to the moment before the restore.

The data of one function gets 2 GB. This includes earlier versions of the data for 7 days: returning to a point in time relies on them. The Data tab shows how much is used; at 80% you get an email.

When the space runs out, the function stops answering requests, even those that do not touch the data, and cannot recover on its own. Do not let it get there — remove what you no longer need in advance; the space frees up once the versions of removed data leave the window. If the space is not enough, contact support.

With Always running instances = 0 the function sleeps without requests. We track Durable Object alarms and cron ourselves and wake the function on time, so schedules run for a sleeping function too. The first response after sleep comes with a delay; if that matters, set it to 1.

The same as for apps: CPU and memory while the function runs, data at the price of object storage, including the earlier versions for 7 days. A sleeping function pays only for its data.