Cómo desplegar FastAPI en Cloudflare Workers: Python ya es GA en el edge

Ya puedes desplegar FastAPI en Cloudflare Workers sin servidor ni capa de JavaScript: Python Workers es GA desde el 21 de septiembre de 2026. Django y Flask también corren, y la base de datos se conecta a PostgreSQL o MySQL mediante Hyperdrive. Aquí va cómo levantar una API con FastAPI y PostgreSQL en Workers, y qué todavía no funciona.

¿Qué es Cloudflare Workers y qué cambia con Python GA?

Cloudflare Workers es la plataforma serverless de Cloudflare: tu código corre en su red global, y la propia plataforma se encarga del escalado y el balanceo de carga. Hasta ahora, Workers era en la práctica un runtime de JavaScript/TypeScript, con Python disponible como beta abierta desde 2024.

GA significa que Cloudflare ahora trata a Python como un lenguaje de primera clase, con soporte completo en su plataforma de desarrollo. En la práctica cambiaron tres cosas:

  • Los bindings hablan Python de forma nativa. Antes necesitabas código de enlace con pyodide.ffi.to_js para enviar un diccionario de Python a una Queue. Ahora self.env.QUEUE.send({"key": "value"}) simplemente funciona. Lo mismo aplica a Workers AI, R2, D1, Durable Objects, Queues y Workflows.
  • Los frameworks web corren tal cual. FastAPI (ASGI), y Django y Flask (WSGI), corren a través de adaptadores ligeros que Cloudflare incluye en su SDK workers. Workers cumple el papel que uvicorn o gunicorn cumplirían en un servidor tradicional.
  • Las bases de datos y los clientes HTTP funcionan. Cloudflare implementó las llamadas de sistema de sockets sobre la API connect de Workers, así que drivers estándar como asyncpg pueden abrir conexiones TCP, y librerías como openai, langchain y mcp ahora corren de forma nativa.

Por debajo, Python Workers corre sobre Pyodide, una compilación de CPython a WebAssembly. Eso define qué paquetes puedes usar (más abajo).

¿Cómo desplegar FastAPI en Cloudflare Workers?

Necesitas dos cosas instaladas: uv y Node.js. Todo lo demás pasa por pywrangler, el CLI de Python Workers, que envuelve el wrangler de Cloudflare y empaqueta tus dependencias de Python al desplegar.

1. Crea el proyecto

uvx --from workers-py pywrangler init

Esto crea un pyproject.toml con workers-py como dependencia de desarrollo, además de un archivo de configuración de Wrangler. Si prefieres escribir los archivos a mano, esto es lo que usa la guía de FastAPI de Cloudflare.

2. Declara tus dependencias

pyproject.toml:

[project]
name = "my-fastapi-app"
version = "0.1.0"
requires-python = ">=3.13"
dependencies = [
    "fastapi",
]

[dependency-groups]
dev = [
    "workers-py",
    "workers-runtime-sdk"
]

3. Escribe la aplicación

src/main.py:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"Hello": "World"}

from workers import asgi
Default = asgi.entrypoint(app)

La última línea es la única parte específica de Workers. asgi.entrypoint(app) conecta tu aplicación FastAPI al runtime de Workers, igual que lo haría uvicorn main:app en una VM.

4. Prepara el archivo wrangler.jsonc

wrangler.jsonc:

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "my-fastapi-app",
  "main": "src/main.py",
  // Set this to today's date
  "compatibility_date": "2026-09-22",
  "compatibility_flags": ["python_workers"]
}

El flag python_workers sigue siendo obligatorio, aunque ya sea GA. La fecha de compatibilidad también elige tu versión de Python: desde 2026-09-08, Workers usa Python 3.14 por defecto.

5. Pruébalo en local y despliégalo

uv run pywrangler dev
curl http://localhost:8787/
# {"Hello":"World"}

uv run pywrangler deploy

pywrangler acepta todos los comandos de wrangler, así que uv run pywrangler --help muestra la lista completa.

¿Cómo conectar FastAPI a PostgreSQL en Cloudflare Workers?

Te conectas a través de Hyperdrive, el pool de conexiones de Cloudflare para bases de datos existentes. Mantiene un pool activo dentro de la red de Cloudflare y cachea las consultas de lectura más frecuentes, así que tu Worker se ahorra los viajes de ida y vuelta de TCP, TLS y autenticación en cada petición. Tu base de datos tiene que ser accesible públicamente; para una red privada, Cloudflare documenta una configuración aparte con Workers VPC.

1. Crea la configuración de Hyperdrive

npx wrangler hyperdrive create <YOUR_CONFIG_NAME> --connection-string="postgres://user:password@HOSTNAME_OR_IP_ADDRESS:PORT/database_name"

El comando devuelve un id. Cópialo.

Ten en cuenta que Hyperdrive cachea por defecto los resultados de lectura y no invalida esa caché cuando tu aplicación escribe. Si necesitas leer justo lo que acabas de escribir, la documentación recomienda una segunda configuración de Hyperdrive con la caché desactivada (--caching-disabled) para esas lecturas.

2. Agrega el binding

Hyperdrive en Python Workers requiere una fecha de compatibilidad de 2026-09-08 o posterior.

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "my-fastapi-app",
  "main": "src/main.py",
  "compatibility_date": "2026-09-22",
  "compatibility_flags": ["python_workers"],
  "hyperdrive": [
    {
      "binding": "HYPERDRIVE",
      "id": "<HYPERDRIVE_CONFIG_ID>"
    }
  ]
}

Agrega "asyncpg" a dependencies en tu pyproject.toml.

3. Consulta desde una ruta de FastAPI

La documentación de Cloudflare muestra dos piezas por separado: FastAPI leyendo los bindings desde request.scope["env"], y asyncpg conectándose a través del binding de Hyperdrive. Juntas quedan así:

import asyncpg
from fastapi import FastAPI, Request
from workers import asgi

app = FastAPI()

@app.get("/users")
async def list_users(request: Request):
    hd = request.scope["env"].HYPERDRIVE
    conn = await asyncpg.connect(
        host=hd.host,
        port=int(hd.port),
        user=hd.user,
        password=hd.password,
        database=hd.database,
        ssl=False,
    )
    try:
        rows = await conn.fetch("SELECT id, name FROM users LIMIT 10")
    finally:
        await conn.close()
    return [dict(r) for r in rows]

Default = asgi.entrypoint(app)

ssl=False es el valor que usa el ejemplo oficial de Cloudflare para Hyperdrive. Los drivers que Cloudflare probó y verificó son asyncpg (recomendado), pg8000 y psycopg para PostgreSQL, y aiomysql (recomendado) y pymysql para MySQL.

¿Cómo desplegar Django o Flask en Cloudflare Workers?

Igual que FastAPI, pero con el adaptador WSGI en lugar de ASGI, porque son frameworks síncronos:

from workers import WorkerEntrypoint, wsgi
from your_django_app.wsgi import app

Default = wsgi.entrypoint(app)

Cualquier framework que hable ASGI o WSGI debería funcionar del mismo modo. El repositorio python-workers-examples de Cloudflare incluye proyectos funcionales django, django-todo-d1, flask-todo y fastapi-todo.

¿Qué paquetes de Python funcionan en Cloudflare Workers con Pyodide?

Funcionan los paquetes de Python puro publicados en PyPI. Los paquetes con extensiones en C, C++ o Rust solo funcionan si publican un wheel para WebAssembly, o si ya vienen incluidos en Pyodide.

El camino hacia más paquetes es PEP 783, que propuso Cloudflare. Estandariza una plataforma “PyEmscripten” para que los mantenedores publiquen wheels de WebAssembly en PyPI igual que publican los de Linux o macOS, y cibuildwheel ya permite compilarlos. La adopción todavía es temprana: si una dependencia no tiene wheel de WASM, hoy no puedes usarla.

Hay un límite que afecta directamente a quienes usan FastAPI. Al 22 de septiembre de 2026, la documentación de Hyperdrive indica que solo está soportado SQLAlchemy síncrono, porque Python Workers no tiene soporte para greenlet. Si tu aplicación FastAPI usa sesiones asíncronas de SQLAlchemy, planifica usar asyncpg directamente, o SQLAlchemy síncrono serializando las operaciones con un asyncio.Lock, como recomienda la documentación para operaciones síncronas de base de datos.

¿Cloudflare Workers o AWS Lambda para Python serverless?

La diferencia está en el cold start, y el anuncio de GA no publica cifras de cold start.

En el hilo de Hacker News del lanzamiento, el fundador de Wasmer citó un benchmark propio de su empresa, publicado a principios de este año: unos 900 ms para una aplicación mínima de Python en Cloudflare Workers, frente a unos 60 ms en Wasmer Edge. Wasmer vende un producto competidor, y él mismo describió las cifras como de hace varios meses. Uno de los autores del anuncio respondió que los memory snapshots y el sharding de peticiones ya redujeron los cold starts y su frecuencia, y remitió a cifras propias de Cloudflare publicadas en un post anterior. Los números de ambas partes son autorreportados. Mide con tu propia aplicación antes de comprometer una API sensible a la latencia.

Donde Workers gana con claridad es en el modelo operativo: no hay servidor ni imagen de contenedor, desplegar es un comando, y tu código Python habla con R2, D1, Queues y Workers AI sin código de enlace.

¿Qué le falta todavía a Python Workers?

Al momento de publicar esta nota (22 de septiembre de 2026):

  • La documentación todavía no dice “GA”. La página de Python Workers y el README del repositorio de ejemplos siguen exigiendo el flag python_workers, y el README todavía describe Python Workers como beta abierta.
  • El anuncio de GA no incluyó precios ni cifras de cold start.
  • SQLAlchemy asíncrono no está soportado, como se explicó arriba.

¿Vale la pena probarlo?

Si tienes un servicio pequeño en FastAPI, una API interna o un receptor de webhooks que no depende de extensiones nativas pesadas, sí. Son tres archivos y dos comandos hasta un endpoint desplegado globalmente, y PostgreSQL a través de Hyperdrive es algo que la beta no tenía: antes, sin sockets TCP, los drivers de base de datos no funcionaban. Si tu stack depende de pipelines intensivos en NumPy o de SQLAlchemy asíncrono, revisa primero el soporte de paquetes.

Para el panorama general de correr backends en el edge, revisa nuestra nota sobre edge computing para backend; para otra pieza de Cloudflare, Browser Run; y para el contexto de por qué Python importa tanto hoy, Python no solo es popular: está dejando a todos atrás.