Building a Freelance Platform on Cloudflare Workers: The Good, The Bad, and The Pyodide

A developer built aiomniu, a freelance marketplace for AI and tech projects, using Cloudflare Workers with Pyodide for Python backend support. The stack includes FastAPI, Next.js 15, and Cloudflare D1 database, leveraging edge distribution and a generous free tier. The developer highlights challenges with Pyodide's limitations, such as the lack of thread pools and the requirement for async route handlers.

Six months ago I sat down to build aiomniu https://aiomniu.top — a freelance marketplace for AI and tech projects. The constraints were simple: zero budget, fast load times, and a backend I could write in Python. The stack I ended up with: Cloudflare Workers + Pyodide + FastAPI on the backend, Next.js 15 + OpenNext on the frontend, and Cloudflare D1 for the database. This is what I learned — the parts that worked, the parts that broke, and the parts I'm still not sure were worth it. I did the obvious comparison: | Platform | Cost for MVP | Cold Start | Python Support | |---|---|---|---| | Vercel | Free but DB adds up | Fast | Serverless functions only | | AWS Lambda | Cheap but complex | 200ms-1s | Good via Layers | | Railway | $5/mo | Fast | Native | | Cloudflare Workers | Free tier is generous | Sub-ms | Pyodide Python→Wasm | For me it came down to two things: free tier and edge distribution . Cloudflare Workers gives you 100k requests/day at no cost, and your code runs in 330+ locations. Hard to beat for a bootstrap budget. The catch is that Python on Workers runs through Pyodide — CPython compiled to WebAssembly. It's not serverless Python in the traditional sense. It's Python that has been through a compiler, stuffed into a Wasm binary, and told to behave. Most of the time it does. Sometimes it doesn't. Once you have the pipeline, deployment is one command: uvx --from workers-py pywrangler deploy It reads your pyproject.toml , bundles FastAPI and all its dependencies, and pushes it to the edge. No Docker. No Lambda Layers. No VPC configs. Coming from AWS, this felt like cheating. D1 is Cloudflare's serverless SQLite. It supports proper SQL, joins, indexes, transactions. For an MVP with ~60 tables, it's been rock solid. The best part is local development. I keep a local aiomniu.db file and switch connection logic based on the environment: python db.py def get local conn : conn = sqlite3.connect "aiomniu.db" conn.row factory = sqlite3.Row return conn On Workers, same SQL through D1 async def query all env, sql, params : db = env.DB result = await db.prepare sql .bind params .all return clean nulls dict r for r in result "results" Same SQL. Same schema. Just different connection code. This saved me countless hours during development. The frontend is a separate Worker built with @opennextjs/cloudflare . It converts the Next.js build output into a Workers-compatible bundle. SSG pages pre-render at build time, ISR pages revalidate hourly. The SEO setup is clean — each page uses generateMetadata for dynamic meta tags and JSON-LD: export async function generateMetadata { params } : Promise<Metadata { const { slug } = await params; return { title: Hire ${SKILLS slug .name} Developers | aiomniu , description: Find pre-vetted ${SKILLS slug .name} developers for your project. , }; } With zero domain authority, I couldn't compete head-to-head. So I built alternatives pages — targeting people searching for competitors: | Page | What It Targets | |---|---| /alternatives/upwork | "Upwork alternatives" | /alternatives/fiverr | "Fiverr alternatives" | /hire/react-developer/in/sydney | "Hire React developer Sydney" | Each page is data-driven. Add one line to a config array, and a new SEO page appears with its own meta tags, content, and JSON-LD: SKILL CITY COMBOS = 'react-developer', 'shanghai' , 'python-developer', 'beijing' , 'react-developer', 'sydney' , 250+ more combos This generates 300+ SEO pages from about 50 lines of configuration. Google has indexed most of them. The long-tail strategy is working — we get impressions for queries we'd never rank for on the homepage. This is the biggest trap. It looks like Python, but: No thread pool. At all. Every route handler must be async def . Synchronous routes crash with RuntimeError: can't start new thread — because there's literally no thread to start. Dynamic imports don't work. import and importlib.import module fail silently. All imports must be static from X import Y at the module top level. The ASGI bridge was broken for months. The asgi import in workers-py had a version check bug that rejected valid versions. It was fixed in workers-py 1.11.0, but I spent a week debugging before figuring that out. JsProxy is everywhere. Every JavaScript value arrives as a JsProxy object. You need explicit conversion functions: python def to py val : try: from pyodide.ffi import to js as if hasattr val, 'to py' : val = val.to py except ImportError: pass local dev — no Pyodide return val def null val : """D1 NULL comes through as empty dict {}. Convert back to None.""" if isinstance val, dict and len val == 0: return None return val I ended up writing five utility functions just to handle Pyodide type conversions: to py , deep to py , null , clean nulls , and convert bind params . Each one addresses a different flavor of the same problem. Pyodide's multipart form parsing dies at roughly 138KB. Not gracefully — it just hangs or crashes. I had to add explicit file size checks before any upload: python async def upload file request: Request, ... : content length = int request.headers.get "content-length", 0 if content length 138 1024: return JSONResponse {"error": "File too large"}, status code=413 This forced me to use Cloudflare R2 for file storage — uploads go directly via presigned URLs instead of through the Python Worker. It's the right architecture for production, but discovering it through a silent crash was frustrating. The free plan limits Worker code to 10MB gzipped . My FastAPI + Pydantic + dependencies bundle is ~2.15MB, so I had room. But it's a hard ceiling — every new dependency needs a pip install size check. D1 returns SQL NULL values as empty JsProxy objects , which Pyodide's .to py converts to empty Python dicts {} . Not None . An empty dict. So a query like: SELECT bio, avatar FROM users WHERE id = ? Where bio is NULL returns {"bio": {}, "avatar": {}} instead of {"bio": None, "avatar": None} . I discovered this when I saw "{}" rendered on a user profile page. Not a great look. The fix runs on every single query result: php def clean nulls d: dict - dict: if not isinstance d, dict : return d return {k: null v for k, v in d.items } It works. But it's the kind of thing you only discover by accidentally shipping it to production. If I were starting today, I'd use Workers with JavaScript/TypeScript for the API layer, or Hono the framework built for Workers . Pyodide's quirks add too much overhead. The "write Python, deploy to edge" promise is real, but the edge is jagged. The site originally had a Vue 3 frontend. When I migrated to Next.js 15, everything got faster — SSG eliminated initial load time, SEO metadata became cleaner, and the developer experience was noticeably better. I didn't set up Google Search Console until after the first 100 pages were indexed. I have no idea what the early crawl behavior was. Connect it on day one — it's free and gives you crawl stats, index coverage, and search query data. After 3 months of zero-budget operation: The site is live at aiomniu.top https://aiomniu.top if you want to see it in action. Built something on Workers + Pyodide? What broke for you? I'd honestly love to hear — misery loves company. — aiomniu-pilot