A caching layer for the Strapi REST API. It injects a middleware that stores GET
responses, keyed by route and query, and invalidates them when the underlying
content changes — so you serve cached responses without serving stale ones.
Cached content lives in a provider (in-memory, Redis, or your own). What gets cached, and for how long, is described by a strategy in your plugin config.
- Pluggable providers. In-memory by default; Redis via
@strapi-community/provider-rest-cache-redis. Custom providers implement theCacheProviderabstract class. - Per-content-type and per-route caching. Cache a list of content types with
their default routes, or declare custom routes with their own
maxAge,paramNamesand key strategy. - Configurable cache keys. Key on query params (
keys.useQueryParams), specific request headers (keys.useHeaders), and — since 5.1.0 — on the authenticated caller (keys.useAuth), so two callers authorised for the same route do not share one entry. - Automatic invalidation through the document service. Since 5.1.0,
invalidation hooks
strapi.documents()rather than HTTP routes, so it catches GraphQL mutations, admin panel edits, scheduled Content Releases and any customstrapi.documents()call — not only REST writes. Related content types can be purged alongside (clearRelatedCache). - Request coalescing. Since 5.1.0, N concurrent misses on the same key make one call to the origin and the rest wait on it. Matters on cold start, right after a purge, and at TTL expiry.
- ETag and
304 Not Modifiedsupport (enableEtag). X-Cacheresponse headers —HIT,MISS,HITPASS(enableXCacheHeaders).- Hitpass. A per-request predicate that bypasses the cache entirely. The
default bypasses any request carrying an
Authorizationheader or a cookie. - Admin dashboard. Since 5.1.0, Settings → REST Cache shows the resolved strategy, live entry counts per content type, and purge controls.
- Homepage widget. Since 5.1.0, a summary of what the cache currently holds.
- Content-manager controls. Since 5.1.0, a cache panel on the edit view plus purge actions on the edit and list views.
- Programmatic purging. Admin routes and internal services, plus an opt-in
content API purge endpoint (
enableContentApiPurge).
- Strapi
>= 5.0.0 - Node
>= 20
Looking for Strapi v4? Use the legacy package. Looking for Strapi v3? Use strapi-middleware-cache.
Install the plugin.
npm:
npm install @strapi-community/plugin-rest-cacheyarn:
yarn add @strapi-community/plugin-rest-cachepnpm:
pnpm add @strapi-community/plugin-rest-cacheThen list the content types you want cached in ./config/plugins.js:
module.exports = {
'rest-cache': {
config: {
provider: {
name: 'memory',
options: {
maxSize: 32767,
},
},
strategy: {
contentTypes: [
'api::category.category',
'api::article.article',
'api::homepage.homepage',
],
},
},
},
};That caches the default find and findOne routes of those content types for one
hour (maxAge, in milliseconds) and purges them when their content changes.
For Redis, install @strapi-community/plugin-redis and
@strapi-community/provider-rest-cache-redis alongside the plugin and set
provider.name to redis — see the
installation guide.
Full documentation lives at strapi-community.github.io/plugin-rest-cache.
- Installation
- Provider configuration — memory, redis, custom
- Strategy configuration — content types, custom routes, cache keys, debug mode
- Services and admin routes
Contributors and maintainers are wanted. See CONTRIBUTING.md for the repo layout, how to run the playgrounds, and how to run the test suites. Bugs and feature requests go in issues.
See the LICENSE file for licensing information.
