FastAPI now has an official Redis integration. With the fastapi-redis-sdk, we worked closely with the FastAPI team on what a naturally integrated Redis experience should look like, following FastAPI’s dependency model instead of forcing Redis into patterns that feel foreign to the framework.
The result is a native way to use Redis in FastAPI, with connection management tied to the application lifecycle, sync and async dependencies out of the box, and caching that fits cleanly into dependency injection. It also brings practical HTTP caching behaviors and cache-control headers, so it goes beyond basic connectivity and makes common web patterns feel first-class.
The fastapi-redis-sdk can be used with all FastAPI flavors, self-managed, and FastAPI Cloud, the new managed platform for deploying and operating FastAPI apps. FastAPI Cloud is now in public beta, and Redis Cloud is available there as a native integration, giving users a straightforward way to connect an existing Redis database, or create a free one directly from FastAPI Cloud dashboard. This delivers a shorter path to production services and reduces effort with the ability to support caching today and more use cases under development through the fastapi-redis-sdk officially supported SDK.
Using the SDK
Installing the package is as easy as any other package available at PyPI:
Then to attach the SDK to the lifecycle of your app you need to call:
Caching data
At this point, you are ready to consume the caching functionality of the framework. You just simply use dependency injection and set up a caching rule:
So now you have everything handled for you:
- The GET endpoint is cached, with a time-to-live of 60 seconds, so repeated requests for the same user identifier get fetched by the Redis cache, rather than hitting the database
- The DELETE endpoint automatically invalidates any cache entries for the provided ID
- The PUT endpoint could do a piece of magic—if the storing operation is successful (and only if it is successful)—we would actually update the cache with the new stored value, saving the first get call after that
The eviction group, on the other hand, could be used to identify data that should be evicted together, which would help improve consistency of the cache in case some of the cached entries only make sense together. It comes at a cost, however, as in order to make the eviction operation atomic the data is stored in the same slot in case of a cluster environment.
To read more on caching, visit the caching section of our guide.
Rate limiting
In a similar way, you need to configure the SDK to watch for rate limiting rules:
Then it is as easy as:
Or if you’d like to handle both burst and sustained rate limiting you can stack two separate rate limit declarations with different scopes to ensure they are counted separately and do not overwrite each other:
More on rate limiting can be found in the rate limiting section of the online guide.
Configuration
The fastapi-redis-sdk follows the Pydantic Settings configuration model, as recommended by the FastAPI team, to ensure portability and type safety. Typically (on cloud environments such as FastAPI Cloud) the configuration parameters will be injected as environment variables; and as long as the names are correct they will be consumed automatically by the endpoints deployed.
So for cloud environments the configuration would look like:
On development environments you can have separate .env files:
A complete list of configuration parameters can be seen at the respective section of the guide.
Advanced recipes
When injecting the CacheBackend or RateLimitBackend in your endpoints (synchronous or asynchronous—it works for both) you are able to implement some advanced caching and rate limiting recipes, including but not limited to, the ones listed below.
Caching
Conditional caching: cache only when certain business rules are met
Cascade invalidations: across eviction groups or when eviction groups could not be used
Dynamic TTL: set the time-to-live based on the data itself
Of course all of these patterns could be used together for advanced use cases. See the section in the guide that concerns these topics for more.
Rate limiting
Limiting a downstream resource: when you want to protect a resource your endpoint depends on, and not the endpoint itself
Per-tenant fairness: when you have a noise tenant in a multi-tenant environment
Token budget: compute the cost at runtime based on usage
Try it today
If you’d like to try the SDK, check out the repository, the guide, and the PyPI package. We’d love for you to test it, share feedback, and suggest improvements or new features.
