Dois anos depois de apresentar o suporte experimental a Python, a Cloudflare levou os Python Workers para disponibilidade geral. A mudança não significa apenas que agora dá para subir um arquivo .py no edge. Python passa a ser uma linguagem oficialmente suportada na plataforma, com integração aos serviços que já cercam os Workers e suporte a frameworks conhecidos como FastAPI, Django e Flask.
Para equipes que já concentram APIs, automações e processamento de dados em Python, isso reduz uma barreira curiosa: não é mais necessário adotar JavaScript só para colocar uma função perto do usuário. Ao mesmo tempo, o ambiente continua sendo um runtime baseado em WebAssembly, não uma máquina Linux pequena disfarçada. Essa diferença define tanto as possibilidades quanto os limites da novidade.
O que o GA muda de verdade
GA, ou disponibilidade geral, indica que o recurso deixou a fase em que deveria ser tratado como experimento. A Cloudflare agora apresenta Python como linguagem de primeira classe ao lado de JavaScript, TypeScript e Rust. Isso inclui suporte de produção, ferramentas de desenvolvimento e acesso aos bindings da plataforma.
Esses bindings conectam o código a R2, D1, KV, Durable Objects, Queues, Workflows, Workers AI, Vectorize e outros serviços. Antes, o caminho entre Python e as APIs implementadas no runtime JavaScript frequentemente exigia conversões explícitas. Um dicionário Python enviado para uma fila, por exemplo, precisava virar manualmente um objeto JavaScript. O runtime e o SDK agora escondem essa tradução, permitindo trabalhar com valores Python normais.
É uma mudança de ergonomia importante. Um recurso pode existir tecnicamente e ainda ser ruim de usar se cada operação lembrar ao desenvolvedor que há outra linguagem do outro lado da ponte. Com a conversão incorporada ao runtime, a integração deixa de parecer um FFI exposto em cada linha do projeto.
FastAPI e Django sem um servidor tradicional
Frameworks Python normalmente conversam com servidores por contratos como ASGI e WSGI. Em uma instalação tradicional, Uvicorn ou Gunicorn recebe conexões, administra processos e entrega as requisições para a aplicação. Nos Workers, a própria plataforma assume o papel do servidor e os conectores workers.asgi e workers.wsgi traduzem a requisição para o formato esperado pelo framework.
from fastapi import FastAPI
from workers import asgi
app = FastAPI()
@app.get("/status")
async def status():
return {"ok": True}
Default = asgi.entrypoint(app)Esse adaptador permite reaproveitar a organização de uma aplicação FastAPI sem iniciar um processo de servidor dentro do Worker. Aplicações síncronas, incluindo projetos Django e Flask, podem usar a ponte WSGI. A compatibilidade não transforma automaticamente qualquer sistema existente em um bom candidato ao edge, mas diminui o trabalho para APIs e serviços que já respeitam esses contratos.
Por baixo, ainda é Python sobre WebAssembly
O código roda no Pyodide, uma distribuição do CPython compilada para WebAssembly, dentro de um isolate V8. Para reduzir o custo de inicialização, a Cloudflare executa boa parte do trabalho pesado durante o deploy: importa os módulos de topo, inicializa o ambiente e cria um snapshot da memória WebAssembly. Quando uma requisição chega, o isolate pode partir desse estado preparado.
Essa arquitetura explica por que não há um servidor Python convencional e também por que algumas expectativas precisam ser ajustadas. O filesystem é temporário e desaparece quando o isolate é destruído. Persistência deve ficar em serviços como R2, KV, D1 ou Durable Objects. Módulos ligados diretamente ao sistema operacional não estão todos disponíveis, e multiprocessing e threading não funcionam como em uma instalação normal do CPython.
O suporte a pacotes também merece uma checagem antes da migração. Pacotes Python puros, wheels PyEmscripten e bibliotecas incluídas no Pyodide são o caminho mais simples. Extensões nativas em C, C++ ou Rust precisam estar compiladas para WebAssembly; portanto, uma dependência disponível no PyPI não está automaticamente pronta para esse ambiente.
Banco relacional ficou menos estranho
Outro avanço relevante é o acesso a PostgreSQL e MySQL por meio do Hyperdrive. Drivers como asyncpg e aiomysql esperam sockets TCP, algo que o sandbox WebAssembly não oferecia da forma esperada pelo Python. A Cloudflare implementou essas operações sobre a API connect dos Workers, fazendo a tradução em uma camada baixa o suficiente para o driver continuar enxergando uma interface familiar.
Isso abre espaço para APIs pequenas, webhooks, gateways, processamento próximo do usuário e serviços que combinam código Python com inferência ou filas. Não elimina a necessidade de medir latência, compatibilidade de dependências e custo. Uma aplicação com processos longos, extensões de sistema específicas ou uso pesado de CPU provavelmente continuará mais confortável em containers ou servidores próprios.
Vale migrar uma API existente?
O GA torna razoável testar cargas de produção, mas não cria uma obrigação de migrar. O melhor primeiro candidato é um serviço pequeno, com dependências conhecidas, armazenamento externo e vantagem clara em rodar na rede da Cloudflare. Antes de levar um projeto grande, vale listar os pacotes nativos, o uso de filesystem, tarefas em segundo plano e qualquer expectativa sobre processos ou threads.
O ganho real está em poder escolher Python sem abrir mão do modelo operacional dos Workers. Para quem só precisava de uma API tradicional em uma região, a novidade talvez não mude muito. Para quem já usa a plataforma e mantinha uma segunda stack apenas porque seu código de dados ou IA era Python, a conta ficou bem mais interessante.