Six months ago I sat down to build aiomniu — 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:
def _get_local_conn():
conn = sqlite3.connect("aiomniu.db")
conn.row_factory = sqlite3.Row
return conn
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'),
]
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:
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:
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:
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 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