Cloudflare Deploy Status
Live Cloudflare Workers deployment status in the VS Code status bar. Quiet when nothing is
happening, informative while a build runs.
$(cloud) mymu v81 ↑3 up to date, 3 local commits not yet deployed
$(clock) mymu · queued a build is waiting
$(sync~spin) mymu · pnpm build 1:04
$(check) mymu · deployed
$(error) mymu · build failed red background, logs revealed
Click it for logs, a Worker picker, the dashboard, and build controls. Hover for the branch,
commit message, live version, and what has changed since.
What works without any setup
Nothing to configure. If you have run wrangler login, the extension reads Wrangler's own
credentials and shows:
- which Worker the file you are editing belongs to
- the live version number, when it deployed, and who deployed it
- how many local commits are ahead of what is live
What needs an API token
Workers Builds status and live build logs. Wrangler's OAuth token cannot read them — its
scopes cover Workers scripts but not Workers Builds, and the CLI has no builds command to
shell out to either. This is a limit of the credential, not a design choice.
Connect one from the tooltip, or run Cloudflare: Connect Cloudflare API Token. It needs:
| Permission |
Access |
| Workers Builds Configuration |
Read |
| Workers Scripts |
Read |
The token is stored encrypted in VS Code secret storage. CLOUDFLARE_API_TOKEN in the
environment is used automatically if set.
Build status only appears for Workers whose repository is connected to Workers Builds in the
Cloudflare dashboard. A Worker you deploy manually with wrangler deploy has no builds to
report, and the status bar will show its live version instead.
Worker detection
Finds wrangler.jsonc, wrangler.json and wrangler.toml anywhere in the workspace,
including nested apps/* and services/* layouts. Real configs are messier than the format
suggests, so detection handles:
- comments and trailing commas (a strict JSON parser fails on both)
- configs with no
main, which assets-only Workers legitimately omit
env.* blocks that rename the Worker — pastery-api deploying as pastery-api-production- configs with no
name, such as the adapter config SvelteKit generates, which are skipped
- Worker names that differ from their folder
With more than one Worker in the workspace, the status bar follows the file you are editing.
Pin one with Cloudflare: Select Worker.
Settings
| Setting |
Default |
Purpose |
cloudflareDeployStatus.accountId |
auto |
Override account detection |
cloudflareDeployStatus.pollInterval.idle |
60 |
Seconds between checks when nothing is running |
cloudflareDeployStatus.pollInterval.active |
5 |
Seconds between checks during a build |
cloudflareDeployStatus.pollOnlyWhenFocused |
true |
Pause polling when the window is in background |
cloudflareDeployStatus.showCommitsAhead |
true |
Show the commit drift counter |
cloudflareDeployStatus.alignment |
right |
Side of the status bar |
cloudflareDeployStatus.priority |
100 |
Ordering within that side |
cloudflareDeployStatus.ignore |
… |
Globs excluded when searching for configs |
Polling is adaptive: slow while idle, fast while a build runs, and it jumps to fast the moment
a push lands — the extension watches .git/refs/remotes, so a build is picked up in seconds
rather than on the next minute boundary.
Development
pnpm install
pnpm check # tsc --noEmit, the type gate
pnpm test # vitest
pnpm build # esbuild -> dist/extension.cjs
F5 launches an Extension Development Host.
The build UI can be exercised without a repo connected to Workers Builds by setting
cloudflareDeployStatus.dev.replay to success or fail, which replays a scripted build
through every state.
Contributing
Issues and pull requests are welcome. pnpm check and pnpm test are the gates; both run in CI
on every push.
Licence
MIT — see LICENSE.
Not an official Cloudflare product. Not affiliated with or endorsed by Cloudflare, Inc.
"Cloudflare", "Workers" and "Wrangler" are trademarks of Cloudflare, Inc.
