Case study · Cloudflare Workers
  • Cloudflare Workers

Cloudflare Workers for websites and the services behind them.

How Cloudflare Workers delivers websites and serverless APIs, illustrated by this Astro site’s static assets and Worker contact endpoint.

Conceptual illustration of a distributed cloud connecting website pages and serverless computing nodes.
Conceptual illustration · Cloudflare Workers
  • Cloudflare Workers
  • Static Assets
  • Astro
  • TypeScript
  • Turnstile
Understand the subject

What is Cloudflare Workers?

Cloudflare Workers is a platform for running server-side code without operating a dedicated application server. A Worker can respond to an HTTP request, call an external service, or provide a small API. Its runtime, configuration, and service connections determine what the application can do.

Workers Static Assets adds website files such as HTML, CSS, JavaScript, and images to the deployment. Cloudflare handles their distribution and caching, while routing configuration determines when a request should use Worker code. This allows a site to combine prebuilt public pages with dynamic endpoints.

Cloudflare Pages is a separate product for building and publishing websites. Pages Functions can add server-side behavior using the Workers runtime. The products overlap in what they can host, but their project configuration and deployment workflows differ. This Ascendo site’s configuration uses Workers with Static Assets.

Benefits & impact

Why it matters to the business.

Deliver content through a distributed network

Cloudflare handles serving and caching the uploaded static files. An Astro build can supply those files while leaving browser interactions and backend calls to their appropriate parts of the application.

Business impactPublic content can be delivered without assembling every page through a traditional application server. The finished experience still depends on asset sizes, browser code, integrations, and the visitor’s network.

Add backend behavior where it is needed

A Worker can handle an API route or call another service alongside the static website. Routing rules can reserve that code for the operations that need it instead of sending every asset request through application logic.

Business impactA business website can support forms and integrations with a focused backend. Authentication, validation, error handling, and service failures still need deliberate implementation.

Reduce the infrastructure a small site must operate

The platform runs the Worker and serves the uploaded assets. The application owner can concentrate on code, configuration, service connections, and deployment instead of maintaining a general-purpose web server for that part of the system.

Business impactThis can simplify an appropriate hosting setup. The work shifts toward maintaining the application, monitoring its behavior, controlling access, and understanding usage and provider dependencies.

Make the right choice

When to use it.

When it is a good fit

A content-focused website with a few dynamic endpoints
Astro service sites, portfolios, and resource pages can use prebuilt assets while a Worker handles a form or API operation. This site’s contact route is an example of that separation.
Small APIs and integrations using compatible services
Workers can fit request handling that communicates through supported APIs and bindings. Assess the required libraries, data access, execution limits, and downstream latency before choosing the implementation.
A team that needs a clear deployment workflow
The platform choice should fit how the team builds, previews, and publishes changes. For an existing Pages project, assess its current functions and configuration; for a Workers project, plan static assets and request routing explicitly.

Tradeoffs and responsibilities

Check runtime and resource requirements
A Worker has platform limits and a specific execution environment. An existing server application may need adaptation or a different hosting choice if its dependencies, runtime behavior, or processing requirements do not fit.
Plan domains, routes, and private configuration
Custom domains need to be associated with the correct application. API routing must agree with the website’s requests, and secret credentials belong in the server environment. Verify the deployed configuration as well as the local build.
Account for service dependencies and usage
An external email, storage, or database service can still fail or add latency and cost. Review current plan allowances and usage, then define useful error handling and monitoring for the complete interaction.
The problem

Keep public content straightforward to deliver while supporting real interactions.

A business website can have mostly shared public content and still need backend behavior. A contact form, for example, needs to validate a request and pass information to an appropriate service. Those responsibilities have different requirements from delivering a service page or image.

For this website, the approach is to generate the content with Astro, publish the output as static assets, and use a focused Cloudflare Worker route for the contact request. The hosting design follows those specific needs.

The approach

How I approached the work.

  1. Build the public content with Astro

    The site generates HTML pages and supporting files during the build. Those assets can be published together without requiring a content database to assemble each public page request.

  2. Route the dynamic operation explicitly

    The deployment configuration sends the contact endpoint through the Worker. The handler applies request validation and integrates with the required verification and email services. Page delivery and form processing therefore have clear responsibilities.

  3. Keep service credentials on the server side

    The contact handler reads its private service configuration from the execution environment. The generated public website does not need the email provider’s secret credentials in order to display the form.

  4. Check both the website and its backend behavior

    The project has build and link checks for the public output and separate checks for the contact and Worker behavior. A local preview helps review content, while deployment verification also needs to cover the actual domains, routes, bindings, and service configuration.

What this means for your project

Choose hosting around the work each request needs to do.

A content website can use static delivery for its pages and add focused serverless behavior for its interactions. My aim is a setup that is understandable to maintain, with clear routing, appropriate access to services, and verification of the complete visitor journey.

Let’s talk about your project.

Tell me what you’re building or what needs fixing.

Start a conversation
Ascendo / Let’s connect

Let’s build
something great.

Start a conversation. Directly with Nick.

I work directly with U.S.-based businesses on websites, applications, and technical consulting. This form is for prospective client projects. I’m not accepting vendor pitches, outsourcing proposals, or white-label partnership requests.

01 / Your project02 / Say hello
What can I help you with?

Choose what best describes your project.

Tell me a little about it.

What does your business need help with, and when would you like to get started?

Your details are used to respond to your inquiry. No account required.

Or email me directly: nlee@ascendosolutions.com