Vercel is exceptional for frontend. But somewhere along the way, Python developers started asking: can I deploy my FastAPI, Django, or Flask app here too?
The answer from Vercel is technically yes. The answer from developers who tried it is more complicated.
Vercel does support Python via its serverless runtime. For simple, stateless API endpoints, it works. But the moment your Python backend needs persistent processes, background tasks, WebSockets, or runs longer than 60 seconds, you start fighting the platform instead of building your product.
This post covers exactly what happens when you try to run a real Python backend on Vercel, where it breaks, and what developers are using instead in 2026.
How Vercel Actually Runs Python
Before diving into the problems, it helps to understand the architecture.
Vercel runs Python through Vercel Functions, a serverless execution model based on ASGI (Asynchronous Server Gateway Interface) and WSGI (Web Server Gateway Interface). It officially supports FastAPI, Flask, and Django.
Here is what that means in practice:
- Each HTTP request spins up a new function instance
- The function handles the request and is destroyed
- No persistent server process runs between requests
- State is not preserved in memory across invocations
Vercel supports Python versions 3.12 (default), 3.13, and 3.14. It auto-detects your framework from entrypoint files like app.py, main.py, server.py, or index.py.
For a simple FastAPI REST endpoint that receives a request, does some logic, and returns a JSON response, this works fine. For everything else, read on.
_**
What “serverless Python” really means: Your app does not run. A function runs, once, per request. If your Python backend is more than a stateless API (background jobs, queues, real-time connections, long-running tasks), Vercel’s model works against you, not for you
**_.
The Real Limitations of Python on Vercel
This is where developers who tried Vercel for Python consistently run into problems. These are not edge cases. They are fundamental constraints of the serverless model.
1. No Persistent Processes
Your Python app does not “run” on Vercel. A function runs once per request and then it is gone.
This means:
- Django management commands cannot run continuously
- You cannot maintain in-memory state between requests
- Any initialisation that needs to happen once at startup becomes expensive, since it re-runs every cold start
- Long-lived connections to databases, message brokers, and external services must be re-established on every invocation
For developers coming from a standard gunicorn or uvicorn deployment, this is a significant mental model shift.
- Execution Timeout Kills Real Python Workloads
Most real Python workloads exceed this:
- LLM inference calls via OpenAI, Anthropic, or local models
- Data processing and ETL pipelines
- PDF generation, image processing, file conversion
- Web scraping jobs
- Any task that involves waiting for an external API with variable response time
If your function exceeds the limit, Vercel kills it mid-execution. No error is returned to the user, no retry, just a timeout.
3. Cold Starts Are Worse for Python
Python has heavier cold starts than Node.js or Go. When a Vercel function has not been invoked recently, the first request triggers initialisation — loading your Python runtime, importing your modules, and setting up your app.
For FastAPI and Django apps with multiple imports, this cold start can add 300 to 800ms to the first response.
For APIs that need consistent, low-latency responses, or any consumer-facing endpoint, this is a real problem that does not go away by optimising your code.
4. WebSockets Are Not Supported
Vercel does not support WebSockets. Full stop.
This means:
- FastAPI WebSocket endpoints (@app.websocket(...)) will not work
- Django Channels applications cannot be deployed
- Real-time features like live notifications, collaborative tools, and streaming AI responses are off the table
If your Python app has any real-time component, Vercel is not the right platform.
5. Background Tasks Are Unreliable
FastAPI’s BackgroundTasks feature partially works in a serverless context, but it is fundamentally unreliable because the function instance may be terminated before the background task completes.
More critically:
- Celery workers cannot run because they require persistent long-running processes
- Redis queues have no worker to drain them
- Scheduled jobs like Celery Beat and APScheduler cannot be set up
If your Django or FastAPI app sends emails in the background, processes uploaded files asynchronously, or runs any kind of job queue — none of this works on Vercel. You need a platform that can run your app and your workers as separate, persistent services. For reference, see how a FastAPI deployment guide handles worker separation on a container-based platform.
6. No Docker Support
Vercel does not support custom Dockerfiles. You cannot containerise your Python application and bring it to Vercel.
This becomes a problem when your app has:
- Complex system-level dependencies (ffmpeg, poppler, libpq, etc.)
- Machine learning libraries with native extensions (PyTorch, NumPy with BLAS, etc.)
- Custom build steps that require shell access
- Multi-process setups (app + worker + scheduler) If your requirements.txt includes anything beyond pure Python packages, you will likely hit build failures.
7. No Persistent File Storage
Vercel functions have access to /tmp, but it is ephemeral. Files written during one invocation are not available in the next.
This breaks:
- Django’s MEDIA_ROOT for user file uploads
- Any app that reads/writes files as part of its normal operation
- Local caching strategies that rely on the filesystem You are forced to use external storage (S3, Cloudflare R2) for anything persistent, even for simple use cases where local storage would have been fine.
8. Database Connection Pooling Breaks at Scale
Each serverless invocation opens a fresh database connection. At low traffic this is fine. At scale with dozens of concurrent requests, your PostgreSQL connection limit is exhausted quickly.
Without PgBouncer or a serverless-compatible connection pooler like Neon or Supabase’s pooler, your Django or FastAPI app will start throwing too many connections errors under real load.
This is a solvable problem, but it requires additional infrastructure that a persistent-process deployment handles automatically.
Summary of what works and what does not:
When Vercel Does Work for Python
Vercel is not a bad choice for Python in every scenario. It is a bad choice for most real Python backends. Here is when it makes sense:
- Simple REST APIs — a FastAPI app that receives a request, queries an external DB, and returns JSON in under 10 seconds
- Next.js + FastAPI in the same project: Vercel’s Services feature lets you deploy a frontend and a Python backend together, and the simplicity is genuine
- Lightweight Flask microservices: stateless transformations, webhooks, or integrations with no side effects
- Serverless data endpoints: a single endpoint that runs a short computation and returns a result If this is your use case, Vercel works. The problems start the moment you need your Python app to behave like a real server.
What Python Developers Are Using Instead
The developers who hit the walls above have moved to platforms that treat Python as a first-class citizen, not a serverless add-on.
What a real Python backend actually needs:
- A persistent process that runs 24/7, just like gunicorn or uvicorn locally
- Full container support, whether you bring a Dockerfile or a requirements.txt
- No execution timeout ceiling
- The ability to run background workers alongside your main app
- WebSocket support
- Auto-deploy from GitHub with no manual steps Kuberns is built for exactly this.
Deploy Any Python App from GitHub in One Click
Connect your GitHub repo, Kuberns detects your Python framework automatically, and deploys it as a full persistent container — not a serverless function. FastAPI, Django, Flask, or any WSGI/ASGI app runs the way it runs locally: as a continuous process.
No vercel.json, no serverless adapter config, no execution time gymnastics.
For step-by-step instructions, see how to deploy a Python app without DevOps skills and the dedicated Django deployment guide.
No Timeout Walls
Your LLM inference endpoint that takes 45 seconds? Runs fine. Your data pipeline that processes a 500MB CSV? No problem. Kuberns does not impose an arbitrary execution limit on your app.
Background Workers Run as Separate Services
Deploy your FastAPI app as one service and your Celery worker as another, both from the same GitHub repo and managed from a single dashboard. Redis, queues, and schedulers all run as persistent processes. This is something you simply cannot do on Vercel.
WebSockets Work
FastAPI WebSocket endpoints, Django Channels, real-time streaming — all supported. Your app runs as a persistent server, so it can maintain long-lived connections.
No Docker Complexity Required
You can bring a Dockerfile if you want. Or just push your code with a requirements.txt and Kuberns handles the container build automatically. Either way, your dependencies including native extensions, ML libraries, and system packages install cleanly.
Deploy your Python app on Kuberns
_
Deploy your Python backend on Kuberns. No credit card, no DevOps, no config files. Connect your GitHub repo and go live in under 2 minutes. Start Free
_
Top comments (0)