Deploy Workers | ermahgerd

Deploy from a project containing your Worker source and Wrangler configuration. First connect Wrangler to your installation and organization.

Deploy a version

npx wrangler deploy --message git:abcdef0

Use your release’s short Git SHA or another meaningful identifier in the message. The Worker name comes from your Wrangler configuration. To publish under a different name:

npx wrangler deploy --name another-worker --message release:2026.10

Create required resources and declare their bindings before deploying, unless your framework’s normal deployment flow provisions them automatically. Bindings must refer to resources in the same organization.

Reach a deployed Worker

Open the Worker’s overview in the tenant console and copy its published URL. The hostname combines the Worker name, immutable organization namespace, and the installation’s Worker domain. Two organizations can use the same Worker name without sharing a route. A bare platform hostname does not select a Worker.

To use your own hostname, open the Worker’s Domains tab and follow the custom-domain setup. This mapping follows deployments; it does not create a second Worker.

For the repository’s seeded applications and local deployment commands, see Example applications.

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 installation, so a running installation restores its routes after a service or VM restart.

Supported runtime surface

The platform 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 service-binding example.

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.