How GitHub Actions Can Deploy a Cloudflare Worker in Under an Hour

A Cloudflare Worker deployed in under an hour isn’t just a technical milestone—it’s proof that automation can outpace manual workflows, even for beginners. After burning three precious minutes on an authentication error, I finally shipped a functional deployment in 47 minutes. The lesson wasn’t in the code, but in the checklist I almost missed.

The Minimal Setup That Makes It Happen

The project required just three files: a JavaScript handler, a configuration file, and a GitHub Actions workflow. No bloated dependencies, no complex dependencies—just the essentials to push code to the edge and forget it.

The Worker Code

The Worker itself is a simple fetch handler that returns a JSON response. The logic lives in src/index.js:

export default {
  async fetch(request, env, ctx) {
    return Response.json({
      message: "Hello from the edge",
      region: request.cf?.colo ?? "unknown",
    });
  },
};

The file is lightweight, relying only on Cloudflare’s global network to handle requests. No server management, no regional setup—just a single function executed at the edge.

The Configuration File

Next, the wrangler.toml file defines the Worker’s identity and compatibility date:

name = "hello-edge"
main = "src/index.js"
compatibility_date = "2025-01-01"

This file acts as the bridge between the code and Cloudflare’s deployment system. It ensures the Worker runs on the specified runtime and remains compatible with future updates.

The GitHub Actions Workflow

The final piece is the automation pipeline. The .github/workflows/deploy.yml file triggers on pushes to the main branch:

name: Deploy Worker

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

This workflow checks out the repository, authenticates with Cloudflare, and deploys the Worker—all without manual intervention. Push to main, and the deployment is live within seconds.

The Hidden Checkbox That Cost Three Minutes

The first deployment failed with an authentication error: Authentication error [code: 10000]. I double-checked the API token, rotated it, and even verified the secret name—yet the error persisted. After 11 seconds of failure, I was stuck questioning reality.

The root cause? A misconfigured API token. I had selected the "Read All Resources" template, which grants read-only access across all Cloudflare services. Wrangler, however, needs write permissions to deploy Workers. Switching to the "Edit Cloudflare Workers" template—with its preconfigured write scope—fixed the issue instantly.

The error message didn’t help. Code 10000 is Cloudflare’s generic authentication failure, offering no clues about missing permissions. The fix was a single checkbox away, but that checkbox wasn’t in the error log—it was in the token creation screen.

Why CI/CD Beats Manual Deployments

Cloudflare’s dashboard offers a "Connect to Git" feature that automates deployments without writing a single line of YAML. For a one-off project, this is the fastest path. But for long-term projects, the trade-off between speed and control matters.

A GitHub Actions workflow isn’t just a deployment tool—it’s a foundation for future enhancements. Need to run tests before deploying? Add a step. Want to deploy to a staging environment first? Configure it. Need to post failure alerts to Slack? Integrate it.

The dashboard’s automation is a black box. The workflow file, however, is readable, version-controlled, and extendable. For learning projects, the extra 15 minutes of setup pays off when the next 100 commits deploy themselves.

The First Deploy and What It Taught Me

The deployment log read:

Total Upload: 0.42 KiB / gzip: 0.30 KiB
Uploaded hello-edge (1.15 sec)
Deployed hello-edge triggers (0.32 sec)

Clicking the URL loaded in 38 milliseconds from a Singapore data center. The Worker was live, globally distributed, and managed entirely by code I wrote 47 minutes earlier. The real victory wasn’t the Worker—it was the pipeline.

Pushing to main and watching the green check appear on GitHub, knowing the Worker was deployed without touching the dashboard, was the actual feature. The Worker itself was just a placeholder for the automation that made it possible.

Three Lessons for First-Time Deployers

Before diving into Cloudflare Workers, keep these principles in mind:

• Use the prebuilt "Edit Cloudflare Workers" API token template. Custom tokens or overly permissive ones like "Read All Resources" will trigger error code 10000. The template ensures wrangler has exactly what it needs.

• Set up the CI/CD pipeline before writing interesting code. A basic Worker behind a working automation pipeline is more valuable than a sophisticated one deployed manually. The pipeline scales; manual deployments don’t.

• Treat the API token like a password, not the account ID. The account ID is visible in the dashboard URL and isn’t sensitive. The API token, however, grants access to your entire Cloudflare account. Rotate it frequently, store it securely, and never log it.

What’s Next: Preview Deployments and Automation

The next step is to add preview deployments for pull requests. Every PR would automatically generate a unique *.workers.dev URL, allowing for testing before merging. The solution involves adding a second job in the workflow, triggered by pull_request events, and a bot to post the preview URL on the PR.

For those who’ve deployed Workers via CI/CD, what does your workflow look like? And what’s the one piece of advice you wish you’d known before setting up your first pipeline?