Devflare Docs
Ship it Quickstart

Deploy one preview, then delete it cleanly

Take the same starter worker, ship one named preview, then remove that preview scope cleanly.

The project tree does not need to become more complicated for the first deploy. Use the same small worker, one memorable preview name, and one equally explicit cleanup command.

Best for
The first named preview deploy and cleanup loop
Preview command
Cleanup command

Deploy a named preview

Named previews are the easiest first deploy shape because the destination is obvious in the command itself and the same name can follow the preview through CI, cleanup, and review.

If the first worker runs locally and your first test already passed, the project is ready for a simple preview loop. You do not need a new framework layer or a bigger repo ritual first.

Pick one preview name such as or . Then deploy with so the preview target is visible in your shell history and logs.

  1. 1

    Finish the worker or app locally and make sure already works.

  2. 2

    Pick a preview scope name such as or .

  3. 3

    Run the explicit preview deploy command.

  4. 4

    Open the preview and confirm the smallest important path works before you automate anything bigger.

Explicit is the point

If the command says , you already know where it is going. That clarity is the whole reason the CLI insists on explicit deploy targets.

Preview-ready worker files before you deploy

Keep the preview example anchored in the same application files a teammate would review, not only the deploy command.

Deploy the same starter worker as a named preview

The active file is just the command transcript. The project tree is still the same small worker from the earlier quickstart pages.

Delete the preview when it is done teaching you something

Preview cleanup should use the same scope name you deployed with. That keeps teardown reviewable and stops preview-only resources from lingering just because nobody remembers the exact branch name later.

If the preview owns preview-only resources, is the quickest way to remove them. Use the exact same scope string you deployed with so the target stays unmistakable.

If you later need richer lifecycle management, the dedicated preview operations docs cover scope inspection, cleanup planning, and broader cleanup runs. For the first loop, resource cleanup is enough to understand the shape.

  • Reuse the same preview scope name you deployed with.
  • Keep cleanup commands explicit so logs clearly show what is being removed.
  • If the preview becomes a real recurring workflow, move that command into CI instead of relying on team memory.

Delete previews explicitly too

Preview environments get messy when deploys are automated but cleanup rules live only in people’s heads. Use the same explicit naming discipline for teardown that you used for deploy.

Clean up the same named preview

The cleanup command should feel like the mirror image of the deploy command: same project, same scope name, same explicit target.

Previous

Your first bindings

Take the same starter worker, split it into routes and helpers, then add one binding-backed route at a time so can stay small.

Next

CLI

Start at : the root page already maps local dev, inspection, deploy intent, account inventory, preview lifecycle, production control, token management, AI pricing, and remote-mode operations in one place.