---
title: "Deploy Workers"
---

> Documentation Index
> Fetch the complete documentation index at: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy Workers

Deploy from a project containing your Worker source and Wrangler configuration.
First [connect Wrangler](/build/connect-wrangler/) to your installation and
organization.

## Deploy a version

```sh
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:

```sh
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](/build/domains/). This mapping follows deployments;
it does not create a second Worker.

For the repository's seeded applications and local deployment commands, see
[Example applications](/self-hosted/examples/).

## 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](/build/storage/) for the exact storage surface. It does
also support a key-value service through Wrangler's Workers KV binding
contract, [databases](/build/databases/) through the D1 contract,
[versioned static assets](/build/static-assets/), and [native image
transformations](/build/images/). Organization-owned model inference and Vectorize
bindings are described in [AI and vector search](/build/ai-and-vectors/).
[Native Durable Objects](/build/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:

```sh
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](https://github.com/nullbytelabs/ermahgerd/blob/main/examples/service-bindings/).

See [Organizations and access](/build/organizations/) for caller identity
and tenant restrictions.

## Configure secrets and schedules

Use normal Wrangler commands for write-only Worker secrets:

```sh
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`:

```json
{
  "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](/build/schedules/) for management and delivery guarantees.

Source: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/build/workers/index.mdx