Entry-Point Runtime — Python

Heuristics the Stella Ops scanner uses to classify a container entry point as a Python application — interpreter launch, WSGI/ASGI server, or task runner — plus the evidence it attaches and the edge cases it guards against. For the shared detector contracts, scoring, and calibration, see the Runtime Detector Overview.

Signals to gather

• argv0 equals python, python3, pypy, or an interpreter symlink.
• WSGI/ASGI servers: gunicorn, uvicorn, hypercorn, daphne.
• Task runners: celery -A app worker, rq worker, pytest.
• Presence of requirements.txt, pyproject.toml, setup.cfg, or Pipfile.
• PYTHONPATH, PYTHONUNBUFFERED, DJANGO_SETTINGS_MODULE, FLASK_APP, or application-specific env vars.
• Virtualenv detection (/venv/bin/python, pyvenv.cfg).

Implementation notes

• When invoked as python -m module, resolve the module to a path if possible.
• For WSGI/ASGI servers, inspect command arguments (app:app, module:create_app) and config files.
• Recognise wrapper scripts such as docker-entrypoint.py that eventually exec "$@".
• Support zipped apps or single-file bundles by checking zipapp signatures.

Evidence & scoring

• Increase confidence when module or script exists and dependencies are present.
• Capture evidence for env variables, config files, or known server arguments.
• Penalise ambiguous invocations (e.g., python -c "..." without persistent service).

Edge cases

• Supervisors launching multiple Python workers fall back to Supervisor classification with Python listed as a child.
• Conda environments use different directory structures; look for conda-meta directories.
• Alpine and distroless images may ship python symlinks without standard libraries — confirm script presence before final classification.

Related

• Runtime Detector Overview — shared contracts, scoring, calibration.
• Supervisor detector — multi-worker Python deployments.
• Entry-Point Runtime — Ruby — sibling interpreted-runtime detector with comparable server/worker patterns.