How to deploy a Python Flask or FastAPI app in 2026
Python web frameworks all share the same deploy story — a process that listens on a port, a database connection string, a few environment variables. Step-by-step tutorial for shipping Flask, FastAPI, or any WSGI/ASGI Python app to a real URL.
Dmytro Chervonyi
Co-founder & CMO, livemy.app
Last updated
TABLE OF CONTENTS
item

AI Summary
Python web apps follow the same deploy shape regardless of framework — Flask, FastAPI, Django, Bottle, Starlette. The host runs your Python process behind a production-grade WSGI or ASGI server (Gunicorn or Uvicorn), exposes a port, sets environment variables for database URLs and API keys, and routes traffic from your domain. This tutorial walks the end-to-end deploy for Flask and FastAPI — the two most common frameworks AI tools generate — plus the production server config, the Python version pinning, the database connection pooling, and the five gotchas that quietly break Python apps in production. Plus the 3-minute flow to livemy.app at $20/month flat with custom domain and free SSL.
Why this guide covers both Flask and FastAPI
Flask and FastAPI are the two Python web frameworks that show up in 95% of AI-generated Python web apps. Cursor, Claude Code, ChatGPT, and deploy a Replit Agent app all default to one of these when you ask for a Python API.
Good news: the deploy story is identical. Both are WSGI/ASGI Python apps that need a production server (Gunicorn or Uvicorn) and a port. Everything from environment variables to custom domain to SSL works the same way.
This tutorial walks the end-to-end deploy assuming you have a working Python app locally and want it on a real URL in under 15 minutes.
What you need before starting
A Flask or FastAPI app that runs locally with
python app.pyoruvicorn main:appA
requirements.txtlisting your dependencies (orpyproject.tomlfor Poetry/UV projects)The Python version your app needs (3.10, 3.11, 3.12, 3.13)
Environment variables your app reads (database URL, API keys, secret keys)
A GitHub account (recommended) or a ZIP of your project
Step-by-step: deploy on livemy.app
Step 1: Make sure your project is production-ready
Two files matter most. requirements.txt must include the production server.
For Flask:
For FastAPI:
Add a Procfile (optional but recommended) in the project root:
For Flask: web: gunicorn app:app --bind 0.0.0.0:$PORT
For FastAPI: web: uvicorn main:app --host 0.0.0.0 --port $PORT
Pin your Python version. Create a runtime.txt file:
Step 2: Push to GitHub
Make sure .env is in your .gitignore — never commit secrets.
Step 3: Sign up at livemy.app, pick Maker
Go to livemy.app, click Start free. Pick Maker ($20/month). Free tier sleeps after 60 minutes — not what you want for an API serving real traffic.
Step 4: Connect the GitHub repo
In the dashboard: New project → Connect repo. Authorize the livemy.app GitHub app, pick the repo. livemy.app reads requirements.txt + runtime.txt + Procfile, detects Python, sets up the build.
Step 5: Set environment variables
Open your local .env. Copy every line into Project Settings → Environment Variables. Common Python web app variables:
SECRET_KEY— Flask session secret (32+ random characters)DATABASE_URL— PostgreSQL or MySQL connection stringOPENAI_API_KEY/ANTHROPIC_API_KEY/ etc.DEBUG=False— critical for production. Never run Flask or FastAPI with DEBUG=True in production; it leaks tracebacks and enables remote code execution.
Step 6: Deploy
Click Deploy. livemy.app:
Pulls the Python version from
runtime.txtRuns
pip install -r requirements.txtStarts the process via your
ProcfilecommandRoutes traffic to your app on the configured port
Typical deploy time: 2 to 4 minutes for a small-to-medium Python app. Build log streams live.
Step 7: Verify the API works
When status is Live, livemy.app gives you a URL on your-app.livemy.site. Test it:
For FastAPI apps, the auto-generated docs at /docs let you test every endpoint in the browser — useful for confirming everything's wired up.
Step 8: Add custom domain
Click Add custom domain, paste your domain, update the DNS record at your registrar (A record for apex, CNAME for subdomain). DNS propagates in 1–10 minutes; SSL fires automatically via automated SSL.
Five things that quietly break Python apps in production
1. Running the dev server in production
Flask's built-in server (app.run()) and FastAPI's uvicorn main:app --reload are development servers. They're single-threaded, slow, and not designed to handle real traffic.
Fix. Use Gunicorn (Flask) or Uvicorn workers (FastAPI) in the Procfile. For Flask under heavier load: gunicorn app:app --workers 4 --bind 0.0.0.0:$PORT. For FastAPI: uvicorn main:app --workers 4 --host 0.0.0.0 --port $PORT.
2. DATABASE_URL connection string doesn't include the right driver
PostgreSQL connection URLs need postgresql:// (or postgresql+psycopg2:// for SQLAlchemy with psycopg2 driver). Just postgres:// works in many cases but breaks in others.
Fix. Always use the full driver prefix in DATABASE_URL. For SQLAlchemy: postgresql+psycopg2://user:pass@host:5432/db. For asyncpg: postgresql+asyncpg://user:pass@host:5432/db.
3. requirements.txt doesn't pin versions
If your requirements.txt just says flask instead of flask==3.0.0, deploys can break weeks later when a new Flask version is released. The build picks up the new version, your code wasn't tested against it, things break.
Fix. Pin exact versions: pip freeze > requirements.txt in your local virtualenv to capture the exact versions you tested against.
4. CORS not configured for browser clients
If a JavaScript frontend on a different domain calls your Python API, CORS preflight requests fail unless explicitly allowed.
Fix. For Flask, install flask-cors and add CORS(app, origins=["https://yourfrontend.com"]). For FastAPI, use the built-in CORSMiddleware: app.add_middleware(CORSMiddleware, allow_origins=["https://yourfrontend.com"], allow_methods=["*"], allow_headers=["*"]).
5. Background tasks that don't survive a restart
If you used FastAPI's BackgroundTasks or a thread to handle long-running work, those tasks die when the container restarts (which happens on deploys, on host scaling events, etc.).
Fix. For real background processing, use a job queue — Celery + Redis, RQ, or Dramatiq. Run the worker as a separate process. livemy.app supports separate "worker" services alongside the main web service.
Cost comparison for one Python API
Heroku Eco (cheapest paid): $5/month per dyno (sleeps after 30 min idle), Postgres add-on $9/month. Total: $14/month, with sleeps.
Render Starter: $7/month compute + $25 Pro workspace = $32/month for one always-on service.
Railway Hobby: $5/month base + usage = $5–20/month.
livemy.app Maker: $20/month flat, always-on, custom domain, SSL, monitoring all included.
Self-hosted on a $5 VPS: $5/month plus your time. Cheapest if you're comfortable with systemd, nginx, and automated SSL.
FAQ
Do I need Docker to deploy Python?
No. Modern hosts (livemy.app, Render, Railway, Fly.io) detect Python projects from requirements.txt and run them directly. Docker is an option if you need more control over the runtime, but not required.
Can I deploy a Django app the same way?
Yes — same tutorial works. The Procfile becomes web: gunicorn myproject.wsgi:application --bind 0.0.0.0:$PORT. Plus a release step for migrations: release: python manage.py migrate. Settings vary but the deploy shape is identical.
What Python version should I pick?
Python 3.12 in 2026 is the sweet spot — stable, performant, supported by every library. Python 3.13 is the latest but still hitting compatibility issues with some C extensions. Python 3.11 is fine if your code already runs on it.
How do I add a database?
Two approaches. Easiest: a managed Postgres from Supabase, Neon, or Railway. Free tiers cover small apps. Copy the connection string into DATABASE_URL as an environment variable. Alternative: livemy.app can provision a Postgres alongside your project as part of the deploy template.
Why is my Python app slow?
Three common reasons. First, dev server in production (see gotcha #1). Second, no connection pooling on the database (each request opens a new connection — use SQLAlchemy with pool_size=10). Third, blocking I/O in async code (FastAPI specifically — don't call sync functions in async handlers without run_in_executor).
How do I scale Python past one instance?
For livemy.app, scale the container size up (more CPU/RAM) on the Pro tier. For real horizontal scaling (multiple instances behind a load balancer), Render, Railway, and Fly.io support multiple replicas. Most Python apps don't need horizontal scaling until traffic is in the millions per day.
Deploy your Python app — 3 minutes, flat $20/month
If your Flask or FastAPI app is on GitHub and you've got requirements.txt + Procfile ready, you're three minutes away from a live URL on your own domain.
→ Start free on livemy.app · Auto-detect for Flask, FastAPI, Django, and any other Python WSGI/ASGI app. Custom domain, SSL, monitoring on Maker at $20/month flat.
Hit one of the five gotchas, or stuck on the database connection? Email hello@livemy.app with the error and your requirements.txt. Replies inside one business day.
Read next

Dmytro Chervonyi
,
Co-founder & CMO, livemy.app
Co-founder & CMO at livemy.app. 12 years as a CMO scaling SaaS from $0 to $10M+ ARR across marketing, sales, and infra products and tools. Now building the missing step between AI-built code and a live URL — for non-developers who’d rather ship than learn DevOps.


