Limits of Flask's application factory for safe upgrade recovery

Question

Flask's application factory pattern is documented as a way to create multiple application instances with different configurations, which can isolate an upgraded version from the running production instance. However, Flask core provides no built-in upgrade rollback, health-check, or atomic recovery mechanism; those concerns remain outside the framework.
When moving from Flask 2.x to 3.x, breaking changes in import paths and removed legacy helpers can cause an application to fail at import time. The factory pattern supports instantiating a candidate app for testing, but it does not define behavior for shared external state such as database schemas managed by Flask-Migrate, nor does it guarantee that extension initialization order or app.config defaults remain compatible across minor versions.
Does the factory pattern provide any documented boundary that prevents a partially initialized upgraded instance from serving traffic, or is process-level isolation entirely the responsibility of the WSGI server? What limits exist between configuration isolation and shared persistent state when using separate factory instances for staging and production? Is there a documented Flask behavior that determines whether an import-time failure in a factory-created instance can be distinguished from a runtime failure after the instance has begun serving requests?

Muntasir · Answer

Answer
No, the Flask application factory does not define a runtime boundary that prevents a partially initialized upgraded instance from serving traffic; that responsibility is entirely on the WSGI server and process isolation.
Documented limits

Configuration isolation is achieved by passing a distinct config object to each factory call, but any shared external resources such as a database schema are not isolated between instances.
Import‑time failures (e.g., import errors in factory code) raise during app creation and stop the server from starting, whereas runtime failures occur after the server is running and are handled by normal request error handling.
Flask core documentation states the factory must return a fully initialized app before the server starts; there is no built‑in health‑check or rollback API.

Steps for safe upgrade recovery

Run the factory in an isolated process (e.g., a separate script) and verify that an import error prevents the server from launching.
Configure the WSGI server to run a single process per instance so that no shared state from a partially initialized app can affect production.
Execute Flask‑Migrate upgrade on the target database before starting the new instance to ensure schema compatibility.
Confirm that the new instance does not receive traffic until the import‑time check succeeds and the schema is up‑to‑date.

Is the upgraded instance isolated at the process or container level from the production instance?

Limits of Flask's application factory for safe upgrade recovery

1 answer

Answer

Documented limits

Steps for safe upgrade recovery

Your perspective belongs here.

0 question comments