Deploy Workers

Worker code enters ermahgerd through Wrangler. Ansible owns the fleet, runtime pool, management services, and HAProxy; it does not install application code.

Deploy the bundled Worker

make deploy

The richer bundled applications are deployed with make examples-deploy. Their resources and bindings are described in Example applications.

The target deploys examples/sum/ using the local deployment API. It provides a short Git-style deployment message automatically. Set WRANGLER_MESSAGE when your build or release system has its own provenance identifier:

make deploy WRANGLER_MESSAGE=release:2026.10

To deploy the same source under another Worker name:

make deploy WRANGLER_NAME=another-sum

Use Wrangler directly

Configure Wrangler with an organization UUID and an organization read-write token. The bootstrap organization is available only for local development:

cd examples
CLOUDFLARE_API_BASE_URL=http://127.0.0.1:9090/client/v4 \
CLOUDFLARE_ACCOUNT_ID=11111111-1111-4111-8111-111111111111 \
CLOUDFLARE_API_TOKEN=local-development-token \
npx wrangler deploy --config sum/wrangler.jsonc --message git:abcdef0

Create organization tokens in the console before deploying for another tenant. The organization UUID is the Wrangler account ID. See Organizations and access.

Reach a deployed Worker

Each organization receives an immutable DNS-safe namespace. A Worker is routed at its own tenant subdomain:

https://<worker>.<organization-namespace>.workers.ermahgerd.localhost:8443

For the bootstrap tenant, sum is available at https://sum.t-bd7662a5eeb4.workers.ermahgerd.localhost:8443. There is no default Worker: bare localhost and 127.0.0.1 do not select application code.

Versions and rollback

Every upload is stored as an immutable version. The console presents retained versions and their deployment history; select a version and use its deployment action to restore it. New ingress requests use the selected immutable route after HAProxy publishes the change. Requests already executing retain the version selected when they entered the runtime.

The deployment API validates an upload with workerd compile --config-only before it can become active. Version metadata and artifacts are durable for the life of the appliance, so a running appliance restores its routes after a service or VM restart.

Supported runtime surface

The appliance supports multiple named Workers, ES modules including imported WebAssembly, compatibility dates and flags, plain-text and JSON bindings, encrypted Worker secrets, Cron Triggers, ordinary outbound HTTP/HTTPS, same-organization service bindings, and common R2 bucket binding operations. See Object storage for the exact storage surface. It does also support a key-value service through Wrangler’s Workers KV binding contract, databases through the D1 contract, versioned static assets, and native image transformations. Organization-owned model inference and Vectorize bindings are described in AI and vector search. Native Durable Objects provide named SQLite-backed state, RPC, alarms, and WebSockets for Workers that declare Wrangler migrations. Worker upload requests are bounded at 128 MiB. It does not provide Cloudflare route resources, gradual traffic splitting, or preview URLs.

Workers are logical identities with version history. They do not receive a dedicated process, port, systemd unit, or network namespace.

Delete a Worker

Use Wrangler to retire a Worker through the same API used for deployment:

npx wrangler delete my-worker

Wrangler refuses deletion when another Worker has a service binding to the target. Review the dependency and remove that binding first, or use --force when breaking it is intentional. Deletion removes the Worker’s route, code and version history, secrets, schedules, queue-consumer triggers, static assets, and Durable Object state. Independently provisioned buckets, databases, key-value namespaces, queues, model providers, and vector indexes are not deleted merely because the Worker had bindings to them.

The console offers the same operation from the Worker’s overview. It requires typing the Worker name as explicit confirmation.

Call another Worker

Declare a Wrangler service binding to grant a Worker the narrow capability to call one named Worker in the same organization. The target resolves to its active version at call time, so a target deployment does not require callers to be redeployed. Global fetch() and connect() can reach public Internet addresses. Workerd’s public-only network capability rejects loopback, WireGuard, link-local, and other private destinations; internal platform access remains available only through declared bindings.

The repository includes a runnable example:

make service-binding-check

See Organizations and access for caller identity and tenant restrictions.

Configure secrets and schedules

Use normal Wrangler commands for write-only Worker secrets:

printf '%s' "$PROVIDER_API_KEY" | npx wrangler secret put PROVIDER_API_KEY
npx wrangler secret list
npx wrangler secret delete PROVIDER_API_KEY

Secret changes create immutable versions. Ordinary secret commands deploy the new version immediately; wrangler versions secret put creates a version for a later deployment. Values are encrypted in the control database, omitted from artifacts and API responses, and made available to application code through env.PROVIDER_API_KEY. Anyone authorized to deploy arbitrary code to that Worker can read its secrets at runtime.

Declare recurring UTC schedules in wrangler.jsonc or wrangler.toml:

{
  "triggers": { "crons": ["*/5 * * * *"] }
}

wrangler deploy replaces the Worker’s trigger set after publishing code. A native coordinator object on the Worker’s stable data shard stores the desired triggers, wakes through a workerd alarm, durably leases due work, and invokes the active version’s scheduled() handler through the trusted runtime dispatcher. Failed deliveries are retried and may be delivered more than once; missed intervals are advanced rather than replayed as a wake storm after downtime. Pause or resume a Worker’s deliveries in Compute → Schedules without changing its Wrangler configuration. Organization suspension also stops delivery without deleting triggers. Resuming can deliver one overdue occurrence before advancing to a future time; it does not replay every missed interval. See Schedules for management and delivery guarantees.