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

> Source: <https://dev.to/aiomniu/building-a-freelance-platform-on-cloudflare-workers-the-good-the-bad-and-the-pyodide-nm3>
> Published: 2026-07-11 10:55:01+00:00

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