Cloudflare Workers
Edge runtime for APIs, webhooks, and small services.
- made by
- Cloudflare
Magic Ship is one shop in Vancouver, BC, working remotely with clients worldwide. We are not a partner, reseller, or certified vendor of Cloudflare - we just build with this.
What Cloudflare Workers is
Workers runs JavaScript and WebAssembly on Cloudflare's network using an isolate per request instead of a container. It has bindings to KV, R2 object storage, D1, Queues, and Durable Objects for coordinated state, and static assets deploy alongside the code.
How we use it
Workers is where we put webhook receivers, auth callbacks, and thin API edges in front of a model - code that has to answer fast and scale to zero between bursts. Queues absorb spiky webhook traffic so a slow downstream call never drops an event. Anything long-running or CPU-heavy stays off it and runs in a container instead.
Where it is the wrong choice
The runtime is not Node, so a dependency that wants native modules, the filesystem, or a long-lived TCP connection will not run, and per-request CPU limits rule out heavy batch work. A container on Fly.io or ECS is the fallback.
Service lines it turns up in
Related tools
More in Infrastructure and deploy
Other tools in the same service lines
Building something on Cloudflare Workers?
Send the problem rather than a job spec. You get an answer on scope, on fit, and on whetherCloudflare Workers is even the right call for it.
Start a projectCloudflare Workers and Cloudflare are trademarks of their respective owners, used here to say what we work with.