Flask and Django, from app.py.
One fixed convention instead of a config file: an app object called app, in a file called app.py. That’s the whole contract.
app, in app.py.
Python apps are served as a WSGI application. agenthost imports the name app from app.py at the root — a fixed entrypoint, not something you can point elsewhere. A Flask or Django app object called app in that file is exactly what’s expected.
gunicorn has to be in requirements.txt. It isn’t “usually there” — it is what runs your code, and leaving it out is the second most common reason a Python deploy never comes up.
If your app lives in main.py, or the object is called application, add a two-line app.py that imports it under the right name. Your agent will do this without being asked.
# app.py — must expose `app`
from flask import Flask
app = Flask(__name__)
@app.route("/")
def index():
return "hello"
# requirements.txt
flask
gunicornEverything the platform expects.
Four facts, and they are the complete set — there is nothing else to get right.
requirements.txt at the root of what you sendgunicorn app:app — the callable named app, imported from app.pyrequirements.txt — which must list gunicorn, since that is what serves the app- build commands
- start commands
- ports
- Dockerfiles
- nginx
- systemd
- process managers
You configure none of this.
There is no build command, no start command and no port setting — for any runtime. Your agent sends files; what runs them is worked out from what's inside.
- TLS renewal
- health checks
- restart policies
- log rotation
- scaling rules
- deploy hooks
- CI pipelines
The one thing each runtime does expect is its entrypoint, and that’s on this page. The deploy reference is the exhaustive version your agent reads.
Will it run what you built?
We'd rather you found out here than mid-deploy, so both halves get the same billing.
Yes — what people deploy here
Flask apps of any size · Django projects · small JSON APIs · form back-ends · scheduled scraping with an HTTP endpoint · anything exposing a WSGI callable
No — what doesn’t work
ASGI frameworks are not served as-is — FastAPI, Starlette and Django’s async stack all speak ASGI, and gunicorn here runs a plain WSGI worker. FastAPI can be wrapped to expose a WSGI app, but it isn’t a drop-in, so plan on Flask or Django unless you know how to adapt it. Local disk isn’t persistent between deploys, so anything that has to survive one belongs in the database that comes with your app.
Why a deploy doesn't come up.
Your agent will usually get these right, and can read the logs when it doesn't. Listed anyway, because knowing the shape of the failure makes the log message make sense.
The entrypoint isn't app.py.
The import is app:app. A file called main.py, wsgi.py or server.py won’t be found, and neither will an object named application. This is the most common Python failure by a wide margin.
gunicorn missing from requirements.txt.
Without it there is no server to run your app, and the container exits immediately. Listing Flask alone is not enough.
Trying to deploy FastAPI unchanged.
The import succeeds and then requests fail, because an ASGI app doesn’t answer a WSGI worker. See the limits above — this one is worth knowing before you build rather than after.
Django not collecting static files.
Django serves its own static files only in debug mode. Run collectstatic as part of your project and serve them through your app, or keep the front-end as a separate static site.
Not what you're building?
Point your agent at it.
€4 a month, database included. Your agent reads the deploy reference itself, so you don't have to.