Deploying Python applications with Cloudflare
Compare Python Workers, static frontends and proxied origins, then plan a reversible deployment.
Published by DME with AI assistance. Examples are educational and identify their assumptions and limitations. Editorial approach and corrections.
“Deploy Python on Cloudflare” can describe several different architectures. Cloudflare may run the application in a Python Worker, serve a static frontend that calls a Python service elsewhere, or proxy a conventional Python origin. Choose the execution model before writing deployment instructions. This guide provides a decision worksheet and a release sequence rather than assuming that every Python application fits the same runtime.
Compare the hosting models
| Model | Suitable starting point | Validate first |
|---|---|---|
| Static Pages frontend + Python API | Separate browser UI and conventional service | Origin security, CORS and API authentication |
| Python Worker | A compatible request-driven edge application | Supported packages, runtime APIs and platform limits |
| Cloudflare proxy + Python origin | An existing server-based Python deployment | Origin access, trusted proxy settings and TLS |
Cloudflare's Python Workers use a WebAssembly-based Python environment built on Pyodide. Package compatibility and runtime behavior differ from a conventional CPython server. Consult the current documentation before selecting dependencies. A static Pages upload containing HTML and JavaScript does not start a Python process; uploading main.py as an asset would expose a file, not create an API.
Inventory the application's assumptions
List native extensions, background jobs, database drivers, filesystem writes, subprocess use and long-lived connections. Identify which work happens during a request and which work continues after it. Determine where persistent state belongs. Do not depend on an in-memory cache or a local file as the only record of a job that must survive restarts.
For a fictional report API, separate quick request validation from expensive report generation. Return a durable job identifier, process the job in a suitable worker system, and expose status and result endpoints. Put authentication and authorization on those endpoints; an unguessable-looking job ID is not an access policy.
Understand the existing DME deployment
DME's recovered site is a Cloudflare Pages Direct Upload of static assets. Its estimator and ROI calculator run in the browser. The contact form prepares an email draft rather than submitting to a server. These are appropriate static behaviors. Introducing a Python backend would be a separate architectural change requiring its own data handling, authentication and operating plan.
A maintainable static workflow can still use a local generator to produce HTML. Keep content, templates and checks in a source repository; upload only the generated public directory. Record the exact source revision and archive checksum for each release. Build tooling need not run on the production hosting platform to make a deployment reproducible.
Use a reversible release sequence
- Create a source-controlled build and record the dependency versions.
- Back up current public assets and persistent data separately.
- Deploy to a preview or staging environment with separate test credentials.
- Check routes, validation, authentication and persistence behavior.
- Run a representative load sample and measure resource use.
- Approve a specific artifact for production.
- Verify the live release and keep the previous version available.
Do not include secrets in a ZIP, Git commit or command recorded in a public guide. A deployment credential should have the smallest required scope. Avoid logging its value. If an application relies on forwarded client addresses or schemes, configure the origin to trust only the intended proxy path and test direct-origin behavior.
Define the verification evidence
Check the actual public URL, not just a successful build. Verify HTTPS, redirects, response content types, error responses and crawler access for public pages. A user-agent test can show whether a response differs, but spoofing a crawler name does not prove that a verified Google crawler will pass every firewall rule. Inspect rules and actual crawl reports where available.
For the first release, prefer the simplest model that satisfies dependencies and operational requirements. Revisit the decision when measured latency, cost or scaling constraints justify a change. Read Production API contracts before exposing writes and Cloud modernization before moving stateful workloads.
Technical references
Cloudflare Python Workers documentation describes the current runtime. Pages Direct Upload documentation explains static upload deployments and project limitations. Check these references again when implementing a deployment, because supported features change.