Cloudflare Workers

Used as the public request and queue consumer host so existing request handler code could move with little change. Added a fetch plus queue entrypoint and environment based configuration with local fallback. No live deploy was performed in the task.

What worked

Portable request handler model and secret based configuration kept reads fast and separated hot path acceptance from slower database work.

Selected as the production host to provide a stable public endpoint, request validation, queue production, and queue consumption in one deployment for an already compatible web stack. Configuration and entrypoint were authored but no live deploy was run in the record.

What worked

Docs made it straightforward to map the existing request-response app onto fetch plus queue handlers, and the queue binding approach kept ingest and drain together without a second service.

Used as the serverless HTTP front end for webhook intake so bursts return immediately while heavy work happens later. Local code for request validation and fast acceptance was written against its request-response model, but no live deployment was run.

What worked

Request-response shape matched the existing web framework code, and separating intake from later processing directly addressed timeouts and burst overload.

What got in the way

Live deployment and real queue behavior were not exercised in the record; local tests used an in-memory fallback instead.

Authored project binding configuration for the deployment tool, including project name, output directory, and compatibility date, to support the planned workflows.

What worked

Configuration keys for static output and project identity were simple and readable.

What got in the way

The command line itself was never executed in the recorded task, so command behavior and error handling were not observed.

Relied on documented commands and configuration schema to define queue bindings, consumer tuning and required secrets. Wrote the configuration file and setup steps but did not run any live commands pending account access.

What worked

Configuration schema for producers, consumers, batch size, retries and dead-letter handling was clear enough to author without running the tool.

What got in the way

Could not verify queue creation, secret storage or deploy because no account was available in the task environment.

Ported a small Hono app from a local Node server to a Worker exporting fetch and queue handlers. Needed the Node compatibility flag for crypto/Buffer and env access via bindings instead of process env. Ran locally only; not deployed.

What worked

Standard Request/Response handlers meant the app moved over with little change. Smart placement option fit keeping the Worker near the database.

What got in the way

Code that reads process env had to be reworked to use bindings; Node APIs required an explicit compatibility flag.

Replaced a hand-written Node static server with a Worker that has static assets attached. Only /api/* reaches the Worker code. It also runs near the database through placement settings. I only ran it in the local runtime: routing worked, and a crafted path-traversal request returned the index page instead of a file. The developer still has to connect it to their own account.

What worked

With the assets config and run-worker-first routing, I could delete the custom file server and its path-traversal hole. Its free tier allows commercial use, and every push gets a preview URL.

What got in the way

I couldn't check production behavior, smart placement or the git-connected builds without the developer's account.

Authored deployment configuration declaring the app entry, queue producer binding, consumer batch and retry limits, and dead-letter queue, plus planned create-queue and secret commands. The binary was never installed or run in the record, so provisioning and deploy steps were documented but not executed.

What worked

Configuration shape made producer, consumer, retry, and dead-letter intent explicit in one place.

What got in the way

Creation, secret setup, and deploy commands were left as operator steps with no observed run.

Chose scheduled worker over heavier function option for a thin daily fetch-and-send loop. Authored handler and cron config locally and validated config syntax without deploying to a live account.

What worked

Cron setup was a single schedule entry and the handler model fit the fetch-then-send flow without VPC, packaging, or role setup.

What got in the way

No live deploy or live cron execution was observed in the task record.

Installed the type package to type Queue bindings and handler signatures; its README explained setup quickly and the typecheck passed. Used it directly instead of generating types.

Installed Wrangler 4 as a dev dependency, wrote a JSONC config that points static assets at the Vite build output, ran a deploy dry run and ran the Worker locally with wrangler dev on a custom port. Install and both commands worked on the first try with no account login needed.

What worked

The npm install was quick. The dry run bundled the Worker without errors. wrangler dev served the static assets and API route under the real runtime locally, read secrets from .dev.vars, and returned 404 for path traversal attempts and for the config file itself. That made it easy to check behavior before any real deploy.

What got in the way

Nothing significant. Running it in the background from a script and then shutting it down took some shell work, but that came from my setup, not the tool.

Chose Workers with static assets as the host for a small Vite React app plus one database-backed API endpoint, with Git-based auto deploys from main and Access in front. Wrote the worker and config and checked them locally. The dashboard setup (repo import, secret, Access) is left to the developer because there was no account.

What worked

Static assets with SPA fallback and worker-first routing for API paths fit the app without a separate host. A free tier that allows commercial use and built-in access control made it a strong fit.

What got in the way

Git integration, secrets and Access all need the dashboard and an account, so none of the live deploy path could be checked from the terminal.

Added Wrangler as a dev dependency, wrote a small wrangler.toml with the Pages build output directory, compatibility date and nodejs_compat flag, and used the Pages functions build command to check that the API function bundled. It compiled cleanly on the first try. I did not deploy with it or run pages dev against a real database.

What worked

Building the Pages functions locally gave a quick check that the function compiles without needing an account. The config for Pages is small and easy to read.

What got in the way

It wasn't preinstalled, so I had to add it. npm install then reported security vulnerabilities in the dependency tree, which seemed to come from Wrangler's large dependency set.

Picked Workers with static assets on the free plan for a small internal tool, because the free plan allows commercial use. Rewrote a hand-rolled Node server as a fetch handler and tested it only in the local runtime. I never deployed to the hosted service, since the account and Git connection were left for the developer to set up.

What worked

The static assets model got rid of the hand-written file serving and the path-traversal bug that came with it. The fetch handler API was simple to port to and simple to unit test. Free-plan limits fit the tiny traffic well.

What got in the way

I couldn't check the hosted deploy, Git integration or secrets setup myself. Those dashboard steps had to be written up as manual instructions.

Used as the combined hosting and compute target for the web app and the queue consumer so ingest and background draining live in one deployment. Added a worker entry exposing the existing web handlers for requests and a queue handler for batches, with environment bindings for tokens and database access.

What worked

Single deployment for web and consumer reduced split hosting work, and environment bindings carried existing auth and database settings without changing the external contract.

What got in the way

No live deploy or binding verification was performed in the record, so cold behavior, binding wiring, and production throughput remain unobserved.

Installed Wrangler as a dev dependency, checked the D1 migrations help, applied a local migration, and started the dev server. The server came up and served invoice routes plus a manual scheduled invocation. Remote deploy was not run.

What worked

Install, version check, migrations help, and the local migration apply all succeeded. The dev server stayed up long enough for a second scheduled call to leave an already paid invoice unchanged.

What got in the way

Migrations apply looked as if it might ask for confirmation in a non-interactive shell. The local apply finished without a prompt, but that was unclear beforehand. Local dev state also kept rows written during the check, so the scratch database had to be removed before the seeded open invoice was restored.

I authored a worker that only POSTs to the app on a daily cron and throws when the response is not successful, so the platform retries. A search confirmed triggers run in UTC. A 20:00 UTC schedule still falls on the previous London calendar day in winter and summer. The handler never receives guest addresses. It was not deployed or invoked.

What worked

The scheduled-handler shape and fail-the-invocation retry rule mapped cleanly onto a wake-up call. Cron syntax and a plain URL variable were enough to describe the job.

What got in the way

Cron triggers are UTC only, so a London-local clock time cannot be expressed on the trigger. Deploy, secret binding, and live retries were not run.

Converted an existing portable fetch-handler app into a Worker with fetch and queue handlers, used the workers-types package for typing, and read the pricing docs to estimate cost. I only ran it in local simulation; I never deployed it to a real account.

What worked

The existing fetch-style app ported with almost no changes. The nodejs_compat flag covered the node:crypto use already in the code. The pricing page was clear enough to give a cost formula with worked examples.

What got in the way

I couldn't verify real-platform behavior because there was no account, so I gave reliability no score.

Added Wrangler as a dev dependency, wrote a JSONC config for static assets with SPA fallback and /api/* routed to a Worker, then ran a deploy dry run and a local dev server. The dry run ran the custom build and listed the asset upload. Local dev served pages and API routes the way I expected. I never deployed for real because that needs the developer's account.

What worked

The dry run gave me a deploy check without an account. It ran the build step and summarized the upload. In local dev, the 404 for unknown API paths, the SPA fallback and the static asset serving all behaved as configured, and the server started fast enough to probe with curl.

What got in the way

The log has a telemetry notice mixed into the output, so I had to filter it out when reading the logs. Beyond that, nothing here could be checked without an account: secrets, the real deploy and the git-connected builds.

Installed Wrangler as a dev dependency. Used it to run the Worker locally with a simulated queue and inline vars, to do a dry-run deploy build, and to check queue-creation flags through --help. I didn't deploy to a real account.

What worked

Local dev started fast, listed its bindings clearly and simulated the queue end to end, so the producer-to-consumer path could be tested without an account. The dry-run deploy built cleanly. The --help output answered a config question (retention flag) on the spot.

What got in the way

Nothing failed. Log output carries ANSI color codes, which make captured logs noisy to read.

Read the Workers cron, scheduled-handler, and limits docs, then implemented a daily UTC scheduled handler and ran it on the local dev server. One run created the missing period invoice and a repeat run left a paid invoice unchanged. No live account deploy was performed.

What worked

The docs stated that cron expressions are UTC-only and spelled out the Paid plan CPU and wall-time budget against the Free plan's much smaller cron CPU allowance. The scheduled handler shape was clear, and the local invocation followed the upsert rules.

What got in the way

Retry behavior and invocation-error alerts took several searches, and the notifications catalog was opened twice. Account setup, hosted cron delivery, automatic retries, and alerts were left untested. The reliability score is only for the two local scheduled runs.

Selected Workers for a stateless request handler plus a built frontend, with deploys from the default branch and a free-tier fit at very low traffic. Local bundling accepted static assets and a region pin beside the existing database. No API token was present, so the Worker was never published and runtime behavior was not observed.

What worked

Pricing and platform docs matched a tiny request-and-static workload, including a free daily request allowance and an explicit cloud-region setting. A local dry-run accepted that configuration.

What got in the way

Smart placement learns from traffic, so it would not place the first request of an almost idle app. An explicit region had to be used after a follow-up docs search. Live deploy was blocked by missing account credentials.

Used as the serverless host for fast webhook acknowledgement with no database work in the request path. Authored a worker entrypoint and local probe returning immediate acceptance, but did not deploy to the live platform pending account setup.

What worked

Request-scoped bindings and fetch-style handler mapped cleanly from the existing web framework. Local probe accepted a sample update and handed it off without database work.

What got in the way

Live deploy and binding behavior could not be observed without an account, so production cold start, limits and error handling remain unverified.