App context e request context

Flask runs your code inside a context, a temporary bubble holding the data your view needs. There are two flavors: an app context and a request context.

The application context tracks which app is active right now. It exists whenever Flask is doing work, even outside a real web request.

The request context wraps a single incoming request. It holds the URL, headers, and form data for that one visitor only.

When a request arrives, Flask pushes a request context, and an app context rides along automatically. So inside a view, both are always active.

The app context gives you current_app and the g object. Use them for config, the database handle, and other per-request shared data.

The request context gives you request and session. These describe the visitor: their path, query string, posted form, and cookies.

Splitting contexts means app-level work, like a startup script, can use current_app without pretending a fake web request exists.

Touch request with no active context and Flask raises a runtime error. The proxy has nothing real to point at yet.

Flask keeps contexts on a stack. Each is pushed when work starts and popped when it ends, so the right data is always on top.

A request context lives only for that one request. Once the response is sent, Flask pops both contexts and they vanish.

Think of it this way: the app context answers which app, and the request context answers which visitor. Inside a view you have both at once.

Let us sort the two contexts apart.

Two bubbles, two jobs: the app context says which app, the request context says which visitor. A request pushes both, so views always have each. 🎉