# Beaker adds sessions and object caching to a WSGI application

> Beaker is a Python session and caching library that ships as WSGI middleware with a choice of back-ends from memory and file to Redis and MongoDB, cookie-only sessions for clustered setups, and a reader/writer lock that stops duplicate cache creation.

**bbangert/beaker** — WSGI middleware for sessions and caching

- Repository: https://github.com/bbangert/beaker
- Website: https://beaker.readthedocs.org/
- Stars: 546 · Forks: 147
- Language: Python
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/bbangert-beaker

## Sessions and caching arrive as WSGI middleware

Beaker is a web session and general caching library that includes WSGI middleware for use in web applications, and the two halves are packaged together for a reason. The session layer needs a place to keep state between requests, and the cache layer is the mechanism that provides it, so the same storage machinery serves both.

The general caching side can store any Python object that can be pickled, for varying amounts of time, with optional back-ends chosen on a fine-grained basis. That is a general purpose object cache rather than an HTTP response cache, and the distinction decides where it fits in a stack: Beaker stores Python objects your application hands it, not the rendered responses of your views.

The history is worth one line, because it explains the shape of the library. Beaker was built largely on the code from MyghtyUtils, then refactored and extended with database support. The packaging reflects the same era and the same ecosystem: it is automatically used by Pylons and by TurboGears, both of which grew out of the same lineage, so a Beaker dependency is close to automatic in those frameworks and a deliberate choice everywhere else.

## Seven back-ends and one Container abstraction

The back-end list is the part that decides whether Beaker can be deployed in your environment. The documented set covers dbm, file, memory, memcached, Redis, MongoDB, and database, where the database back-end uses SQLAlchemy for multiple database vendor support.

That list spans the range from a single process to a fleet. The memory back-end is per-process and disappears with the process, the file and dbm back-ends are local disk, and memcached, Redis, MongoDB and the SQLAlchemy-backed option are network stores that several application instances can share.

The abstraction that holds them together is the Container object, which is extensible so that new back-ends can be supported. Around it sit two more features that shape how you use the library. Caches can be divided into namespaces, to represent templates, objects and other categories separately, and then keyed for different copies within a namespace. And the back-end, the keys and the expiration can be toggled per Cache object, so one application can keep a template cache in memory and a slow object cache in Redis at the same time.

The back-ends are registered as package entry points, so the manager for each one is loaded by name rather than imported by hand.

## Cookie-only sessions take the server out of the picture

Two session features deserve attention because they change the deployment story. The first is cookie-only sessions, which remove the need for a database or file back-end, and the README calls them ideal for clustered systems. When sessions live entirely in the cookie, an application running on several machines needs no shared session store, because there is no server-side session to share.

The second is that the cookies are signed, and the stated purpose is to prevent session hijacking and spoofing. Signing is what makes a cookie-only session viable: the client cannot edit the session payload without invalidating the signature, so a tampered cookie is rejected rather than trusted.

The trade-off is size. A cookie travels with every request, and the session data has to fit in the browser's limits, which is the usual reason cookie-only mode is reserved for small sessions. The README does not document the size threshold, so the practical approach is to keep cookie-only sessions for cases where the state is genuinely small and to fall back to a server-side back-end when it is not.

## The reader and writer lock stops two workers building the same key

One feature in the list is about a specific race rather than about speed, and it is the kind of detail that only appears in a library that has been used in production for a long time. Beaker uses a multiple reader, single writer lock system to avoid duplicate simultaneous cache creation, so when several workers miss the same key at the same time, one of them builds the entry and the others wait rather than each producing a copy.

Paired with it are the create functions, which support automatic call-backs to create new cache copies after expiration. That combination is the standard cache stampede defence: a miss triggers a regeneration instead of a hole, and the lock keeps the regeneration to one worker.

The other half of the design is the fine-grained control. Back-ends, keys and expiration can be toggled per Cache object, and caches can be namespaced and then keyed for different copies, so a template cache and a data cache can have different expiration policies and different storage. For an application with mixed workloads, that is more useful than a single global cache with one eviction policy, at the cost of a configuration surface that has to be understood before it is tuned.

## It installs as a package and plugs in through Paste

There is no install command in the README, but the package metadata describes the project fully enough to know what you are getting. The distribution is Beaker, version 1.14.1, it requires Python 3.8 or newer, and it declares no runtime dependencies at all:

```toml
[project]
name = "Beaker"
version = "1.14.1"
requires-python = ">=3.8"
dependencies = []
```

The integration mechanism is Paste filter factories, declared as entry points in the package metadata, one for a filter factory and one for a filter app factory, both pointing at the session middleware. The back-ends are entry points too, with the database manager and the memcached manager among those registered, so the backend for a given namespace is selected by name at configuration time.

The metadata also lists the classifiers, and they are dated in a useful way. The package declares itself at Development Status 5, Production/Stable, and supports Python 3.8 through 3.13, and the keyword list still includes the myghty name from the project it grew out of. The documentation lives on readthedocs, and the source repository is where the developer version is.

## Where Beaker is the wrong tool

The first limitation is structural and worth checking before anything else. Everything documented about Beaker is WSGI: the middleware, the Paste entry points, the classifiers. An application server built around ASGI, with its own middleware model, is not what this package describes, and the README says nothing about ASGI support.

The second is the caching model. Because the cache stores pickled Python objects, the value is tied to the Python version and the class definitions that produced it. A cache that outlives a deployment, holding objects pickled by an older release of your code, can fail to unpickle or, worse, unpickle into something whose meaning has changed. That is a normal property of object caches, but it means the cache is usually a performance layer you can throw away rather than a source of truth.

The third is the age of the design. The middleware and factory conventions, the MyghtyUtils lineage and the Pylons and TurboGears integration all point to a library shaped around a particular era of Python web development. It may well be exactly right for the applications that still use that stack, and it is a poor fit as a starting point for something new. The README's own feature list claims fast and reliable performance without evidence in the text, so treat that line as a claim rather than a measurement.

## Releases, licence and the shape of the project now

The maintenance picture is modest. Version 1.14.1 was released on 2026-05-30, and version 1.14.0 a week earlier on 2026-05-24, while the release before that, 1.13.0, dates from 2024-04-11. The last push to the repository was on 2026-05-30, and the repository is not archived. The pattern suggests maintenance in bursts rather than a steady stream.

The repository is a conventional Python package: a beaker directory for the code, a tests directory, a CHANGELOG, a MANIFEST.in, a pyproject.toml and a README.rst, with a .github directory for the workflows. Bugs are filed on GitHub and should be accompanied by a test case to retain current code coverage, and should arrive as a pull request. That policy is a small signal about the project's priorities, since the test suite is treated as something a fix has to maintain rather than something written afterwards.

On the licence, there is a discrepancy worth resolving before you ship anything. The package metadata declares BSD, and the classifier says BSD License, while the repository's licence field is recorded as a custom licence that GitHub cannot classify, with the LICENSE file in the repository as the reference. Read the LICENSE file, since the metadata and the repository disagree about how the project is licensed.

## Conclusion

Beaker fits a WSGI application that needs server-side sessions and a general object cache with pluggable storage, especially one that runs several app instances and wants cookie-only sessions so no shared session store is required. It does not fit an ASGI application, since the integration it documents is WSGI middleware and Paste filter factories, and it is the wrong tool if you need HTTP response caching rather than pickled Python objects. Before you adopt it, check three things: that your Python is 3.8 or newer, which the package metadata requires, that the back-end you pick is one of the registered entry points, database, memcached and the others listed in the package metadata, and that the licence text in the LICENSE file matches what you expect, because the package metadata declares BSD while the repository's licence field is recorded as a custom licence GitHub cannot classify. The current release is 1.14.1 from 2026-05-30 and the last push was on 2026-05-30.

## FAQ

### What is Beaker used for in a Python web application?

Beaker provides web sessions and general caching, delivered as WSGI middleware so it integrates with WSGI capable frameworks. The general caching side stores any Python object that can be pickled, for varying amounts of time, with back-ends chosen per cache object.

### Which cache back-ends does Beaker support?

The documented set is dbm, file, memory, memcached, Redis, MongoDB, and database, where the database back-end uses SQLAlchemy for multiple vendor support. New back-ends can be added through the extensible Container object, and the back-ends are registered as package entry points.

### What are cookie-only sessions in Beaker good for?

They remove the need for a database or file back-end, which the README describes as ideal for clustered systems, since there is no server-side session to share between instances. The cookies are signed, which is what prevents session hijacking and spoofing.

### Does Beaker work with ASGI applications?

The documentation and the package metadata describe WSGI middleware and Paste filter factories, and the package classifiers list WSGI and WSGI middleware as topics. The README does not mention ASGI support.

### What Python version does Beaker require and under what licence?

The package metadata requires Python 3.8 or newer and supports up to 3.13, and it declares no runtime dependencies. The metadata says BSD, while the repository licence field is recorded as a custom licence, so the LICENSE file in the repository is the reference to read.

## Sources

- [bbangert/beaker on GitHub](https://github.com/bbangert/beaker)
- [Issues](https://github.com/bbangert/beaker/issues)
- [Project website](https://beaker.readthedocs.org/)
- [README](https://github.com/bbangert/beaker/blob/master/README.md)
- [Releases](https://github.com/bbangert/beaker/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bbangert-beaker