Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

cf workers delete leaves the Containers application running and billing; no combined teardown

Open
  • Is something wrong?
#184 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
cli, cloud

Research direction

No source files or tests are named. Start by tracing the cf workers delete and cf containers applications delete command paths, then reproduce the Worker-plus-Containers deployment described above. Done means the Worker deletion detects owned container applications and provides the explicit teardown or refusal behavior described in the issue, with verification that instances are handled safely.

Written by the indexing model from the issue text.

Description

upstream

cf workers delete and cf containers applications delete are separate operations, so retiring a Workers+Containers project leaves billable containers running

A Worker with a Containers binding provisions a separate Containers application. Deleting the Worker does not touch it, and there is no combined teardown path in the CLI.

Reproduction

Deploy a Worker with a containers block, start a container, then delete the Worker:

cf deploy
curl -s "$WORKER/inventory"          # starts a container
cf workers delete my-worker --force  # "Successfully deleted my-worker"

cf workers list                       # my-worker absent
cf containers applications list       # my-worker-mycontainer still present

The application retains running instances, and Containers bills per vCPU-hour and
GB-hour. With the Worker gone there is no interface left to stop the container, so
it has to be located and removed by application ID:

cf containers applications list       # find the id
cf containers applications delete <application-id> --force

Deletion is itself not synchronous: it reports "Application has been deleted.
It might take a while for all the app instances to completely shutdown." So even
after a successful delete there is no immediate confirmation that instances have
stopped.

Impact observed

Across five spike deployments, deleting all five Workers left five container
applications behind, four of them with instances still running. The only reason
they were found was checking cf containers applications list separately — the
Worker listing looks clean.

Suggested behaviour

cf workers delete should report any container applications the Worker owns, and
offer to remove them, or refuse without an explicit flag that covers them. The
failure is invisible by default and the cost is real.

Related

The same split exists in wrangler — wrangler deploy creates the pairing and
wrangler delete removes only the Worker. Filed separately against
cloudflare/workers-sdk as #16008. This issue is about cf having no combined path
either, which matters more for agent use since cf is the tool recommended for
API-level work.

Environment

  • cf v1.0.0-beta.10
  • containers[].class_name with scheduling_policy: "durable_object"
  • Workers Paid account
  • Note that cf requires CLOUDFLARE_ACCOUNT_ID to be set when more than one
    account is reachable, and path parameters are rejected as flags on some
    commands — see the other issues filed from the same session.
Dominant language
TypeScript
Stars
916
Forks
53
Avg merge
18h 31m
Merged PRs (30d)
172

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cloudflare/cf

All issues in cloudflare/cf

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.