Deploying
Flask
From git push to production in minutes.
No build pipeline. No Vercel lock-in.
Flask deployment is simpler than you think.
The full deployment stack: Flask + gunicorn + PostgreSQL + Railway (or Render). No webpack. No build step. No cold-start delays from serverless functions. Your app runs as a real process, always on, always fast.
Below: the exact files you need, the exact commands to run, and an honest comparison against deploying a Next.js app on Vercel.
The Three Files You Need
This is everything required to deploy a production Flask app.
What each flag does:
--workers 2— 2 worker processes (scale up for more traffic)--worker-class gevent— async I/O for handling concurrent requests efficiently--bind 0.0.0.0:$PORT— listen on the port Railway/Render assigns
Five dependencies. That's the entire production stack.
Compare this to a Next.js package.json with 50+ packages.
Deploy on Railway
The recommended host for Flask Vibe apps. PostgreSQL included.
Push your app to GitHub
Create a new Railway project
Go to railway.app → New Project → Deploy from GitHub repo.
Select your repository. Railway detects the Procfile automatically and starts deploying.
Add a PostgreSQL database
In your Railway project → New → Database → PostgreSQL.
Railway automatically injects DATABASE_URL into your environment.
Set environment variables
Railway → Your service → Variables. Add your secrets:
You're live.
Railway gives you a public URL immediately. Every subsequent git push triggers an automatic redeploy.
No build step. No waiting. Typically live in under 60 seconds.
Flask vs Next.js: Deployment Reality
What deployment actually looks like for each stack.
| Aspect | Flask (Railway) | Next.js (Vercel) |
|---|---|---|
| Build step | None. Python runs directly. | 2–5 min build on every deploy |
| Config files needed | 1 Procfile | vercel.json + next.config.js + tsconfig.json + .eslintrc |
| Database included | PostgreSQL on Railway (same platform) | Separate service (Neon, Supabase, PlanetScale…) |
| Deploy time | ~30–60 seconds | 3–7 minutes (includes build) |
| Cold starts | None (always-on process) | Serverless functions: 200–800ms cold start |
| Pricing model | ~$5–20/month flat (Railway starter) | Free tier → $20/month (Vercel Pro) + DB costs |
| Vendor lock-in | None — gunicorn runs anywhere | Vercel-specific edge functions & ISR behaviour |
| Rollback | git revert + push | One-click in Vercel dashboard (good) |
| Logs | Standard stdout, Railway streams them live | Vercel log drains (paid for retention) |
| Environment variables | Railway UI, injected at runtime | Vercel UI, but some must be prefixed NEXT_PUBLIC_ |
The Honest Vercel Counterpoint
Vercel is genuinely excellent for Next.js. The one-click deploy, preview deployments per branch, and edge network are real advantages. If you're on Next.js, use Vercel. But if you're on Flask, Railway or Render are better fits — they're designed for long-running processes, not serverless functions. And they don't charge extra for database connections.
Alternative: Render
Railway's main competitor. Both work great for Flask.
Render setup
1. Connect your GitHub repo on render.com
2. Set build command: pip install -r requirements.txt
3. Set start command: gunicorn app:app
4. Add a PostgreSQL database (same platform)
5. Done. Auto-deploys on every push.
Railway vs Render
Railway: Better DX, faster deploys, generous free credits for new projects
Render: More predictable pricing, free static site hosting, good for teams
Both support custom domains, SSL, and PostgreSQL out of the box. Either works.
Three Files. One Command. Live.
Procfile + requirements.txt + runtime.txt. That's the entire deployment story.