(Python) CloudFlare Workers Disappointed Me a Bit | ✉️ #77

Illustrated banner titled “MKDEV Dispatch #77” with a person holding a cat and text: “(Python) Cloudflare Workers disappointed me a bit.” The background features paper plane icons and an orange section.
Last updated: | Published:

Hey! 👋

The other day I tried CloudFlare Workers for my personal project. I wanted to use Python, because when Ruby is not available, then Python is my fallback language. CloudFlare Workers do have Python support, but it is in beta. Still, I tried.

First, you can’t install any packages today. My worker was meant to be a thin proxy to OpenAI APIs, and not being able to use OpenAI Python SDK felt weird. Still, I made it work, as making a few HTTP calls is not too hard.

Second, it was slow. Well, slower than JavaScript version, which I ended up deploying later on.

And finally, it was just unreliable. Requests would get stuck or timeout without any clear reason. Where it was supposed to wait for the request to finish, it would not.

So then, I moved my service to AWS Lambda. And it was working like a charm. I could use any libraries, and I could use Ruby. There were no issues with timeouts and everything just worked (tm).

Still, I kept the CloudFlare worker around, but now it was merely proxying requests to my Lambda. The reason is simple: CloudFlare’s abstraction to routing edge traffic just feels effortless.

I could do this setup in minutes:

  1. Root domain example.com servers static website deployed via CloudFlare Pages

    (CloudFlare Pages picks up any change in GitHub repository and builds static website using Hugo;)

  2. Sub-path example.com/api invokes CloudFlare Worker, which then proxies request to Lambda, waits for a response and returns it to the user;

  3. Sub-path example.com/support redirects user to another domain, hosted by a support SaaS I use;

It gets better: there is a set of email functionality with similarly neat and easy to setup features. For example, I could just configure forwarding of emails from kirill@example.com to my personal email, and I could setup DKIM and DMARC etc in the same place, as CloudFlare handles my DNS.

All of this with speed, caching, huge network of edge nodes etc etc. All of this, for a personal project, for free - but if it grows, I will have to pay. CloudFlare has fantastic Free Tier.

But this Free Tier could not satisfy my app-hosting needs. CloudFlare Workers seem to integrate easily with many other CloudFlare services, for Key Value, Object Storage and so on - but my first, so far, experience trying to use it for running a tiny micro-service was not successful. Runtime duration limitation, quirky Python support and lack of “use libraries” feature in other runtimes and many other small things make it a suboptimal choice for running a “real” app.

So I stick to Lambda, for person projects anyway. But I move more and more of other “edge” processing to CloudFlare. For this project, CloudFlare is doing everything except executing my business logic (as small as it is). Perhaps eventually, it will take over running my code as well. I am curious to learn about real setups leveraging workers for actual apps, and not just as a tiny edge functions.

But as of today, (Python) CloudFlare Workers disappointed me a bit.


What We've Shared

  • DevOps Accents, episode 63: Data Science 2.0 with Suzanne El-Moursi from Brighthive. Data Science 2.0 is the shift from dashboards to decision workflows. Suzanne El-Moursi shows how teams can go beyond “reports nobody trusts” to agentic, governed analytics, using a pragmatic stack (infrastructure → composable tools → governance) so insight can flow from ingestion through modeling, validation, and visualization without the usual stalls. We focus on how the data scientist role evolves from dashboard factory to orchestration and stewardship so the right decision happens at the right time.

  • A snippet of the previous episode in video form: The State of Agentic Systems and Dapr in 2025.

  • GenAI Security Risks for Product Managers: The third article of this series by Paul Larsen warns product managers about the major cybersecurity risks of GenAI—like data leaks, prompt jailbreaks, and injection attacks—and offers practical steps to keep AI use productive without endangering company data or operations.


What We've Discovered


The 78th mkdev dispatch will arrive on Friday, September 19th. See you next time!