Django, FastAPI, or Flask — run as written.
A WSGI or ASGI process on a dedicated instance, a managed Postgres database that runs your existing migrations, and deploys triggered by a push — whichever of the three frameworks you’re running, the shape underneath is the same.
When this isn't the right fit A script or a one-off job with no HTTP-facing component at all doesn’t need a web-facing dedicated instance — that’s a scheduled job, which we’ll quote as a smaller line item, not a full app tier.
What it needs to run
The shape of the workload, before any hosting decision gets made.
- Runtime
- Python, via WSGI (Django, Flask) or ASGI (FastAPI, async Django)
- Build step
- Dependency install + migrations, run on deploy
- Standing process?
- Yes — gunicorn/uvicorn or equivalent, kept running
- Data store
- Postgres, almost always, via your existing migrations
- Verdict
- Dedicated, sized to whether a database is attached
How it runs here
The same management as every other tier we run, written in Python's own terms.
Provisioning
A dedicated instance with the WSGI/ASGI server of your choice already wired to a process manager that restarts it on crash or deploy.
Deploys
Push to main, the pipeline we already run installs dependencies, runs your migrations, and restarts the process — no separate deploy script to babysit.
Data + backups
A managed Postgres tier alongside the app, backed up nightly with point-in-time recovery — your existing migrations run against it unchanged.
TLS / DNS / monitoring
Certificates auto-renew, DNS is managed end to end, and monitoring restarts a hung worker before a request times out.
Moving it in
Already running somewhere else? See the full migration playbook — here's what's specific to Python.
- 1
Point us at the repo
Read access to the repo and the requirements/pyproject file is the whole ask.
- 2
We stand up a copy
Dependencies installed, migrations run against a copy of your data, checked on a staging mirror before anything is live.
- 3
Cutover on your schedule
DNS and TLS switch over with little-to-no downtime, rollback ready if anything looks wrong.
- WSGI and ASGI apps need different process managers underneath — mixing them up is the most common first-deploy failure, so we confirm which one before provisioning.
- Pending migrations that never ran in production surface for the first time during a move — we run them against a copy first, never against live data untested.
- Background task runners (Celery, RQ, arq) are a second process alongside the web one and need their own line item, not an assumption that the web dyno covers it.
The loop, on Python
A Python API or app tends to grow one endpoint, one management command, one Celery task at a time — the loop is built for exactly that cadence.
- 01Build
CustomLabs
Bring an app you already built, or have CustomLabs design and build the first version in Django, FastAPI, or Flask.
- 02Iterate
CodeHerder
Brief a new endpoint, a Celery task, or a data migration in plain language — an agent opens a pull request against the real Python codebase.
- 03Run
CustomHosted
A dedicated instance sized to the framework, a managed Postgres tier alongside it, patched and backed up on a schedule.
- Brief
- Briefed: add a Celery task that emails a weekly usage summary, and a new read-only endpoint for the dashboard.
- Pull request
- CodeHerder’s agent wrote the task and the endpoint against the real repo, opening a pull request the same day.
- Shipped
- Reviewed, merged, and running on the next scheduled push — no context lost between the brief and the code.
WSGI or ASGI, and why it changes the provisioning
Django, FastAPI, and Flask all run "Python on a server", but the process model underneath them isn't interchangeable.
Flask and classic Django are WSGI applications: one request, one worker, blocking calls are fine because each worker only ever handles a single request at a time. We put gunicorn in front of them with a worker count sized to the instance's CPU, and that's the whole story — no event loop to reason about, no async/await creeping into code that was never written for it.
FastAPI, and Django's newer async views, are ASGI applications built around an event loop — a single worker can hold open far more concurrent connections, which is exactly what makes FastAPI look cheap to run for a small API. The trade-off is that one blocking call inside an async view stalls every other request sharing that worker, so we run these behind uvicorn with a process count tuned to keep that risk contained rather than maximised for raw concurrency.
Getting this backwards — WSGI-style worker counts under an ASGI app, or vice versa — is the single most common first-deploy performance complaint we see move in from another host. We ask which one you're running before provisioning, not after something falls over under load.
A starting configuration
A production Django, FastAPI, or Flask app: a dedicated instance, a managed database, and the iteration add-on.
- Base plan
- Dedicated M
- Iteration — CodeHerder loop
- +$25/mo
- Managed database
- DB Standard — +$25/mo
- Estimated total
- $109/mo
Python questions
The questions this stack raises on its own. General hosting questions live on the homepage.
01Which Python frameworks do you actually support?
Django, FastAPI, and Flask are the common cases this page covers, but anything that runs behind WSGI or ASGI works the same way — describe it on the quote form.
02Do you run our existing migrations, or start fresh?
Your existing migrations run as-is against the managed database — we’re not asking you to switch ORMs or migration tools to move in.
03What about Celery or another task queue?
A worker process runs alongside the web process on the same or a separate instance, depending on load — tell us about it and we’ll size accordingly.
04Can CodeHerder write and run a migration for us?
Yes — a briefed schema change comes back as a pull request with the migration file included, reviewed before it runs against real data.
05Is FastAPI cheaper to host than Django?
Usually, yes, if there’s no database yet — Dedicated S often covers a small FastAPI service. Attach Postgres and the two frameworks cost about the same to run.
Keep exploring
- Databases
Managed Postgres, backed up nightly with point-in-time recovery.
- Dedicated compute
A fixed-price instance sized to the workload, with a static IP and full control.
- For: founders
Turning a fast-built Python app into something real users can hit.
- Email
The mail your Celery task actually sends through — the path, the records, and the honest limits.
Ready to start?
Tell us what you're running — one fixed monthly rate, within a business day.