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 · 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.
01
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.
02
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.
03
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.
04
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.