SncRedisBundle: Redis behind a Symfony service, not a global client

One bundle, two client implementations, and a recommendation

SncRedisBundle integrates Predis and PhpRedis into your Symfony 6.4 or later application, providing a fast and convenient interface to Redis.

The two-client design is the first thing to understand, because it determines what you write in your own code. The PhpRedis extension is a compiled C extension for PHP, and Predis is a pure PHP Redis client. The bundle supports both, and the readme is clear about the preference:

Using the native PhpRedis extension is recommended as it is faster and the main development platform for the project. If the extension is not available and cannot be installed in your environment, Predis is considered a safe and portable alternative, and the integration should be functionally identical.

That is a well-chosen default. A PHP deployment on a hosting provider you do not control may not let you install extensions, and a pure PHP client means the bundle still works. The cost is that the two paths are not exactly the same, and the readme's phrase should be functionally identical rather than identical is doing some work.

The framing of the whole project is worth noting too. This is a bundle, a Symfony-specific integration, and the top-level entries are a `src/` directory with the bundle code, `tests/`, `docs/`, `composer.json`, and the quality tooling: `phpcs.xml.dist`, `phpunit.xml.dist` and `psalm.xml.dist`. The presence of a Psalm configuration is a good sign, because a static analyser is what catches the type mismatches that come from having two client implementations behind one interface.

It is MIT licensed, the default branch is `master`, and the release history is a steady 4.x line, 4.13.1 on 2026-08-02, 4.13.0 on 2026-07-29 and 4.12.0 on 2026-06-12, with the last push on 2026-08-03.

Installing it is one Composer command

The installation section of the readme is two lines long, which is what you would expect for a bundle.

composer require snc/redis-bundle

That is the whole thing for the application side. The bundle registers its services, and your code asks the container for a Redis client rather than building one.

That distinction is the substance of the bundle. A Symfony bundle for Redis is not just a wrapper around `new Redis()`; the value is in the configuration, in the connection profiles, in the ability to point the same code at different Redis servers in different environments, and in having the client managed by the container so it is a service with a lifecycle rather than a global that a class reaches for.

The documentation is kept in a `docs/` directory in the repository rather than only on a website, and the readme points there directly. There is also an `UPGRADE.md` file at the root, which is worth reading before you bump the version, because a bundle that supports two client implementations and multiple Symfony versions tends to have configuration changes between minor releases.

The `Procfile` at the top of the repository is a small but revealing file. A Procfile is a convention for describing process types, and its presence points at the development setup rather than the application, which is where the next section goes.

Running the tests needs a fleet of Redis processes, so the project uses Nix

The contributing section explains the development setup, and it is unusual enough to be worth quoting closely.

Running the full test suite requires PHP installed with certain PHP extensions and a Redis server, as well as overmind to start the fleet of Redis processes. Because of this, the project uses Nix for local development.

The workflow is: install Nix, make sure you are in the directory with SncRedisBundle, then run:

nix shell

to install and enter the development environment. Once there, you can run:

composer update # install php package dependencies
overmind start & # start redis fleet
php vendor/bin/phpunit # run tests, or anything else you want with php binary

The reason for the fleet is the subject matter. Testing a Redis integration properly means testing against configurations that matter in production, and those include a Redis with authentication, a Redis with TLS, a Redis with a sentinel setup, and a Redis cluster. A single local Redis cannot express those, so the test suite starts a set of Redis processes with different configurations, and overmind is the tool that supervises them and shows their output together.

That is a much more thorough test setup than most bundles have, and it explains the `flake.nix` and `flake.lock` files at the root. Nix pins the entire development environment, including the PHP version and the extensions, which means a contributor's machine and CI get the same toolchain, and the `nix shell` command needs no per-contributor setup beyond having Nix installed.

The `scripts/` and `tests/` directories in the listing complete the picture, and there is a `docs/` directory that is the actual user documentation.

Two clients behind one interface, and the cost of that abstraction

The decision to support both Predis and PhpRedis has consequences that go beyond the install line, and they are worth working through before you commit.

The upside is portability. A PHP application that has to run on a managed host with a restrictive extension policy, on a shared host where you cannot compile anything, and on a container image you build yourself, has one code path rather than two, and the client choice becomes a deployment detail rather than an architectural one. That is a real benefit and it is why the bundle supports both rather than insisting on the extension.

The downside is that the abstraction is only as good as its common denominator. Predis and PhpRedis do not have identical surfaces. Predis is an object-oriented client with command methods, PhpRedis is a thin procedural extension where every command is a method with an argument shape of its own, and a few commands exist in one and not the other, or behave differently around error handling and binary safety. A bundle that hides this has to either narrow the API to what both can do, or expose the differences and let you opt out of portability for a specific client.

That is why the readme's claim that the integration should be functionally identical is worth reading carefully rather than accepting. Functionally identical means the common operations behave the same, and it does not mean every command of one client is reachable through the other. If your application needs a command that only one of the two provides, that is where the abstraction will show its edge.

The `psalm.xml.dist` configuration is worth noting in that context. A static analyser on a codebase whose public surface is an interface implemented by two different third-party clients is exactly the tool that catches a method that one of them does not satisfy, and the presence of the configuration suggests the maintainers run it for that reason.

There is also a performance dimension, and the readme is direct about it: the native extension is faster, and the extension is the main development platform, which means the fast path is the one that is continuously exercised, and the pure PHP path is the one that is functionally covered but not performance-characterised.

Why a bundle at all, and where it is the wrong tool

The first case is a project that is not on Symfony. The bundle registers services, uses the container, and integrates with the framework's configuration and lifecycle. A Laravel, Django or plain PHP application would use the Predis or PhpRedis client directly, which is a two-line difference, and the bundle adds nothing.

The second case is an application that needs more than one Redis with a specific topology and wants to manage the connections itself. The bundle is about giving you a configured client, and if your requirement is a connection pool with health checks, failover logic and per-request routing, that is a different layer and possibly a different library.

The third is a team that has already standardised on a Symfony cache or session store backed by Redis through the framework's own integration. Symfony has its own Redis support for the session and the cache, and if you are only using Redis for those, the framework's configuration is enough and the bundle is redundant.

The fourth is a project that does not want a Redis client at all. The bundle exists to make Redis convenient, and there are cases where the right answer is to not have Redis, and where adding a bundle makes the architecture worse rather than better.

A practical note on the two clients. The readme recommends the extension, and if you follow that advice you should verify the extension is present in every environment your application runs in, including CI, because the configured client requires its dependencies; do not assume a missing extension will silently switch the application to Predis. The alternative is to check which client is active at startup, so a misconfigured environment is loud rather than slow.

The last point is version discipline. The bundle requires Symfony 6.4 or later, and its own minor versions move fairly often, 4.12.0 in June and 4.13.1 in August. Reading `UPGRADE.md` before bumping is the cheap way to avoid a surprise in a deployment.

Editorial conclusion

SncRedisBundle fits a Symfony application that needs Redis configured once, injected where it is used, and supported across both a native extension and a pure PHP client, and it fits a team that wants the two client implementations to be interchangeable. It does not fit a project that is not on Symfony, or one that wants to manage its own connection lifecycle with a different abstraction. Before you adopt it, read `docs/` and the `UPGRADE.md` file at the root, and note that the recommendation is to use the native PhpRedis extension where it is available, with Predis as the portable fallback.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. snc/SncRedisBundle on GitHub