Best Python hosting for FastAPI, Flask, and Django

Choose Python hosting by checking request timeouts, background workers, and durable storage before deployment. These requirements help determine whether a host is a good fit for the app and whether you will need to migrate later.

Compare Python hosts on five points:

• Deploy workflow: Some platforms build Python apps from source and dependency files. Others use a Dockerfile that the team maintains.

• Cold starts and scaling: Scaling to zero can eliminate idle compute charges but delay the next request. Storage, networking, and other resources can remain billable.

• Pricing model: Platforms charge for CPU time, memory, storage, network usage, instance sizes, and workspace subscriptions.

• Framework support: Some platforms run Web Server Gateway Interface (WSGI) and Asynchronous Server Gateway Interface (ASGI) apps directly. Others require an adapter or wrapper.

• Python version support: Hosts differ in which Python 3 versions they support and how projects select a version.

Copy link to heading1. Vercel

Vercel runs FastAPI, Flask, and Django apps as Vercel Functions on Fluid compute. Connect a Git repository and configure dependencies and environment variables to deploy on push events. Standard layouts such as app.py or main.py usually need no Dockerfile or custom routing in vercel.json.

Vercel detects Django's manage.py and reads the project settings to locate the WSGI or ASGI application. If the project sets STATIC_ROOT, Vercel runs collectstatic during the build and serves the files from its content delivery network (CDN). The Django deployment documentation lists supported storage backends.

Copy link to headingVercel pros:

• Active CPU billing: Fluid compute pauses CPU billing while code waits on a database or external API. Provisioned Memory remains billable until the last in-flight request finishes.

• Current Python versions: The runtime supports Python 3.12, 3.13, and 3.14. Set the version in the project's files.

• Large Functions (beta): Eligible projects can deploy uncompressed bundles up to 5 GB, compared with the standard 500 MB Python limit. The beta requires Fluid compute with Active CPU enabled. Existing projects must opt in. Secure Compute and Static IPs are not supported.

Copy link to headingVercel cons:

• Hobby plan limits: The free plan permits personal, non-commercial use. Commercial projects require a paid plan to support their use, even before they generate revenue.

• Request time limits: Pro and Enterprise default to 300 seconds. You can configure up to 800 seconds, or 1,800 seconds in the extended-duration beta for supported runtimes. Secure Compute and Static IPs do not support the extended limit. Queue-triggered functions have the same execution limits.

Pricing: Hobby is $0. Pro starts at $20/month with $20 of usage credit. Function rates start at $0.128 per Active CPU hour, $0.0106 per GB-hour of Provisioned Memory, and $0.60 per 1 million invocations. CPU and memory rates vary by region. See Vercel pricing and function billing for credits and additional charges.

Best for: FastAPI, Flask, and Django APIs that store durable state externally and fit the function limits.

Copy link to heading2. AWS Lambda

AWS Lambda runs Python functions in response to events, including HTTP requests through API Gateway or Lambda function URLs. Cold-start latency depends on the runtime, dependencies, memory allocation, and deployment configuration. Independent daily cold-start benchmarks compare test configurations but do not predict startup latency for a full FastAPI or Django app.

Copy link to headingAWS Lambda pros:

• AWS service triggers: Functions can receive events from SQS queues, S3 storage, and EventBridge, among other AWS services.

• Faster startup options: SnapStart reduces initialization latency for supported Python runtimes. Provisioned concurrency keeps function instances initialized for an additional charge. You cannot enable both on the same function version.

• 15-minute invocations: A standard invocation can run for up to 900 seconds. HTTP responses also have integration limits. API Gateway HTTP APIs have a 30-second maximum integration timeout, so a 900-second function timeout does not guarantee a 15-minute HTTP response window.

Copy link to headingAWS Lambda cons:

• Adapter requirement: FastAPI can use Mangum or Lambda Web Adapter. Flask and Django also have adapter-based deployment options. The adapter connects the app to Lambda's invocation model.

• Infrastructure configuration: Configure HTTP integrations, Identity and Access Management (IAM) permissions, and deployment packages through the console, deployment templates, or infrastructure tools.

Pricing: Standard x86 on-demand rates start at $0.20 per 1 million requests and $0.0000166667 per GB-second after applicable free allowances. Rates vary by region and usage tier. For the latest information, see Lambda pricing.

Best for: Teams already using AWS that want to run Python APIs alongside their other AWS services.

Copy link to heading3. Google Cloud Run

Google Cloud Run manages serverless containers. Google's FastAPI source-deployment quickstart uses buildpacks to turn Python source into a container image without a team-written Dockerfile.

Copy link to headingGoogle Cloud Run pros:

• 60-minute requests: A service's request timeout defaults to 5 minutes. You can configure it up to 60 minutes, but client and upstream service timeouts can end the connection sooner.

• Source-based builds: Google's buildpacks turn Python source code into a container without a Dockerfile.

• No idle compute charges after scaling to zero: With request-based billing and no minimum instances, compute charges stop when the service scales to zero. Storage, networking, build services, and other resources can remain billable.

Copy link to headingGoogle Cloud Run cons:

• Django resource setup: Google's Django tutorial uses Cloud SQL and Cloud Storage. Other database and static-file setups are possible. Those services are not mandatory.

• Cold starts after idle periods: The first request after scaling to zero waits for a container to start. Keeping minimum instances warm costs money.

Pricing: With request-based billing in us-central1, on-demand CPU costs $0.000024 per virtual CPU (vCPU) second. For the latest billing information, see Cloud Run pricing.

Best for: Python APIs and machine learning (ML) inference endpoints that need synchronous request timeouts up to 60 minutes.

Copy link to heading4. Azure Functions (Flex Consumption)

Azure Functions Flex Consumption is Microsoft's event-driven serverless plan. The current runtimes support Python 3.11 through 3.14 as generally available and Python 3.15 in preview. Flex defaults to a 30-minute function timeout. HTTP-triggered functions must still respond within 230 seconds. Use an asynchronous response pattern or a background worker if processing takes longer.

Copy link to headingAzure Functions pros:

• Always-ready instances: Keep a configured number of instances initialized to reduce cold starts. Requests beyond that capacity may need new instances.

• Azure service bindings: Bindings connect functions to services such as Service Bus, Cosmos DB, and Blob Storage. They reduce the client code needed for supported operations.

• Long background jobs: Queue- and timer-triggered functions can run beyond the HTTP response limit. The configured function timeout and hosting-plan rules still apply.

Copy link to headingAzure Functions cons:

• Framework wrapper: FastAPI and Flask can use Azure's AsgiFunctionApp and WsgiFunctionApp classes to connect ASGI and WSGI apps to HTTP triggers.

• Django integration: Running Django on Functions requires a wrapper for its WSGI or ASGI application. You also need to configure the database, settings, and static files.

Pricing: Azure bills Flex execution time in GB-seconds and counts executions after the monthly on-demand free grant. See detailed pricing information on Azure Functions pricing.

Best for: Azure teams whose FastAPI or Flask APIs use Azure services and can respond within the HTTP time limit.

Copy link to heading5. Render

Render deploys Python services from a connected Git repository. Paid web services and background workers keep running between requests or jobs. Free web services can spin down. Render bills service compute separately from its Hobby, Pro, Scale, and Enterprise workspace plans.

Copy link to headingRender pros:

• Native Python runtime: Flask, FastAPI, and Django deploy without Docker. Render's Django guide uses WhiteNoise to serve static files.

• Separate worker services: Celery workers and cron jobs run as their own services next to the web app.

• Managed Postgres: A Django app and its Postgres database run in the same workspace.

Copy link to headingRender cons:

• Workspace fee: Teams with multiple members require a Pro or higher workspace plan. The workspace subscription is separate from service compute charges.

• Always-running workers: Render continues to charge for a worker's instance while it waits for jobs, even when the queue is empty.

Pricing: The Hobby workspace is $0, and Pro is $25/month. Service compute starts at $7/month for a 512 MB instance. Bandwidth, databases, disks, and other usage can add charges. See more details on Render pricing.

Best for: Django or Flask apps that run Celery workers and cron jobs beside a managed Postgres database.

Copy link to heading6. Railway

Railway builds Python source into containers with Railpack or uses the project's Dockerfile when one is present. Services keep running by default, so workers can remain active between jobs. Optional Serverless mode can put a service to sleep when it stops sending outbound traffic. Database connections and telemetry can keep the service awake.

Copy link to headingRailway pros:

• Resource-based billing: Railway meters CPU, memory, and volume storage over time. It bills service egress per GB transferred.

• Database templates: Postgres, MySQL, Redis, and MongoDB run in the same project as the app.

• Built-in cron: Paid plans support scheduled service executions without a separate scheduler service.

Copy link to headingRailway cons:

• Variable monthly bills: Traffic spikes and runaway workers increase resource usage and the bill.

• Serverless mode cold boots: A sleeping service must restart before it can answer the first request.

Pricing: Railway starts with a 30-day trial and $5 of credit. The Free plan then provides $1 of monthly credit. Hobby has a $5 monthly minimum that includes $5 of usage. For the latest pricing information, see Railway pricing.

Best for: Teams running always-on containers with Postgres or Redis that want usage-based billing and can monitor resource consumption.

Copy link to heading7. Fly.io

Fly.io runs Python apps as Fly Machines, lightweight virtual machines (VMs) that start and stop on demand. New accounts get a free trial of 2 total Machine runtime hours or 7 days, whichever ends first. Set auto_stop_machines = "stop" to let Fly Proxy stop excess idle Machines. Autostart and minimum-instance settings control how they resume and how many stay running.

Copy link to headingFly.io pros:

• Global placement: Machines can run in regions close to traffic across several continents.

• Per-second compute billing: Running Machines are billed by the second. Stopped Machines incur root-filesystem storage charges. Fly.io continues to charge for separately provisioned volumes and other billable resources.

• Generated setup files: fly launch can generate a starting Dockerfile and fly.toml for Django and FastAPI projects.

Copy link to headingFly.io cons:

• Dockerfile maintenance: The team must maintain the generated Dockerfile as dependencies and Python versions change.

• Region-based pricing: Compute rates vary by region. Traffic between regions can add network charges.

Pricing: A 256 MB shared-cpu-1x Machine starts at $2.19 per 30 days of continuous runtime in Ashburn or Secaucus. Stopped Machines cost $0.15 per GB of root filesystem per month. Volumes, network usage, and other resources are additional. For more information, see Fly.io pricing.

Best for: Teams comfortable with Docker that need regional Machine placement and configurable autostop without a monthly platform fee.

Copy link to heading8. PythonAnywhere

PythonAnywhere hosts Flask and Django as managed WSGI web apps. Task features depend on the plan. Configure web apps through the dashboard. Git pushes do not automatically deploy them.

Copy link to headingPythonAnywhere pros:

• No server setup: Flask and Django web apps run without configuring Gunicorn, a reverse proxy, or a container.

• Browser-based tools: The editor and Python consoles run in the browser, so you can develop without a local setup.

• Free HTTPS: All plans, including the free plan, support HTTPS certificates.

Copy link to headingPythonAnywhere cons:

• Limited async support: ASGI hosting is experimental. Manage apps such as FastAPI through command-line tools or an API. Limited web UI access is available on request.

• Restricted free accounts: Free accounts can access only an allowlist of external sites. This can block calls to third-party APIs.

Pricing: The Beginner plan is $0, the Developer plan is $10/month, and custom plans range from $10 to $500/month. For the latest information, see PythonAnywhere pricing and its ASGI documentation.

Best for: Django or Flask learning projects, portfolio sites, and educators who want a ready-to-code environment.

Copy link to headingFree Python hosting tiers and what they limit

All eight platforms offer a free tier or a trial. Limits cover compute allowances, idle behavior, and permitted uses. Free access can suit prototypes and personal projects, but check whether it meets the app's production resource and reliability requirements.

Each free tier has its own quota and limits:

Scale-to-zero on a serverless platform costs a cold start, whereas spin-down on Render's free tier costs a restart of about a minute.

Copy link to headingHow do you choose the right Python hosting?

A single hard requirement can rule out a whole hosting category before price comes up. A synchronous request longer than 30 minutes rules out every serverless option except Cloud Run, and a process that must keep local state rules out serverless entirely.

Copy link to headingRuntime interface and framework support

The framework interface affects deployment options. Server configuration determines concurrency too. Flask and Django can run on WSGI. Gunicorn's synchronous workers handle one request at a time, while threaded workers can handle concurrent requests within a process. FastAPI uses ASGI, which supports asynchronous request handling and WebSockets. Django supports both interfaces and needs ASGI to use its full async request stack.

Vercel runs WSGI and ASGI apps through its Python runtime. Lambda and Azure Functions use adapters or wrappers. cPanel's Passenger integration can host Python apps. Support for ASGI servers, Celery workers, and Redis depends on the provider's configuration and process policies. Shell access alone does not establish support for long-running services.

Copy link to headingRequest duration and long-running work

Check function execution limits separately from HTTP response limits. With Fluid compute, Vercel allows 300 seconds on Hobby. Pro and Enterprise default to 300 seconds, configurable up to 800 seconds or 1,800 seconds in the eligible extended-duration beta. Standard Lambda invocations allow up to 900 seconds, but API Gateway HTTP APIs cap integration time at 30 seconds. Azure Functions has a 230-second HTTP response limit. Cloud Run service request timeouts can be configured up to 60 minutes.

Leave room below a timeout for slower database queries or external calls. Move a 20-minute report to a background system if the caller does not need to keep an HTTP connection open. Choose a worker with enough execution time, and configure retries and duplicate handling.

Copy link to headingBackground workers and cron

Background jobs let an API respond before slow work finishes. Celery supports queued tasks. FastAPI’s BackgroundTasks runs work inside the web process after a response, and cron schedules executions. Vercel can run Celery tasks as private functions triggered by Vercel Queues, currently in beta, or as continuous workers through Vercel Daemons, currently in public beta. Render, Railway, and Fly.io also support long-running worker processes.

BackgroundTasks runs small operations after a response, but the work can stop if the web process exits. A durable queue stores pending work outside the request and can redeliver failed or unacknowledged messages. Vercel Queues provides at-least-once delivery, so handlers must tolerate duplicate execution. Queue-triggered functions still have execution time limits.

Copy link to headingDatabase connections and pooling

Autoscaling can create database connections faster than a fixed set of application processes. Each instance may open several Postgres connections. Adding instances during a traffic spike can exhaust the database's connection limit. Pool sizes, process counts, and connection cleanup determine the total.

An external pooler, such as PgBouncer, manages connections shared by application instances. With Django and transaction pooling, set DISABLE_SERVER_SIDE_CURSORS = True unless the app manages cursor lifetimes within transactions. Django's local connection pool, introduced in Django 5.1, requires psycopg[pool] and CONN_MAX_AGE = 0.

This partial settings example caps each process's pool at four connections. Choose a limit that fits the deployment's database connection budget.

DATABASES = {
  "default": {
    "ENGINE": "django.db.backends.postgresql",
    # NAME, USER, PASSWORD, and HOST read from environment variables
    "CONN_MAX_AGE": 0,
    "OPTIONS": {"pool": {"min_size": 0, "max_size": 4}},
  }
}

Each process has its own pool. With one database alias and four connections per process, the deployment can still open hundreds of connections as instances and processes multiply. Reserve capacity for other database clients. CONN_MAX_AGE = 0 disables Django's persistent connections. The pool manages connection reuse.

Copy link to headingHow Vercel hosts Python APIs

Vercel's Python runtime detects supported web frameworks. Services group apps in one project. Queues deliver background work, and Daemons run continuous worker processes. Each has its own configuration and limits.

Copy link to headingZero-configuration framework detection

Vercel reads dependencies from requirements.txt, pyproject.toml, or Pipfile with its lockfile to detect supported frameworks during the build. It loads apps from supported layouts, such as app.py or main.py, or from tool.vercel.entrypoint in pyproject.toml. In the Vercel case study, Delphi's Python backend supported more than 100 production deployments a day with 10 engineers and no dedicated infrastructure role.

Copy link to headingCold starts and Fluid compute

A cold start occurs when a new instance initializes before serving a request. Loading dependencies and running startup code add to the delay. Fluid compute reuses instances and handles concurrent requests within an instance, which can reduce how often new capacity must be initialized.

Vercel compiles Python source to bytecode during the build and includes the files if bundle space allows. This reduces initialization work. Eligible production deployments on Pro and Enterprise also use prewarmed instances. To measure an app's startup behavior, check initialization telemetry and compare first-request latency to that of later requests.

Copy link to headingPython and JavaScript in one deployment

Separate deployments for a Python backend and a Next.js frontend can require teams to coordinate releases, environment variables, routing, and preview environments.

Vercel Services, currently in beta, deploys the backend and frontend in one project with shared deployment configuration and top-level routing. Service bindings in vercel.json let server-side code call another service privately. A binding does not create a public route. A top-level rewrite can expose the target service, so check the routing configuration to determine public access.

Copy link to headingBackground work with queues and cron

Use a background system for long-running work that does not need an immediate HTTP response. Short operations and streamed inference can stay in request handlers. Vercel's Celery and Dramatiq integrations run workers as private, queue-triggered Vercel Functions with function execution limits. Continuous workers can use Vercel Daemons. Its beta supports production deployments, manual instance counts, and ephemeral storage.

Vercel Cron Jobs send HTTP GET requests to configured production endpoints. These endpoints are not automatically private queue consumers. Scheduled and queued work can share the API's project and production environment variables, but use different triggers and routing configurations.

Copy link to headingChoose the Python hosting for your architecture

Choose a Python host by checking durable storage, request and job duration, and worker deployment. Include the cost of maintaining adapters, Dockerfiles, routing, and separate services in the comparison, along with resource charges.

For FastAPI, Flask, and Django APIs, Vercel provides:

• Zero-configuration framework detection: Vercel deploys supported FastAPI, Flask, and Django layouts from a connected Git repository without a Dockerfile for the web app.

• Vercel Services (beta): The Python API and frontend can share a project and deployment, with configured public routing and private service bindings.

• Vercel Queues (beta): Background tasks run outside the request path. Queue-triggered functions still have execution limits, and handlers must tolerate redelivery.

Use Vercel Functions for request-driven Python APIs and Vercel Daemons for continuous background workers. Workloads that require persistent local storage need a separate storage solution.

Start a new project with an existing Python API, or browse templates for FastAPI, Flask, and Django starters.

Copy link to headingFrequently asked questions about Python hosting

Copy link to headingWhat is the best free Python hosting for a side project?

The Vercel Hobby plan supports personal, non-commercial FastAPI, Flask, and Django projects deployed from a connected Git repository. Google Cloud Run and AWS Lambda offer free compute allowances for eligible usage, but other resources can incur charges. PythonAnywhere's Beginner plan includes a browser-based editor for learning and personal web projects.

Copy link to headingIs Vercel good for Python APIs?

Yes, for FastAPI, Flask, and Django APIs that fit the execution and resource limits and store durable state externally. On Vercel, set a supported Python version in pyproject.toml, .python-version, or Pipfile.lock.

Copy link to headingHow much does Python hosting cost?

Small Python APIs typically cost $0 to a few dollars per month in compute costs. At Vercel's starting rates, 1M requests using 50 ms of Active CPU each cost about $2.38, and Provisioned Memory adds to that in proportion to how long instances stay alive.

Copy link to headingWhat is the difference between WSGI and ASGI for Python hosting?

WSGI defines a synchronous application interface. ASGI supports asynchronous request handling and WebSockets. Both can support streamed HTTP responses, depending on the server and app. Django's startproject creates wsgi.py and asgi.py, so a project can use either interface. Gunicorn can serve ASGI apps with an ASGI-capable worker, including Uvicorn workers.