Create Cloudflare Worker Previews

Deploy branch-specific Worker previews and compare them with production.

Introduction

30 Second Summary

A promising change can still behave differently once real people reach it. Testing against the live version makes every experiment feel riskier than it should.

In this project, you will build a small endpoint with Cloudflare Workers that returns a short JSON message at a production URL. You will then use Worker Previews to give a branch its own URL, configuration, and logs while production stays unchanged.

What You'll Build

You open two live URLs side by side and see a branch change working in its own preview while production keeps serving the original response.

By the end of this project, you'll have:

  • A production URL that serves a short JSON response from your Worker.
  • A branch preview URL that shows the changed message plus a preview-only environment value while production keeps its original response.
  • Request logs and cleanup proof that show the exact call you made to the preview. You will also confirm that the deleted preview URL stops serving while production stays live.
  • An optional Secret Mission to push your skills further.

Are there any prerequisites?

You'll need a Cloudflare account, Node, the Wrangler CLI, a repository for the Worker, and a code editor. The project uses only the Workers free plan.

Before We Start

Branch previews need a production baseline before they can prove that a change is isolated. Your account provides the deployment space for that baseline.

You'll confirm access to Cloudflare Workers. You'll also prepare a local Git repository whose production branch is main.

In this step, get ready to:
  • Confirm that your Cloudflare account can access Workers.
  • Check that Git is available on your computer.
  • Create a local repository with a production branch named main.
Confirm your Cloudflare access

The Cloudflare dashboard is where you manage Workers. Reaching the Workers page confirms that your account has access before you try to deploy anything.

You'll enter credentials only on Cloudflare's official account page. This access check creates no Worker or billable resource.

✔️ The dashboard opens

Your existing session is active. Continue below to check your Workers access.

ⓧ I see the sign-in page

  • Choose the sign-in option associated with your Cloudflare account.
  • Complete the authentication prompts for your account.
  • Return to the Cloudflare dashboard.

ⓧ I need a Cloudflare account

Your password stays on Cloudflare's official account page. Creating the account does not create a billable resource.

  • Open Cloudflare's account creation guide.
  • Select the official Sign up page link in the guide.
  • Enter your email address in the Email field.
  • Enter a secure password in the Password field.
  • Select Create Account.
  • Open the verification email from Cloudflare.
  • Select the verification link in the email.
  • Return to the Cloudflare dashboard.
  • Select Workers & Pages in the dashboard sidebar.

You'll see Create application on the Workers page. Its presence confirms that your account can create and deploy a Worker.

Your Cloudflare access is ready for the first production deployment.

Check Git on your computer

Each preview follows a branch in your repository. Git provides the branch history that keeps production separate from preview work.

  • Press Cmd+Space on macOS or the Windows key on Windows to open your search bar.
  • Type Terminal on macOS or PowerShell on Windows. Press Enter.
  • Check whether Git is available by running this command:
git --version

What does this command check?

The command asks Git to print its installed version. A version line confirms that your terminal can find the Git program.

✔️ I see a Git version

You should see a line beginning with git version. Git is ready to create the repository.

ⓧ Git is not recognized

Git needs to be installed before your terminal can create the repository. Choose your operating system below.

macOS

  • Start the Apple installation prompt by running this command:
xcode-select --install
What does this command do?

This command opens the installer for Xcode Command Line Tools. That package includes Git for your terminal.

  • Complete the installation prompts shown by macOS.
  • Return to Terminal after the installation finishes.
  • Confirm that Git is now available by running this command:
git --version
What does this check prove?

The version command confirms that the installation finished successfully. It also proves that Terminal can locate Git.

You'll now see a line beginning with git version.

Still unable to run Git?

Close Terminal after the installer finishes. Reopen it before running the version check again.

If Git is still unavailable, help me check my macOS Git installation.

Windows

Cloudflare development uses the standard Git commands provided by Git for Windows.

  • Open the official Git for Windows installation page.
  • Download the standalone installer that matches your Windows processor.
  • Run the downloaded installer.
  • Keep the default options in the installer.
  • Close PowerShell after the installation finishes.
  • Press the Windows key to reopen your search bar.
  • Type PowerShell and press Enter.
  • Confirm that Git is now available by running this command:
git --version
What does this check prove?

The version command confirms that the installation finished successfully. It also proves that PowerShell can locate Git.

You'll now see a line beginning with git version.

Still unable to run Git?

Restart PowerShell after the installer finishes. An older PowerShell window may not know about the new installation.

If Git is still unavailable, help me check my Windows Git installation.

Your terminal can now call Git whenever this project needs to create or inspect a branch.

Create the production repository

The repository starts with one empty production branch. Naming that branch main gives every later preview branch a clear baseline.

  • Choose a short name for your repository folder.
  • Record the folder name here: your repository folder name.
  • Create the repository on your Desktop by running these commands:
cd ~/Desktop
git init [[REPOSITORY_NAME="your repository folder name"]]
cd [[REPOSITORY_NAME="your repository folder name"]]
git branch -M main

What do these commands do?

  • The first command places the repository on your Desktop so you can find it easily.
  • The second command creates the repository metadata inside your chosen folder.
  • The third command moves your terminal into the new repository.
  • The final command names the production branch main.

You'll see a terminal message confirming that an empty Git repository was initialized.

Repository not created?

Check that the folder name contains no unfilled placeholder text. Run the commands again with the same folder name.

If the initialization still fails, help me create my local Git repository.

Before you run the final check, which branch name do you expect Git to report?

  • Confirm the repository state by running this command:
git status

What does this command prove?

The status command reports the current repository state. Its first line identifies the branch your terminal is using.

You'll see On branch main. That result proves the repository exists with the correct production branch.

Your production baseline is ready. Cloudflare access and local branch tracking now have a shared starting point.

Next up, you'll add the Worker project to this repository and deploy its first production response.

Deploy Your Production Worker

A branch preview only proves isolation when there is a production response beside it. Right now, your Git repository has no live baseline for that comparison.

In this step, you'll add a small Cloudflare Worker that returns a JSON message. Workers Builds then deploys the repository's default branch to a production URL.

In this step, get ready to:
  • Add the production Worker source to your repository.
  • Publish the source on the default production branch.
  • Deploy the Worker through Cloudflare and open its production URL.

Why connect the repository?

A Git-connected deployment gives your production branch a repeatable path to Cloudflare. Future pushes can create builds without copying code into the dashboard.

That connection also gives later branches a shared source repository while keeping their previews separate from production.

Add the Worker project files

Every incoming request reaches the Worker's fetch() handler. The handler needs to return a stable production message that later previews can differ from.

  • Open the local Git repository from earlier in your code editor.
  • Create a folder named src inside the repository's top-level folder.

You should now see the src folder in your editor's file list.

  • Create a file named index.js inside the src folder.
  • Define the production response by pasting this code into src/index.js:
export default {
  async fetch(request) {
    // Keep the production response stable for later preview comparisons.
    const data = {
      message: "Hello from production",
    };

    return Response.json(data);
  },
};

What does this code do?

  • The fetch() handler runs whenever someone requests the Worker URL.
  • The data object holds the message that identifies this deployment as production.
  • Response.json() serializes that object into a JSON response for the browser.
  • Save src/index.js.
  • Confirm that src/index.js remains visible beneath the src folder in your editor.

Can't find the Worker file?

Check that index.js sits inside src. The final path must be src/index.js.

Make sure the file name does not end with an extra text-file extension.

Help me check my Worker file structure.

✔️ Awesome, I've got everything!

Your production request handler is saved in src/index.js.

ⓧ I'd like to double check the full code

export default {
  async fetch(request) {
    // Keep the production response stable for later preview comparisons.
    const data = {
      message: "Hello from production",
    };

    return Response.json(data);
  },
};

Wrangler configuration tells Cloudflare which Worker to deploy. It also points the deployment process to the request handler you just created.

  • Create wrangler.jsonc inside the repository's top-level folder.
  • Configure the Worker by pasting this code into wrangler.jsonc:
{
  "name": "branch-live-url-worker",
  "main": "src/index.js",
  "compatibility_date": "2026-09-11"
}

What does this configuration do?

  • name gives the deployed Worker the required branch-live-url-worker name.
  • main directs the deployment process to src/index.js.
  • compatibility_date pins the runtime behavior used by this project.
  • Save wrangler.jsonc.
  • Confirm that wrangler.jsonc appears beside the src folder in your editor's file list.

Configuration file missing?

Check that wrangler.jsonc is in the repository's top-level folder. A copy inside src will not be found from the expected location.

Confirm that your editor did not save the file as wrangler.jsonc.txt.

Help me validate my Wrangler configuration.

✔️ Awesome, I've got everything!

Your Worker name and entry file are now defined in wrangler.jsonc.

ⓧ I'd like to double check the full code

{
  "name": "branch-live-url-worker",
  "main": "src/index.js",
  "compatibility_date": "2026-09-11"
}
Publish the production branch

Cloudflare can only import code that your Git provider can access. Publishing these files places the Worker source on the repository's default production branch.

  • Switch to the terminal for your local repository.
  • Stage the project files by running the commands below:
git add .
git commit -m "your message"
git push origin HEAD

What do these commands do?

  • git add . stages the Worker source and configuration for the next commit.
  • git commit -m "your message" records the staged files on your current production branch.
  • git push origin HEAD sends the current branch to the branch with the same name on the origin remote.
  • Confirm that the terminal reports a completed push to the remote repository.

Good progress. The default production branch now contains src/index.js and wrangler.jsonc.

Push did not complete?

Check that the repository has a remote named origin. Confirm that your Git provider credentials still allow pushes to the repository.

If Git reports that there is nothing to commit, confirm that both project files were saved before staging them.

Help me diagnose this Git push.

Deploy and open the production Worker

The repository now contains everything Cloudflare needs for a production deployment. Connecting it through Workers Builds turns each future production-branch push into a new deployment.

  • Return to the Cloudflare dashboard from earlier.
  • Select Workers & Pages from the dashboard navigation.
  • Select Create application.
  • Select Get started next to Import a repository.

Cloudflare may ask for permission to read repositories from your Git provider. The authorization only needs access to the repository you are importing.

  • Choose the Git account that contains your repository.
  • Approve the authorization prompt if Cloudflare displays one.
  • Select the repository containing wrangler.jsonc.
  • Confirm that Git branch shows the repository's default production branch.

What does the repository connection change?

Workers Builds listens for commits on the selected production branch. A successful production build promotes the uploaded Worker to the active deployment.

The name in the dashboard must match branch-live-url-worker from wrangler.jsonc.

  • Replace the generated project name with branch-live-url-worker.
  • Leave Build command (Optional) empty.
  • Leave Deploy command at its default value.
  • Select Save and Deploy.

The build page should finish with a successful production deployment for branch-live-url-worker.

Build did not succeed?

Confirm that the dashboard project name matches the name value in wrangler.jsonc.

Check that the selected Git branch contains both wrangler.jsonc and src/index.js.

Help me troubleshoot this Workers build.

  • Copy the provided production URL here: your production Worker URL.

Before you open the URL, what message do you expect the production branch to return?

  • Open your production Worker URL in a new browser tab.

You should see {"message":"Hello from production"} in the browser. This proves that the default branch is serving the production response from Cloudflare.

Your production baseline is live. You now have a stable response that every branch preview can be checked against.

Your production Worker is ready for comparison. Next up, you'll change the message on a branch and deploy it to a separate preview URL.

Deploy a Branch Preview

Your production Cloudflare Worker now serves a JSON response from its live URL. Editing that deployment directly would replace the response your production visitors receive.

Worker Previews gives each Git branch its own deployment. In this step, you will change the message on a feature branch without promoting that change to production.

In this step, get ready to:
  • Enable preview builds for non-production branches.
  • Create the feature-preview-message branch with an updated Worker response.
  • Confirm the updated response at its own preview URL.
Prepare Cloudflare for branch changes

Cloudflare needs permission to build commits from branches outside production. Once enabled, those commits follow the preview deployment path.

  • Switch back to the Cloudflare dashboard from earlier.
  • Select Workers & Pages in the dashboard sidebar.
  • Select branch-live-url-worker from the Workers list.
  • Select Settings.
  • Select Build.
  • Locate Branch control.
  • Enable Builds for non-production branches.

You should see that builds for non-production branches are enabled. Cloudflare can now turn your next branch commit into a preview deployment.

How Do Branch Builds Protect Production?

Cloudflare keeps the production branch on the production deployment path. Commits from other branches use a preview path that does not promote them to the live Worker.

Can't Find Branch Control?

Confirm that you selected branch-live-url-worker before opening Settings. The branch controls belong to the selected Worker's build settings.

Help me find the branch build settings for my Cloudflare Worker.

Give the preview its own message

A branch begins as a copy of the production source. Changing only the branch keeps the production source on Hello from production.

  • Return to your Git repository from earlier.
  • Open the branch selector above the repository's file list.
  • Enter feature-preview-message in the branch search field.
  • Create feature-preview-message from the default production branch.

Why Start From Production?

The new branch starts with the same Worker source that is already running successfully. Its next commit captures only the message change you want to test.

  • Open the Worker source file from earlier.
  • Select the repository's edit control.
  • Locate Hello from production in the response.
  • Replace it with Hello from branch preview.
  • Enter Update branch preview message as the commit summary.
  • Commit the change to feature-preview-message.

Your branch source should now show Hello from branch preview. The default production branch still contains the original message.

Confirm the preview deployment

The branch commit triggers a separate Cloudflare build. A successful build provides a Preview URL that always points to the latest deployment for this branch.

  • Switch back to the Cloudflare dashboard.
  • Select branch-live-url-worker.
  • Select the Deployments tab.
  • Locate the new version associated with feature-preview-message under Version History.
  • Select View build for that version.
  • Wait for the preview build to report a successful deployment.
  • Record the Preview URL here: your branch preview URL.

The preview deployment is ready when its build succeeds and its Preview URL is available. That URL targets the branch deployment instead of the production deployment.

  • Before opening the URL, predict which message the branch preview should return.
  • Open your branch preview URL in a new browser tab.

You should see a JSON response containing Hello from branch preview. Your feature branch now has a live URL with its own response.

Still Seeing the Production Message?

Confirm that the build details name feature-preview-message. Make sure you opened the Preview URL from that successful build.

Help me troubleshoot a Cloudflare branch preview that still returns the production message.

Your feature branch now serves its updated response at a separate live URL. Next, you will place the preview beside production to prove that the two deployments stay independent.

Compare the Live URLs

Your feature branch is now live through Cloudflare Worker Previews at its own address. The production Worker still serves the original response.

A separate URL only matters if it keeps branch changes away from production. In this step, you'll place both responses side by side to prove that boundary.

In this step, get ready to:
  • Open the production URL in its own browser window.
  • Open the branch preview URL in a second browser window.
  • Confirm that each URL serves its own message.
Open both deployments side by side

Each live URL points to one deployment. Opening both at once makes the separation visible.

  • Return to the branch-live-url-worker Worker in the Cloudflare dashboard from earlier.
  • Select the production deployment's Cloudflare-provided URL to open it in a browser tab.
  • Drag the production tab away from the browser tab bar to place it in its own window.
  • Switch back to the Cloudflare dashboard tab.
  • Select the preview URL for feature-preview-message to open it in a browser tab.
  • Drag the preview tab away from the browser tab bar to place it in its own window.
  • Place the production window on the left side of your screen.
  • Place the preview window on the right side of your screen.

You should now see one JSON response in each window. The address bars should show different URLs.

Verify the deployment boundary

The message value identifies the source version served by each deployment. Comparing that value proves whether the branch change stayed isolated.

Before you reload either page, predict whether the branch response has replaced the production response.

  • Reload the production browser window.

In the production response, you'll see Hello from production as the JSON message.

  • Reload the preview browser window.

In the preview response, you'll see Hello from branch preview as the JSON message.

You have now proved that the branch change stays on its preview URL. Production still serves its original response.

What does this comparison prove?

Cloudflare Worker Previews creates a separate deployment for the branch. The preview URL serves code from feature-preview-message.

Production remains tied to the default branch code. The side-by-side results expose that boundary before changes reach real traffic.

Seeing the same message twice?

  • Confirm that the two browser address bars contain different URLs.
  • Return to branch-live-url-worker in the Cloudflare dashboard from earlier.
  • Reopen the URL attached to the feature-preview-message preview deployment.
  • Reload the production window.
  • Reload the preview window.

Help me compare my production and preview Worker responses.

  • Keep both browser windows side by side with their address bars and JSON responses visible.

Your two deployments are visibly independent. Next, you'll test whether their configuration stays independent too.

Add a Preview-Only Variable

Your two URLs already prove that Cloudflare Workers can run branch code beside production. Production still serves its original response.

An environment variable lets each environment inject its own configuration at runtime. You will add one to the branch preview without changing production.

In this step, get ready to:
  • Update the branch source to read the optional PREVIEW_LABEL variable.
  • Add PREVIEW_LABEL to the feature-preview-message preview.
  • Compare the preview response with the unchanged production response.
Update the preview response

The branch Worker needs to read runtime configuration before the new variable can appear in its response. The variable stays optional so the handler can still respond when no label exists.

  • Return to the Git repository from earlier.
  • Switch to the feature-preview-message branch.
  • Locate the Worker source that currently returns Hello from branch preview.
  • Replace the existing branch Worker source with this code:
export default {
  async fetch(request, env) {
    // Add the preview label only when this environment provides it.
    return Response.json({
      message: "Hello from branch preview",
      ...(env.PREVIEW_LABEL ? { previewLabel: env.PREVIEW_LABEL } : {}),
    })
  },
}

What Does This Code Do?

  • The env parameter holds configuration injected into the Worker at runtime.
  • The conditional spread adds previewLabel only when PREVIEW_LABEL exists.
  • The Response.json() method turns the resulting object into the JSON response.
  • Save the Worker source.
  • Commit the source change on the feature-preview-message branch.
  • Push the branch using the same Git workflow from earlier.
  • Return to the Cloudflare dashboard from earlier.
  • Confirm the latest deployment for feature-preview-message completes successfully.
  • Reload the preview URL in your side-by-side browser view.

You will still see only message with the value Hello from branch preview. This confirms the optional configuration check works before the variable is added.

Branch Build Not Succeeding?

  • Compare every brace in your branch source with the reference code.
  • Confirm the commit belongs to feature-preview-message.
  • Confirm the latest branch deployment uses your newest commit.

Ask for help with the branch deployment error.

✔️ Awesome, I've got everything!

Your feature branch source can now include a label supplied by its runtime environment.

ⓧ I'd like to double check the full code

export default {
  async fetch(request, env) {
    // Add the preview label only when this environment provides it.
    return Response.json({
      message: "Hello from branch preview",
      ...(env.PREVIEW_LABEL ? { previewLabel: env.PREVIEW_LABEL } : {}),
    })
  },
}
Configure the preview variable

Each Preview has its own settings area in the Worker dashboard. Selecting the branch Preview before changing its settings keeps the new value scoped to that environment.

  • Switch back to the Cloudflare dashboard from earlier.
  • Select Workers & Pages from the left sidebar.
  • In Overview select branch-live-url-worker.
  • Select the environment breadcrumb beside branch-live-url-worker.
  • Choose the feature-preview-message Preview.
  • Confirm the breadcrumb shows feature-preview-message.
  • Select Settings.
  • Under Variables and Secrets select Add.

Why Check the Breadcrumb?

The breadcrumb identifies which environment receives your configuration change. With feature-preview-message selected the new variable belongs to that Preview.

  • Set Type to a plaintext variable.
  • Enter PREVIEW_LABEL in Variable name.
  • Enter branch-only in Value.
  • Select Deploy.
  • Confirm PREVIEW_LABEL appears in the selected Preview settings.

That is the configuration boundary in action. The branch Preview now owns a value that production does not have.

Compare preview and production

The Preview URL always points to the latest deployment for its branch. Reloading both pages now tests whether the code and configuration stayed inside the Preview.

Before you reload the two pages, which response do you expect to contain the new field?

  • Reload the feature-preview-message preview URL.
  • Reload the production URL.

The preview response now shows message as Hello from branch preview. It also shows previewLabel as branch-only.

Production still shows only message as Hello from production. Your production code and configuration remain unchanged.

Preview Label Missing?

  • Confirm the dashboard breadcrumb shows feature-preview-message.
  • Confirm the selected Preview lists PREVIEW_LABEL with the value branch-only.
  • Confirm the latest Preview deployment contains the updated branch source.

Help me find why the preview response is missing its label.

You have proved that a branch Preview can carry its own code and runtime configuration without changing production. That isolation gives you a safer place to test each change.

Your Preview now has its own response and its own configuration. Next up you will trace a request through the Preview's logs.

Inspect the Preview Logs

Your branch preview now serves branch-only through PREVIEW_LABEL. Production still serves its original response.

A live response proves the code ran. The observability view in Cloudflare Workers lets you trace that response back to the request that triggered it.

In this step, get ready to:
  • Generate a fresh request from the branch preview.
  • Open observability for the feature-preview-message preview.
  • Locate the invocation that matches your reload.
Generate a fresh preview request

An invocation log represents one Worker execution. A fresh reload gives you a recent event that is easy to distinguish from older traffic.

Before you reload, do you expect this request to appear with the production URL or the preview URL?

  • Switch back to the preview URL from earlier.
  • Reload the preview page with your browser's reload control.

You'll see the JSON response with Hello from branch preview as the message. You'll also see branch-only as the preview label.

What did the reload create?

The reload invokes the preview Worker once. Its invocation log records the request URL.

The log also records the time of the event. This evidence stays inside the preview's observability view.

Open the preview observability view

Each preview keeps its own observability data. This separation lets you inspect branch traffic without mixing it with production traffic.

  • Return to the Cloudflare dashboard from earlier.
  • Select Workers & Pages in the left navigation.
  • From Overview, select the branch-live-url-worker Worker.
  • Select the feature-preview-message preview from the Worker's preview list.
  • Select the preview's Observability tab.
  • Select Logs to view the preview invocations.

You'll see the log list for feature-preview-message. These entries belong to the branch preview.

Locate the exact request

The request URL separates your preview reload from other invocations. The most recent matching time ties the entry to the reload you just made.

Before you inspect the newest matching entry, what should its URL tell you about the environment that handled it?

  • Find the newest invocation whose request URL exactly matches the preview URL from earlier.
  • Select that invocation to inspect its details.
  • Compare its timestamp with the reload you just made.

You'll see that the request URL belongs to the branch preview. Its timestamp matches your recent reload.

You've now traced the branch response to its exact request log.

No matching preview request?

Preview logs can take a few seconds to arrive. A short delay here is normal.

  • Confirm that you selected the feature-preview-message preview.
  • Reload the preview URL again if the log list is empty.
  • Refresh the Logs view after a few seconds.

Help me find my preview request log.

What does this prove?

Observability connects the visible preview response to one recorded invocation. Inspecting that record does not change the deployment.

Your preview still uses PREVIEW_LABEL with the value branch-only. Production remains untouched.

Your preview response now has a matching record in its own logs. Next up, you'll remove the branch preview and confirm that production stays live.

Remove the Branch Preview

You have traced the feature-preview-message request through its own Cloudflare Workers logs. The preview has completed its review job.

Finished previews can clutter the branch list after testing ends. This step removes the stale deployment.

The Git branch stays in the repository. Production keeps serving the original response.

In this step, get ready to:
  • Delete the feature-preview-message preview deployment.
  • Confirm the former preview URL no longer serves the Worker.
  • Verify the Git branch and production Worker remain unchanged.
Delete the branch preview

A Worker Preview is an isolated runtime for one branch. Its settings belong to that runtime.

Deleting a live address can feel risky. This action targets only the feature-preview-message preview.

  • Select branch-live-url-worker in the breadcrumb above the observability view.
  • Use the environment breadcrumb next to the Worker name to display its previews.
  • Select feature-preview-message from the preview list.
  • Open the actions menu for the selected preview.
  • Choose the option that deletes the selected preview.
  • Confirm the deletion in the dialog.

You should see feature-preview-message disappear from the preview list.

Preview still listed?

  • Refresh the Worker view to update the preview list.
  • Select feature-preview-message again if another environment is active.

Help me remove this Worker Preview without affecting production.

Confirm the preview URL is gone

The former preview address is the direct test of whether its runtime still serves traffic.

Before you reload it, do you expect the branch JSON to appear again?

  • Switch back to the browser tab with the former preview URL.
  • Reload the preview URL.

You'll see that the former preview URL no longer serves the Worker. The branch response is gone.

You no longer see Hello from branch preview or branch-only.

Preview response still loading?

  • Hard refresh the former preview URL to bypass a cached response.
  • Check the preview list again for a lingering feature-preview-message entry.

Help me check why this deleted Worker Preview still responds.

Verify production and the branch remain

The preview deployment has its own lifecycle. Production remains a separate runtime under the same Worker.

Before you reload production, do you expect its response to include the preview message or label?

  • Switch back to the browser tab with the Cloudflare-provided production URL.
  • Reload the production URL.

You'll see JSON with the message Hello from production. No preview label appears.

  • Return to the Git repository from earlier.
  • Select feature-preview-message from the branch list.

You'll see that the branch still contains the Worker source for Hello from branch preview. It still reads the optional PREVIEW_LABEL value.

What remains after cleanup?

The feature-preview-message branch keeps its Worker source.

Production keeps its existing configuration. It still has no PREVIEW_LABEL variable.

Observability history retains the request you located before cleanup.

You have now proved the full branch-preview lifecycle from deployment through cleanup. Production kept serving throughout.

Secret mission

Audit Preview Isolation After Deletion

Turn your deleted preview into a deployment isolation audit. Prove its runtime is gone while its branch source remains. Confirm production is healthy. Recover the retained preview request as audit evidence.

Clean Up Your Resources

Clean Up Your Resources

Your branch preview is already deleted. The remaining Cloudflare Worker and repository cost nothing for this project's handful of requests. You can keep them for later or delete them entirely.

Resources you used:

  • Production Worker branch-live-url-worker. Its production URL serves Hello from production.
  • Git repository with the default production branch and the feature-preview-message branch.

Keep everything running

No action needed. Choose this if you want to keep the production Worker available or reuse the branch source later.

  • The production URL continues serving Hello from production.
  • The feature-preview-message branch remains available if you want to deploy another preview.
  • The deleted branch preview stays unavailable.

Pause - I'll come back to this later

There is no active branch preview or local process to pause. Choose this if you want to leave the remaining resources in their current state.

  • Leave branch-live-url-worker deployed so its production URL remains available.
  • Keep the repository so both branches are ready when you return.
  • Avoid creating another preview until you are ready to continue testing.

Delete - I don't want to use this again

Remove the production deployment and repository if you no longer need this project.

Deletion Is Permanent

Deleting the production Worker stops its live URL. Deleting the repository removes the default branch and the feature-preview-message branch.

  • Return to the Cloudflare dashboard from earlier.
  • Go to the resource page for branch-live-url-worker.
  • Use the page's permanent deletion control to delete branch-live-url-worker.
  • Reload the former production URL to confirm it no longer serves the Worker.
  • Switch back to the repository interface from earlier.
  • Confirm the default branch contains the Worker source that returns Hello from production.
  • Use the interface's permanent repository deletion control to delete the repository.
  • Confirm the repository no longer appears in your repository interface.

Nice Work!

Nice Work!

Excellent work! Your Cloudflare Worker now proves that production can stay stable while a branch receives an isolated live preview.

What you learned:

  • Deployed the Worker to a production URL. Verified its JSON response of Hello from production in your browser.
  • Used Worker Previews to give feature-preview-message its own URL. Compared that preview with production to prove each deployment served a different message.
  • Scoped preview configuration through PREVIEW_LABEL. Located the exact request in Cloudflare observability. Deleted the preview deployment while production stayed available.
  • Secret Mission: Took on an optional challenge to push your branch-preview skills further.

Ready to quiz yourself?