The Application Context

This is similar to the The Request Context, which keeps track ofrequest-level data during a request. A corresponding application contextis pushed when a request context is pushed.

The application object has attributes, such asconfig, that are useful to access within views and. However, importing the app instancewithin the modules in your project is prone to circular import issues.When using the app factory pattern orwriting reusable orextensions there won’t be an app instance toimport at all.

Flask solves this issue with the application context. Rather thanreferring to an app directly, you use the proxy, which points to the application handling the current activity.

Flask automatically pushes an application context when handling arequest. View functions, error handlers, and other functions that runduring a request will have access to current_app.

Flask will also automatically push an app context when running CLIcommands registered with Flask.cli using @app.cli.command().

The application context is created and destroyed as necessary. When aFlask application begins handling a request, it pushes an applicationcontext and a . When the requestends it pops the request context then the application context.Typically, an application context will have the same lifetime as arequest.

See The Request Context for more information about how the contexts workand the full life cycle of a request.

If you see that error while configuring your application, such as wheninitializing an extension, you can push a context manually since youhave direct access to the app. Use in awith block, and everything that runs in the block will have accessto current_app.

If you see that error somewhere else in your code not related toconfiguring the application, it most likely indicates that you shouldmove that code into a view function or CLI command.

The application context is a good place to store common data during arequest or CLI command. Flask provides the for thispurpose. It is a simple namespace object that has the same lifetime asan application context.

Note

The g name stands for “global”, but that is referring to thedata being global within a context. The data on g is lostafter the context ends, and it is not an appropriate place to storedata between requests. Use the session or a database tostore data across requests.

A common use for is to manage resources during a request.

For example, you can manage a database connection using this pattern:

During a request, every call to will return the sameconnection, and it will be closed automatically at the end of therequest.

You can use LocalProxy to make a new contextlocal from get_db():

Accessing db will call get_db internally, in the same way that works.

If you’re writing an extension, g should be reserved for usercode. You may store internal data on the context itself, but be sure touse a sufficiently unique name. The current context is accessed with. For more information seeFlask Extension Development.

The application will call functions registered with when the application context ispopped.

If signals_available is true, the following signals aresent: , appcontext_tearing_down, and.