Flask development server reloader activation when FLASK_ENV=development and FLASK_DEBUG=0

Short answer

Yes: FLASK_DEBUG=0 wins. The reloader is tied to debug mode, and an explicit FLASK_DEBUG value takes precedence over FLASK_ENV. With FLASK_ENV=development FLASK_DEBUG=0 flask run, the reloader does not start. By default the reloader watches imported Python modules only — templates and static files do not trigger a restart unless you opt in with --extra-files. And the behavior is identical whether you use an application factory or a module-level app object.

Why FLASK_DEBUG=0 overrides FLASK_ENV=development

On Flask versions before 2.3, FLASK_ENV=development enabled debug mode only when FLASK_DEBUG was unset. It acted as a default, not a mandate. As soon as FLASK_DEBUG has any explicit value — including 0 — that value decides debug mode, and the reloader follows debug mode. So the documentation's claim that development mode enables the reloader is true only in the absence of an explicit FLASK_DEBUG.

Version caveat: FLASK_ENV was deprecated in Flask 2.2 and ignored entirely in Flask 2.3 and later. On a modern install, FLASK_ENV=development does nothing at all and FLASK_DEBUG (or flask run --debug) is the only control. Check your version before reasoning about precedence:

pip show flask

To confirm the behavior on your machine:

FLASK_ENV=development FLASK_DEBUG=0 flask run

Watch the startup output. With debug enabled you see a line like Restarting with stat; its absence confirms the reloader is off. Edit a .py file — no restart should occur.

Which files trigger a restart

The Werkzeug reloader (which flask run uses under the hood) watches the Python modules that were actually imported by the running process — effectively your .py files. It does not watch:

• Jinja templates (templates/*.html)
• Static assets (CSS, JS, images)
• Config files, .env, or data files

This is usually fine: in debug mode, templates are re-rendered per request, so template edits show up on the next browser refresh without any server restart. If you genuinely need a full restart when a non-Python file changes (for example, a YAML config loaded once at startup), pass it explicitly:

flask run --debug --extra-files config/settings.yaml templates/base.html

Verify with two quick experiments: run FLASK_DEBUG=1 flask run, touch a template, and observe no restart; then repeat with --extra-files pointing at that template and confirm the server restarts on edit.

Application factory vs module-level app

No difference. The reloader operates at the Werkzeug server layer, below Flask's app construction. It spawns a subprocess, re-imports your modules when a watched file changes, and then lets flask run locate the app again — whether that means calling create_app() or importing a module-level app. The set of watched files is "whatever Python files got imported," which is the same either way. One practical side effect for factories: module-level side effects (open files, background threads, DB connections created at import time) run again on every reload, so keep heavy initialization inside the factory or request handlers.

Practical recommendations

1. On Flask 2.3+, drop FLASK_ENV from your scripts and use FLASK_DEBUG=1 or --debug alone.
2. Never rely on FLASK_ENV for safety in production-like environments — explicitly set FLASK_DEBUG=0 (or simply don't set it) so the debugger and reloader stay off.
3. Use --extra-files sparingly; the default stat-based reloader rescans the watch set on a timer, and very large sets get sluggish. If the watchdog package is installed, Werkzeug uses it and scales better.

The one detail that could change this advice is your installed Flask version — if pip show flask reports something older than 2.2, the FLASK_ENV precedence rules above apply; on 2.3+ the variable is simply dead weight.