What is the best Python hosting in 2026?
Every platform below runs Python; what separates them is whether they also run the worker, the scheduled job and the database beside it. Render has the only real free tier and charges $7/month for the smallest paid instance; PythonAnywhere at $10/month is the gentlest first deployment and the most limiting afterwards.
Granite — our own platform — is $9/month with $15 of usage credits, and covers managed Postgres, a Valkey broker and S3-compatible storage in one project. If what you are deploying is a single stateless service with no jobs and no uploads, cheaper options here beat it, and the table below says so.
Last updated 1 September 2026
"Python hosting" is three or four different questions wearing one name. A Django application needs somewhere for media, a Postgres and usually a Celery worker. A FastAPI service needs an ASGI server and a platform that does not cut long-lived connections. A script that reconciles invoices at 3am needs no web server at all, and the platforms that charge by the request are the wrong shape for it entirely.
The memory floor is the one thing they share: a Python process holds the interpreter and your imported application, so the 256 MB tiers that comfortably run a Go binary are unavailable here. The short version is Render for a free demo, PythonAnywhere for a first deployment, Cloud Run for something idle most of the day, and Granite — ours — when the web process, the worker, the schedule and the database should be one project.
How much does Python hosting cost?
| Provider | From /mo | Free tier | Managed DB | Persistent disk | Deploy from |
|---|---|---|---|---|---|
| Fly.io | ~$2 | Postgres (unmanaged app) | Dockerfile, buildpack | ||
| Railway | $5 | yes ($1 credits) | Git, Dockerfile, template | ||
| Render | $7 | yes (spins down) | Git, Dockerfile | ||
| Granite | $9 | from Advanced | Git, Docker image | ||
| PythonAnywhere | $10 | yes (limited) | MySQL | yes (5 GB) | Git pull, web UI |
| Koyeb | $29 | limited | Serverless Postgres | Git, Dockerfile | |
| Google Cloud Run | usage-based | yes (monthly allowance) | via Cloud SQL | no (use GCS) | Container image |
Entry prices as published by each provider on 1 September 2026, sorted cheapest first. Usage, bandwidth and databases are billed on top almost everywhere — treat this column as a starting point, not a monthly bill.
Django, Flask, FastAPI — or no framework at all?
Django is the demanding one: synchronous WSGI under gunicorn, a real Postgres, somewhere for uploads that survives a deploy, and usually a Celery worker and a beat scheduler behind it. Four processes and two data stores is the normal case, which makes "can this platform run more than a web service?" the first question rather than the last. Django hosting compared goes through it platform by platform.
Flask is the same runtime shape with fewer assumptions — still WSGI, still a synchronous pool, but nothing bundled, so the database, the migrations and the queue arrive one decision at a time. It starts smaller and stays inside a 512 MB tier for longer. Flask hosting compared covers where that stops being true.
FastAPI changes the requirements rather than the number of them. ASGI under uvicorn means an async pool per event loop, long-lived websockets that an aggressive idle timeout will kill, and health measured by a readiness probe rather than a TCP check. FastAPI hosting compared is the detail.
A script with no HTTP port is the case every listicle forgets. A poller, a scraper, a nightly report never serves a request, so a platform that bills per request or demands a listening port is the wrong tool. What it needs is a process type allowed to run without a public domain, or a container that starts on a schedule and exits.
A site with uploads, a database and background jobs — Django, or Flask that grew
Managed platform
Web, worker and scheduler deploy together, with Postgres and storage attached.
Granite · Render · Railway
An API that is idle most of the day and holds no long-lived connections
Serverless
Free while asleep, at the cost of a seconds-long Python cold start.
Cloud Run · Koyeb
A script or a poller that never serves an HTTP request
Worker or cron-job
A process with no public domain, or a container that starts on a schedule and exits.
Granite · Render · A VPS
What does each platform actually give you?
Fly.io
- Best for
- Multi-region deployment, if you are comfortable operating your own database.
- Pricing
- Pay as you go. The smallest shared-cpu-1x machine with 256 MB RAM works out at roughly $2.02/month, billed per second.
- Takes your Dockerfile unchanged, so a slim multi-stage image behaves exactly as built.
- Per-second billing, volumes on every machine and Anycast routing across regions.
- Postgres is an app you deploy and back up yourself — a second job, not a checkbox.
- The $2.02 machine has 256 MB of RAM, which is a Go budget rather than a Python one.
Railway
- Best for
- Getting a Python app, a Postgres and a Redis running together the same afternoon.
- Pricing
- Billing is per second of actual usage against a monthly minimum: $5 on Hobby and $20 on Pro, each including that much usage credit. The free plan is a 30-day trial with $5 of credits and $1 a month afterwards, capped at 1 vCPU and 0.5 GB per service. Pro includes unlimited workspace seats.
- Templates assemble the app, the database and the broker with private networking between them.
- Per-second billing suits a worker that is idle for most of the day.
- Usage-based billing is hard to forecast, and Python spends credits faster than a lighter runtime.
- Hobby is a single-developer workspace; a second person means Pro's $20 monthly minimum.
Render
- Best for
- A free demo now, and a simple paid tier when it stops being a demo.
- Pricing
- Free web services are available but spin down after 15 minutes without traffic. The cheapest paid instance, Starter, is $7/month for 0.5 vCPU and 512 MB RAM.
- A genuine free tier for web services, plus free Postgres and Key Value instances to build against.
- Background workers, cron jobs and release commands are first-class rather than improvised.
- Free services spin down after 15 minutes idle, and a Python cold start is seconds long.
- The $7 Starter tier is 512 MB — two modest workers and not many more.
Granite
- Best for
- A Python app whose worker, scheduled jobs, database and storage should live in one project.
- Pricing
- Hobby is $9/month and includes $15 of monthly usage credits. Advanced is $39/month with $50 of credits, Professional $149/month with $200. Every plan has unlimited workspace seats.
- Web app, worker and cron-job are three resource types from one image, sharing environment variables and internal DNS.
- Managed Postgres and Valkey with no public endpoint, plus S3-compatible storage with a CDN.
- No free tier; the cheapest way in is $9/month for the project.
- Hobby caps each service at 1 vCPU, 1 GiB and one replica, which a real gunicorn set outgrows.
PythonAnywhere
- Best for
- A first deployment, coursework, or an internal tool where simplicity beats control.
- Pricing
- A limited free Beginner account runs one web app with restricted outbound internet. The Developer plan is $10/month: one web app on a custom domain, 5 GB of storage and 5,000 CPU-seconds a day.
- Built for Python specifically: no Docker, no build pipeline, no YAML to learn first.
- Scheduled tasks and a MySQL database are included rather than assembled.
- You work inside their environment rather than your own container, so anything unusual may be impossible.
- Queue workers are awkward here, which rules it out for most Celery projects.
Koyeb
- Best for
- Edge presence with scale-to-zero, if the entry price is acceptable.
- Pricing
- Pro is $29/month plus compute and includes $10 of it; Scale is $299/month including $100. Serverless Postgres has a free tier of 5 hours a month at 0.25 vCPU, 1 GB RAM and 1 GB of storage, after which the smallest always-on instance is $29.76/month plus $0.50 per GB stored.
- Edge locations and a serverless Postgres are included rather than sold separately.
- Autoscaling and per-second billing on every plan.
- Scale-to-zero fits Python badly: importing the application takes seconds a visitor sits through.
- The highest entry price of any managed option in this table.
Google Cloud Run
- Best for
- A stateless Python service with spiky traffic that should cost nothing while idle.
- Pricing
- No monthly fee. You pay per request and per resource-second, with a monthly free allowance. Cloud SQL and networking are billed separately.
- Free while idle, with 180,000 vCPU-seconds and 2 million requests included each month.
- Takes any container image and scales past anything you are likely to need.
- No persistent disk, so uploads move to Cloud Storage before the first deploy, not after the first incident.
- Postgres, secrets and networking are separate Google Cloud products you assemble yourself.
What does a Python app need from a host?
- Memory per worker, not per request
- Every gunicorn or uvicorn worker is a separate process holding the interpreter and your imported application. Memory tracks the worker count and stays roughly flat as traffic rises, so size the plan by processes and treat the 256 MB tiers as unavailable.
- A process type that is not a web service
- Queue consumers, pollers and scheduled commands have no HTTP port. A platform that only knows how to run web services means renting a second one for the half of your application that does not serve requests.
- Migrations as a release step
- manage.py migrate, flask db upgrade and alembic upgrade head all have to run once per deploy, after the build and before traffic — never from the container start command, where every replica races the others through the same schema.
Where do background jobs and queue workers run?
In a process of their own, whichever framework you are on. Celery with a Valkey or Redis broker is the default for Django and Flask; RQ is the smaller version of the same idea; arq and Dramatiq fit an async FastAPI codebase better. What they have in common is the deployment shape: a long-lived process started from the same image with a different command, so the task code and the request code cannot diverge. On Granite that is a worker resource — no public domain, internal ports only, always running — and it is also where a script with no HTTP port lives, which is why the type exists separately from a web app at all.
How do scheduled tasks and cron work?
Two families. In-process schedulers — celery beat, APScheduler, an asyncio task started in a FastAPI lifespan handler — are convenient and only correct at one replica, because each copy of the process keeps its own timer. Platform cron is the other: on Granite a cron-job resource runs a command such as python manage.py send_digests on a standard cron expression, always as a single container, with Forbid or Allow deciding what happens when a run overruns its next slot. Its output goes to that resource's own log — novps resources logs <id> --since 1d.
Is Postgres managed, and what about backups?
Managed on Render, Railway, Koyeb and Granite; an app you run on Fly; a separate Cloud SQL instance on Cloud Run; MySQL rather than Postgres on PythonAnywhere. Granite takes scheduled backups into external storage and support can run point-in-time recovery for Postgres on request, with the interval unpublished — ask before you promise an RPO. Databases have no public endpoint: the app connects over internal DNS and you connect with novps port-forward database <id> -l 5432. Watch the connection arithmetic either way — a synchronous pool per gunicorn worker and an asyncpg pool per event loop both multiply by the replica count.
How do deploys and migrations work?
Either a push to the tracked branch, which builds an image and rolls it out, or a Docker tag the platform watches for a new digest. collectstatic and dependency installation belong in the build. Migrations belong in a release step that runs once: Render and Railway provide one, and Granite does not, so run the migration from the resource's Console tab or over a forwarded database port before the new image goes live. Rolling the image back does not roll the schema back, which is the argument for adding a column in one deploy and removing the old one in another.
What does it actually cost per month?
A web process, a worker and a small Postgres, priced as of 1 September 2026. Render is $7 plus $7 plus $6 for a 256 MB database — $20, and $10 more for a Key Value broker if Celery needs one. Fly.io is $3.32 for each 512 MB machine with the Postgres left to you. PythonAnywhere is $10 flat, with scheduled tasks but no real queue. Cloud Run bills $0.000018 per vCPU-second with 180,000 free, which flatters the web process and does nothing for a worker that must stay awake. Granite is $9 with $15 of credits shared across all three, inside a 1 vCPU and 1 GiB ceiling per service on Hobby.
So which should you pick?
Your first deployment, or a teaching project. PythonAnywhere. It hides the parts you are not ready for, and the free tier serves a real site on a subdomain.
A demo that should cost nothing. Render's free tier, accepting that the first visitor after fifteen idle minutes waits several seconds.
A script or a service that is idle most of the day. Cloud Run if it serves HTTP, a small always-on worker if it does not.
An application with a worker, a schedule and a database. This is where we would argue for Granite. Web app, worker and cron-job are three resources from one image, Postgres and Valkey sit beside them with no public endpoint, and S3-compatible storage takes the uploads. From $9/month with $15 of credits, though a real gunicorn set will want Advanced at $39.
Already know which framework? Django, Flask and FastAPI each have their own comparison, and the app platform page covers workers and cron jobs in detail.
Hosting for other stacks
Six ways to run a Go binary, from a $2 machine to scale-to-zero — and why Go stays cheap longer.
Seven options weighed on the things Django actually needs: media storage, a real Postgres, Celery workers and enough memory for gunicorn.
Vercel and six alternatives, weighed on the things that actually break when you self-host: ISR across replicas, image optimization and build-time env vars.
Six ways to run an Express, NestJS or Fastify service — weighed on the event loop, the connection pool, and what a long-lived process costs while it waits.
Six platforms plus Kamal, weighed on what Rails really needs: a release phase for migrations, a job runner, Active Storage and enough memory for Puma.
Laravel Cloud and six alternatives, weighed on queue workers, the scheduler, writable storage and the caches you must rebuild on every deploy.
Six platforms weighed on what an ASGI service actually needs: worker processes, connections that stay open, and a database pool that does not multiply out of control.
Seven options for the framework that ships no opinions — weighed on the WSGI server you have to bring, the session key you must keep stable, and the extensions that decide the rest.
Six platforms weighed on the things Symfony assumes: a warmed cache built at build time, Messenger workers that restart on deploy, and Doctrine migrations that run exactly once.
Seven platforms for a framework that renders on every request — weighed on streaming, adapters, and how far the loaders sit from the database.
Six platforms weighed on what the JVM actually asks for: memory it is allowed to use, a container that knows its own limits, and a start-up you can afford to repeat.
Six places to run a container image, compared on what actually bites: architecture mismatches, registry access, signal handling and the volume you assumed would still be there.
Five ways to serve HTML that is already written — and an honest note about which of them we are not the right answer for.