Scope a Cloudflare Worker Deploy Token

Deploy two Workers and prove a token can change only one.

Introduction

30 Second Summary

The key that publishes one app often unlocks every app on the account. If it leaks, the smallest task can expose far more than expected.

In this project, you will deploy two small Cloudflare Workers that each return their own name. You will prove exactly where two API tokens stop by testing one-app deployment access and logs-only access.

What You'll Build

Picture two live URLs that make the permission boundary visible: one accepts its dedicated deploy token while the other refuses it.

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

Two live Worker URLs that each show their own app name in your browser.
A one-app deployment test where the first Worker updates while the second Worker refuses the same token.
A logs-only access test that streams requests from the first Worker while refusing a deployment attempt.
Secret Mission: Connect the single-Worker deploy token to a CI/CD workflow that updates only the intended app.

Are there any prerequisites?

You need a free Cloudflare account plus Node and npm on your computer. Comfort with basic terminal commands helps you focus on the permission tests.

Before We Start

A narrow API token needs an account where you can test its scope. Your local command-line tools provide the other half of that test.

In this step, you will prepare your Cloudflare account. You will open a terminal to confirm that Node.js plus npm are available.

In this step, get ready to:

Prepare a Cloudflare account.
Open a terminal window.
Verify Node.js with its npm package manager.

Prepare your Cloudflare account

The Cloudflare dashboard is where you manage account access later. A signed-in dashboard is all you need at this stage.

✔️ I already have an account

Visit the Cloudflare dashboard.
Sign in to your account.

You will see the Cloudflare dashboard after your account loads.

ⓧ I need to create an account

Visit the official Cloudflare sign-up page.
Enter your email address in the Email field.
Enter a strong password in the Password field.
Select Create Account.
Complete the email verification that Cloudflare sends you.
Return to the Cloudflare dashboard.

You will see the Cloudflare dashboard after verification succeeds.

Good, your Cloudflare dashboard is ready for the scoped-access work ahead.

Open a terminal window

A terminal gives you a place to run the local commands used throughout this project.

macOS

Press Cmd+Space to open Spotlight.
Type Terminal into the search field.
Press Return to launch Terminal.

Windows

Select Start from the taskbar.
Type Windows PowerShell into the search field.
Select Windows PowerShell from the results.

Your open prompt is ready for the local checks.

Keep the terminal window open for the next substep.

Verify Node.js and npm

Node.js runs JavaScript-based command-line tools. npm installs the packages those tools need.

Predict whether both tools are already installed.
Check both tools by running these commands:

node -v
npm -v

What do these commands check?

The node -v command prints the installed Node.js version.
The npm -v command prints the installed npm version.

✔️ I see two version numbers

Great, both version numbers confirm that Node.js plus npm are ready.

ⓧ One or both commands are missing

A missing command means Node.js or npm is unavailable in your current terminal session.

Download the LTS installer from the official Node.js download page.
Install the LTS release using the default options.

The installer ends with a completion screen when Node.js plus npm are ready.

Close your existing terminal window.
Repeat the platform steps above to open a fresh terminal.
Check the installation by running these commands:

node -v
npm -v

What confirms the installation?

Each command prints its installed version. Two version numbers confirm that the fresh terminal can find both tools.

Your Node.js installation is now ready for the command-line work in the next step.

Still missing a command?

A terminal opened before installation may still use an old command path. A fresh terminal usually loads the new path.

Restart your computer if a fresh terminal still cannot find one of the tools.

Help me diagnose the missing Node.js or npm command.

Your Cloudflare account plus local tools are ready. Next, you will install the Cloudflare CLI before building the two Workers.

Deploy Two Workers

A restricted deploy token only proves its value when two separate applications exist. Your first Worker becomes the allowed target. Your second Worker becomes the boundary test.

You will use Cloudflare Workers for both applications. Wrangler creates the local projects. It also deploys each response to a live URL.

In this step, get ready to:

Create two local Worker projects with Wrangler installed.
Deploy a different plain-text response from each project.
Open both live URLs to confirm the Workers are independent.

Create both Worker projects

Cloudflare's project generator is called C3. It creates the Worker files. It also installs Wrangler inside each project.

Move to your Desktop by running this command:

cd ~/Desktop

What does this command do?

This places your terminal on the Desktop. Both project folders will be easy to find there.

Create the first project by running this command:

npm create cloudflare@latest -- nextwork-deploy-key-one

What does this command do?

C3 creates the nextwork-deploy-key-one folder. It installs Wrangler as a project dependency.

The generator asks several questions before it creates the project. npm may also ask permission to install the generator package.

Accept the generator installation if npm requests permission.
Choose Hello World example when asked what you want to start with.
Choose Worker only when asked which template you want.
Choose JavaScript when asked which language you want.
Choose Yes when asked about Git version control.
Choose No when asked whether to deploy the application.

You will see a completion message for nextwork-deploy-key-one. The folder now contains src/index.js plus its Wrangler configuration.

Project generator failed?

Check that the terminal is still connected to the internet. A permissions error can also mean npm cannot write to its package directory.

Use a Node.js version manager if npm reports a permissions problem. Help me troubleshoot the first Cloudflare project setup.

Create the second project by running this command:

npm create cloudflare@latest -- nextwork-deploy-key-two

What does this command do?

C3 creates a separate nextwork-deploy-key-two folder. Its configuration names a different Worker.

Accept the generator installation if npm requests permission.
Choose Hello World example when asked what you want to start with.
Choose Worker only when asked which template you want.
Choose JavaScript when asked which language you want.
Choose Yes when asked about Git version control.
Choose No when asked whether to deploy the application.

You will see a completion message for nextwork-deploy-key-two. Both local Worker projects now exist on your Desktop.

This login lets Wrangler deploy from your computer. The restricted API tokens come later, so you do not paste a secret into the terminal here.

Start Wrangler's browser login from the first project by running these commands:

cd ~/Desktop/nextwork-deploy-key-one
npx wrangler login

How does Wrangler sign in?

Wrangler starts an OAuth login in your browser. Your terminal waits while you approve access through your Cloudflare account.

Sign in to the Cloudflare account from earlier if the browser requests it.
Select Allow on the authorization page.
Return to the terminal after the browser confirms authorization.

The terminal will confirm that Wrangler is logged in. Your local CLI can now manage Workers on the account.

Verify Wrangler's account connection by running this command:

npx wrangler whoami

What does this check prove?

The account details confirm that Wrangler can use the browser login. This separates authentication problems from deployment problems.

Your Wrangler setup is ready. The same local session can deploy both Worker projects.

Wrangler still logged out?

Check the browser for an unfinished authorization page. Complete that page before returning to the terminal.

If the browser did not open, copy the login URL from the terminal into your browser. Help me fix Wrangler authentication.

Deploy Worker One

A Worker's fetch() handler runs whenever its URL receives a request. The first handler returns a name that identifies the allowed deployment target.

Replace the generated first Worker code by running this command from the nextwork-deploy-key-one project:

node -e 'require("node:fs").writeFileSync("src/index.js", "export default {\n\tasync fetch() {\n\t\t// Return a distinct name so this deployment is easy to identify.\n\t\treturn new Response(\"Hello from Worker One\");\n\t},\n};\n", "utf8")'

What does this code do?

The file-writing command replaces the generated content in src/index.js.
The fetch() handler responds to every request sent to the Worker.
The response body identifies this deployment as Worker One.

Before you deploy, what response do you expect when the first live URL receives a request?

Deploy Worker One by running this command:

npx wrangler deploy

What does this deployment do?

Wrangler uploads src/index.js to Cloudflare. The deployment output includes the public workers.dev URL.

Copy the live URL printed by Wrangler.
Record the account-specific part of that URL here: <your-subdomain>.
Switch back to the browser Wrangler opened earlier.
Open a new browser tab.
Paste the Worker One URL into the address bar.
Press Enter.

You will see Hello from Worker One in the browser. Your first live endpoint is now responding with its own identity.

The live address follows this pattern: https://nextwork-deploy-key-one.<your-subdomain>.workers.dev.

Worker One not loading?

Compare the Worker name in Wrangler's deployment output with nextwork-deploy-key-one. A name mismatch points to the wrong project directory.

Run the deployment again from the first project if the upload failed. Help me troubleshoot the Worker One deployment.

✔️ Awesome, I've got everything!

Great. Worker One is deployed from nextwork-deploy-key-one and returns its expected response.

ⓧ I'd like to double check the full code

Your nextwork-deploy-key-one/src/index.js file should look exactly like this:

export default {
	async fetch() {
		// Return a distinct name so this deployment is easy to identify.
		return new Response("Hello from Worker One");
	},
};

Deploy Worker Two and verify both

The second project needs its own response before deployment. Its different name gives you a clear signal when you test access boundaries later.

Switch to the second project and replace its generated Worker code by running these commands:

cd ~/Desktop/nextwork-deploy-key-two
node -e 'require("node:fs").writeFileSync("src/index.js", "export default {\n\tasync fetch() {\n\t\t// Return a distinct name so this deployment is easy to identify.\n\t\treturn new Response(\"Hello from Worker Two\");\n\t},\n};\n", "utf8")'

What does this code do?

The first command moves your terminal into nextwork-deploy-key-two.
The file-writing command replaces the generated src/index.js content.
The response body identifies this deployment as Worker Two.

Before you deploy, which Worker name should appear when you visit the next live URL?

Deploy Worker Two by running this command:

npx wrangler deploy

What does this deployment do?

Wrangler uploads the second project's handler as a separate Worker. Its public URL uses the second project name.

Copy the Worker Two URL printed by Wrangler.
Return to the browser from earlier.
Open another browser tab.
Paste the Worker Two URL into the address bar.
Press Enter.

You will see Hello from Worker Two in the browser. Both applications are now live under separate names.

The second live address follows this pattern: https://nextwork-deploy-key-two.<your-subdomain>.workers.dev.

Worker Two shows the wrong text?

Confirm that your terminal path ends with nextwork-deploy-key-two. Deploying from the first folder updates Worker One instead.

Check that src/index.js contains the Worker Two response. Help me troubleshoot the Worker Two deployment.

✔️ Awesome, I've got everything!

Great. Worker Two is deployed from nextwork-deploy-key-two and returns its expected response.

ⓧ I'd like to double check the full code

Your nextwork-deploy-key-two/src/index.js file should look exactly like this:

export default {
	async fetch() {
		// Return a distinct name so this deployment is easy to identify.
		return new Response("Hello from Worker Two");
	},
};

Before the final check, which response belongs to each Worker URL?

Refresh the browser tab for https://nextwork-deploy-key-one.<your-subdomain>.workers.dev.
Confirm that the first tab shows Hello from Worker One.
Refresh the browser tab for https://nextwork-deploy-key-two.<your-subdomain>.workers.dev.
Confirm that the second tab shows Hello from Worker Two.

That is the foundation in place. Two local projects now map to two independent live Workers.

Your two deployment targets are ready. Next, you will create a token that can reach Worker One without gaining access to Worker Two.

Scope a Single-Worker Token

Your two Cloudflare Workers are live. Each one returns its own response.

Now you need a deployment credential for Worker One. A scoped API token gives automation its own access boundary.

An account-wide token would let one CI job change every Worker. You will use the Editor role at resource level so this token reaches only nextwork-deploy-key-one.

In this step, get ready to:

Open the account API token builder.
Limit the token to Worker One.
Store the token secret outside your project files.

Open the account token builder

Account API tokens act as service principals for automations such as CI jobs. The account-level token page lets you define their permissions before Cloudflare creates a secret.

Return to the Cloudflare dashboard in your browser.
Select the Cloudflare account that owns both Workers.
Open Manage Account from the dashboard navigation.
Select Account API Tokens.
Click Create Token.

You should see a token form with settings for its name and permission policies.

Can't access account tokens?

Creating an account-owned token requires permission to manage tokens for the selected account.

Confirm that you selected the account containing nextwork-deploy-key-one.
Ask an account Super Administrator to grant the required access if the token page remains unavailable.

Use this prompt if you need help: Help me find the Account API Tokens page in my Cloudflare dashboard.

Set one Worker as the entire scope

A token policy answers two questions. The role defines what the token can do while the scope defines where that power applies.

Enter NextWork Worker One Deploy Token in the Token name field.
Add a policy for Developer Platform access under Permission policies.
Set the policy's Role to Editor.
Set the policy's Scope to the resource level.
Choose Workers as the product.
Select nextwork-deploy-key-one as the resource.

The policy should name nextwork-deploy-key-one as its only Worker resource. nextwork-deploy-key-two should remain outside the included scope.

Why use the Editor role?

The Editor role can read or write Worker content.
The Editor role can update Worker settings.
The Editor role cannot create or delete resources.
Resource-level scope contains those permissions to one Worker.

Can't select Worker One?

The Worker selector only shows resources available in the account attached to the policy.

Confirm that the policy uses the account containing both deployed Workers.
Check the resource name for the exact spelling nextwork-deploy-key-one.
Keep the policy at resource level so the selector can target one Worker.

Use this prompt if the selector still looks wrong: Help me troubleshoot my single-Worker Cloudflare token scope.

Review and save the token

The token summary is your last safe checkpoint before a live secret exists. It exposes the permission boundary without exposing a credential.

Before you open the summary, predict which Worker will be the only named resource.

Click Continue to summary.
Confirm that the token name is NextWork Worker One Deploy Token.
Confirm that the Developer Platform role is Editor.
Confirm that the resource scope contains only nextwork-deploy-key-one.

The summary should show NextWork Worker One Deploy Token with the Editor role. Its resource scope should contain only nextwork-deploy-key-one.

The next screen reveals a live credential only once. A password manager or secure secret manager keeps that value outside both Worker projects.

Click Create Token.
Copy the token secret immediately.
Save the secret in a password manager or secure secret manager under NextWork Worker One Deploy Token.

Before you return to the token list, predict how Cloudflare will identify the credential you just created.

Return to the Account API Tokens page.

You should see NextWork Worker One Deploy Token listed as an active token.

That access boundary is now locked in. Your deploy token can reach Worker One without gaining access to Worker Two.

Next, you will edit Worker One and deploy the new response using only this restricted token.

Deploy With the Scoped Token

Your scoped API token can reach one Cloudflare Worker. It still needs to prove that it can ship a real change to that Worker.

An existing Wrangler login could make a successful deployment misleading. You will force Wrangler to prioritize CLOUDFLARE_API_TOKEN for this deployment.

In this step, get ready to:

Update the response from nextwork-deploy-key-one.
Deploy the first Worker through the scoped token.
Verify the updated response at the live Worker URL.

Change the first Worker response

A unique response marker connects the live page to this deployment. The \u2014 escape renders the required separator inside the Worker response.

Return to the local nextwork-deploy-key-one project from earlier.
Use your editor's project search to find Hello from Worker One.
Replace only that response text with Hello from Worker One \u2014 deployed with a scoped token.
Save the file that contains the first Worker's fetch handler.

Why add a response marker?

The new wording gives you visible proof that the scoped deployment reached the live Worker. A successful command followed by the old greeting would leave the result uncertain.

Deploy through the scoped token

Handling a deploy token deserves care. You will load the saved secret through the secure CLI method from the previous step.

Switch back to the terminal for the nextwork-deploy-key-one project.
Load your saved token secret into CLOUDFLARE_API_TOKEN using the secure terminal method from the token step.

Before you deploy, pause and predict which credential Wrangler will prioritize.

Deploy the saved first Worker through the scoped token by running this command:

npx wrangler deploy

What Does This Deploy Prove?

Wrangler prioritizes CLOUDFLARE_API_TOKEN over its existing authenticated profile.
The token authorizes the upload to nextwork-deploy-key-one through its single-Worker scope.
The deployment result connects the narrow permission to a real change on the live Worker.

Wrangler reports a successful deployment. You will also see the live URL for nextwork-deploy-key-one in the terminal output.

Deployment Refused?

Confirm that CLOUDFLARE_API_TOKEN is loaded in the same terminal session that runs Wrangler.

Check that the terminal is inside nextwork-deploy-key-one. A Worker name mismatch can look like a permissions problem.

Review the token summary if the refusal continues. The token must remain active with the Developer Platform role scoped to nextwork-deploy-key-one.

Help me diagnose why my scoped Cloudflare token cannot deploy the first Worker.

Verify the live response

The live endpoint confirms that Cloudflare accepted the deployment. It also proves that you tested the deployed Worker instead of a local copy.

Before you refresh, predict which part of the greeting changes if the scoped deployment reached the live Worker.

Switch back to the browser tab for https://nextwork-deploy-key-one.<your-subdomain>.workers.dev.
Refresh the page.

You will see the Worker One greeting followed by deployed with a scoped token. That visible change proves the narrow token successfully deployed its permitted Worker.

✔️ Awesome, I've got everything!

Your updated first Worker is live. The deployment used NextWork Worker One Deploy Token through CLOUDFLARE_API_TOKEN.

ⓧ I'd like to double check the full code

Your existing fetch handler structure stays unchanged. Compare its response string with this final value.

Confirm that the response string reads Hello from Worker One \u2014 deployed with a scoped token.
Confirm that Wrangler deployed from the nextwork-deploy-key-one project.
Confirm that the browser shows the updated response at https://nextwork-deploy-key-one.<your-subdomain>.workers.dev.

The scoped token can now deploy its intended Worker. Next, you will test where that permission stops.

Prove the Token Boundary

Your scoped API token has already deployed nextwork-deploy-key-one through Cloudflare Workers. That proves the credential can do its intended job.

A security boundary becomes meaningful when the same credential is refused outside its scope.

In this step, you will use Wrangler to target nextwork-deploy-key-two. You will capture the refusal as evidence that the token only opens one app.

In this step, get ready to:

Direct the first Worker's scoped token at the second Worker.
Capture the authorization refusal as boundary evidence.
Confirm the second Worker's live response remains unchanged.

Point the scoped token at Worker Two

The test only counts if Wrangler uses the scoped token. CLOUDFLARE_API_TOKEN takes priority over Wrangler's stored profiles.

Your token stays outside project files throughout this test, so you can capture the result without exposing the secret.

Return to the terminal you used for the successful Worker One deployment.
Supply the saved NextWork Worker One Deploy Token through CLOUDFLARE_API_TOKEN using the same secure method from the previous step.
Move into the local nextwork-deploy-key-two folder by running this command:

cd [[WORKER_TWO_PATH="path/to/nextwork-deploy-key-two"]]

What does this command do?

The command makes nextwork-deploy-key-two the terminal's current project. Wrangler uses that project's configuration to identify Worker Two as the deployment target.

Run the boundary test

Before you run the command, do you expect the token's successful Worker One deployment to grant it access here?

Attempt to deploy Worker Two by running this command:

npx wrangler deploy

The Refusal Is the Proof

You'll see Wrangler stop with an authorization or permission error before publishing Worker Two. The deploy token's Worker-level scope is blocking the request.

That refusal is the result you wanted. The same credential can deploy Worker One without gaining access to Worker Two.

Confirm the terminal is inside the nextwork-deploy-key-two project before treating the error as boundary evidence.
Keep the deployment command and its complete authorization error visible in the terminal.

Did Worker Two Deploy?

Stop the test before making another deployment.
Reapply NextWork Worker One Deploy Token through CLOUDFLARE_API_TOKEN without printing its value.
Return to the Cloudflare dashboard API Tokens page from earlier.
Select NextWork Worker One Deploy Token from the token list.
Confirm its resource scope lists only nextwork-deploy-key-one.

Help me investigate why the scoped token deployed Worker Two.

Confirm Worker Two stayed unchanged

A refused deployment should leave the live Worker on its existing version. The unchanged response gives you a second piece of evidence.

Before you refresh the second Worker's URL, do you expect its response to change?

Return to https://nextwork-deploy-key-two.<your-subdomain>.workers.dev in your browser.
Refresh the page.

You'll still see Hello from Worker Two. No update reached the second Worker because the scoped token was unauthorized.

You now have concrete evidence that the deploy credential can update one Worker while remaining blocked from another. Next, you will test a read-only token that can observe logs without shipping code.

Tail Logs With Read-Only Access

Your first scoped API token proved that one credential can deploy one Cloudflare Worker. The refused deployment showed that the second Worker stays outside its reach.

This step narrows the role as well as the resource scope. You will give Wrangler access to Worker One's logs without giving it permission to deploy.

In this step, get ready to:

Create a logs token scoped to Worker One.
Observe a live request through the logs token.
Test the logs token against a deployment.

Create a logs-only token

Cloudflare's Metadata Read-Only role exposes observability data without exposing source code. A resource scope limits that visibility to one Worker.

Creating a token reveals a secret that you can copy only once. You will store it outside both Worker projects so it never enters your source files.

Return to the Cloudflare dashboard API Tokens page from earlier.
Select Create Token.
Choose the custom token option.
Enter NextWork Worker One Logs Token as the token name.
Add a permission policy for the Developer Platform.
Choose Metadata Read-Only as the role.
Set the resource scope to the specific Worker named nextwork-deploy-key-one.

The token summary is your chance to catch an overly broad scope before the secret exists. It should name one role and one Worker.

Continue to the token summary.
Confirm that the summary shows Metadata Read-Only for only nextwork-deploy-key-one.
Select Create Token.
Copy the token secret to a secure place outside both Worker projects.

Good progress. Your second token can now observe Worker One without receiving deployment access.

What Does Metadata Read-Only Allow?

Metadata Read-Only provides access to settings plus observability data such as metrics, logs, or traces. It does not provide access to Worker source code.

The Worker-level scope applies that role only to nextwork-deploy-key-one. This gives a debugging tool the smallest useful view.

Can't Find the Scoped Role?

Check that you are creating the token in the same Cloudflare account that owns nextwork-deploy-key-one.

Use the Developer Platform policy controls. Choose Metadata Read-Only before limiting the policy to the Worker resource.

Help me configure a Worker-scoped Metadata Read-Only token.

Tail Worker One's logs

A real-time log tail waits for requests to reach the deployed Worker. Loading the new token through CLOUDFLARE_API_TOKEN makes Wrangler use that credential instead of your saved login profile.

Switch back to the terminal for your local nextwork-deploy-key-one project from earlier.

macOS

Load the logs token into the current shell by replacing the placeholder in this command:

export CLOUDFLARE_API_TOKEN="your-api-token-here"

What Does This Command Do?

This sets CLOUDFLARE_API_TOKEN for the current shell session. Wrangler gives this value priority over stored login credentials.

Windows

Load the logs token into the current PowerShell session by replacing the placeholder in this command:

$env:CLOUDFLARE_API_TOKEN="your-api-token-here"

What Does This Command Do?

This sets CLOUDFLARE_API_TOKEN for the current PowerShell session. Wrangler gives this value priority over stored login credentials.

Linux

Load the logs token into the current shell by replacing the placeholder in this command:

export CLOUDFLARE_API_TOKEN="your-api-token-here"

What Does This Command Do?

This sets CLOUDFLARE_API_TOKEN for the current shell session. Wrangler gives this value priority over stored login credentials.

Start a live log tail for Worker One by running this command:

npx wrangler tail nextwork-deploy-key-one

What Does This Command Do?

The tail command opens a live stream for requests handled by nextwork-deploy-key-one. The command keeps running while it waits for traffic.

Before you trigger a request, which Worker do you expect this token to reveal in the tail output?

Open https://nextwork-deploy-key-one.<your-subdomain>.workers.dev in a new browser tab.

You will see a request for nextwork-deploy-key-one in the terminal. That request proves the read-only token can access Worker One's live logs.

Stop the tail by pressing Ctrl+C in the terminal.

No Request in the Tail?

Check that the tail command is still running when you load Worker One's URL. Refresh the browser once if the first request happened before the tail connected.

If Wrangler reports an authorization problem, confirm that the token summary scopes Metadata Read-Only to nextwork-deploy-key-one.

Help me troubleshoot an empty Wrangler tail.

Test the logs token against a deployment

The logs token has now observed a real request. The final check tests whether the same credential can perform a write operation.

Before you run the deployment, do you think the credential that tailed the logs can also ship code?

Attempt a deployment from the local nextwork-deploy-key-one project by running this command:

npx wrangler deploy

This Refusal Is the Result

Wrangler returns an authorization error because Metadata Read-Only cannot deploy Worker content. This expected failure proves that log access does not become write access.

Refresh https://nextwork-deploy-key-one.<your-subdomain>.workers.dev in your browser.

You will still see the response beginning Hello from Worker One and ending deployed with a scoped token. The refused command did not replace the live Worker.

Did the Deployment Succeed?

A successful deployment means Wrangler used a credential with write access. Confirm that CLOUDFLARE_API_TOKEN contains the secret for NextWork Worker One Logs Token.

Review the token summary again. It must show Metadata Read-Only with a resource scope limited to nextwork-deploy-key-one.

Help me identify why my read-only token deployed a Worker.

That closes the proof. Your logs token can observe requests to one Worker while every deployment remains outside its authority.

Secret mission

Build an Access Evidence Matrix

Turn your four captured tests into an access evidence matrix. Use it to assign each token to one workflow. Keep both secret values out of the evidence.

Clean Up Your Resources

The two Cloudflare Workers stay on the free plan, so this project has no ongoing cost. Decide whether to keep the project available, remove its active tokens, or delete every resource.

Resources you used:

Deployed nextwork-deploy-key-one Worker with its live URL.
Deployed nextwork-deploy-key-two Worker with its live URL.
Active Cloudflare API token named NextWork Worker One Deploy Token with access limited to nextwork-deploy-key-one.
Active Cloudflare API token named NextWork Worker One Logs Token with read-only log-tail access to nextwork-deploy-key-one.
Local nextwork-deploy-key-one Worker project folder.
Local nextwork-deploy-key-two Worker project folder.

Keep everything running

No action needed. Choose this only if you are actively continuing the authorization tests.

Keep nextwork-deploy-key-one deployed so its live URL remains available.
Keep nextwork-deploy-key-two deployed so its live URL remains available.
Keep NextWork Worker One Deploy Token active only while repeating the scoped deployment tests.
Keep NextWork Worker One Logs Token active only while repeating the log-tail tests.
Continue storing both token secrets securely outside the local Worker project files.
Delete both API tokens as soon as you finish testing.

Pause - I'll come back to this later

Remove the active tokens while preserving the deployed Workers and local folders. Choose this if you want to return later without leaving credentials active.

Return to the Cloudflare dashboard's API Tokens page from earlier.
Locate NextWork Worker One Deploy Token.
Use the deletion control associated with that token.
Locate NextWork Worker One Logs Token.
Use the deletion control associated with that token.
Confirm that both token names are absent from the API Tokens page.

Good call. The two credentials are now gone, while the deployed Workers and local projects remain ready for later.

Delete - I don't want to use this again

Remove all project resources to close the authorization test completely. This permanently removes both tokens, both deployed Workers, and both local project folders.

Delete the API tokens:

Return to the Cloudflare dashboard's API Tokens page from earlier.
Locate NextWork Worker One Deploy Token.
Use the deletion control associated with that token.
Locate NextWork Worker One Logs Token.
Use the deletion control associated with that token.
Confirm that both token names are absent from the API Tokens page.

Both credentials are now inactive. They can no longer deploy a Worker or read its logs.

Delete the deployed Workers:

Return to the Worker list in the Cloudflare dashboard.
Open nextwork-deploy-key-one from the Worker list.
Use the deletion control available for that Worker.
Complete the confirmation shown by Cloudflare.
Open nextwork-deploy-key-two from the Worker list.
Use the deletion control available for that Worker.
Complete the confirmation shown by Cloudflare.
Confirm that neither Worker appears in the Worker list.

That's the cloud cleanup complete. Neither Worker can serve its project response now.

Delete the local project folders:

Go to the location where you saved the Worker projects in your computer's file browser.
Delete the nextwork-deploy-key-one folder.
Delete the nextwork-deploy-key-two folder.
Confirm that neither folder appears in that location.

Your tokens, deployments, and local project files are now removed.

Nice Work!

You did it! Your two Cloudflare Workers now demonstrate how scoped API tokens contain deployment access.

You've learned how to:

Deployed two live Workers from nextwork-deploy-key-one plus nextwork-deploy-key-two. Confirmed that each Worker returned its own response from a live URL.
Created a Worker-scoped deploy token for nextwork-deploy-key-one. Proved its authorization boundary when the same token was refused on nextwork-deploy-key-two.
Used a read-only logs token to tail live requests for nextwork-deploy-key-one. Confirmed its read-only boundary when a deployment attempt was refused.
Secret Mission: Applied the same least-privilege thinking in an optional project extension.

Ready to quiz yourself?