Sylius production requirements: PHP, workers, Redis
A Sylius 2.3 production deployment requires PHP 8.3 or later, a supported Symfony version (6.4, 7.4 or 8), a database, a web server, and a process manager that keeps Symfony Messenger workers running. Redis is not a hard requirement of the code, but it becomes a practical need when you run several servers or replace containers on each deployment. The hosting plan should be chosen after this list, never before.
Disclosure: I build and maintain Sylius shops, including their hosting, so I have an interest in this subject. I checked what follows on 1 November 2026, going to the source code when documentation pages did not settle the question.
Official requirements: PHP, Symfony and extensions
The most reliable statement of requirements is the code itself. The composer.json of the Sylius 2.3 branch requires PHP ^8.3, with the extensions dom, exif, fileinfo, filter, gd, hash, intl, json, simplexml and sodium. Sylius has also announced support for Symfony 6.4, 7.4 and 8, and API Platform 4.3 or 5.
The older requirements page (written for Sylius 1.13, so read it as background) asks for a memory_limit of at least 1024M and write access for the web server on var/cache, var/log and public/media. It mentions MySQL 8.0 or later by default and allows another database such as PostgreSQL. Sylius itself describes the product as on-premise by design, able to run wherever PHP, MySQL and Nginx or Apache are available.
Your version choice also has a deadline attached. Security support for Sylius 1.14 ends on 31 December 2026, for 2.2 on 31 March 2027, and 2.1 stopped on 30 September 2026. A host that cannot give you PHP 8.3 blocks the move to 2.3.
Workers: the requirement most often missed
A Sylius shop is not only a website answering requests. The Sylius-Standard .env file declares separate Messenger transports: a main one, one for catalog promotion removal and one for payment requests, each with a failure transport. If nothing consumes those queues, messages wait, and the resulting problems can look unrelated to their cause.
The Symfony Messenger documentation is explicit: you want one or more workers running at all times, under a process control system such as Supervisor or systemd. It recommends limits like --memory-limit=128M or --time-limit=3600 so that workers exit and get restarted before they grow too large. It also asks you to run messenger:stop-workers at each deployment, after the code is in place and the cache is warm, so that workers do not keep running old code.
This single point disqualifies many cheap hosting offers. If a provider cannot keep a process alive and restart it, your shop has no reliable place to run these queues.
Redis: useful, but know why you want it
The 2.3 composer file does not list the Redis extension, and in Sylius-Standard Redis appears only as a commented example. So a single server can start without it. The case for Redis comes from the architecture you pick.
Symfony notes that multi-host setups should use a shared cache adapter such as Redis, because the signal that stops workers relies on the application cache. It also warns that with a Redis transport, each worker needs a unique consumer name, otherwise a message can be handled more than once. The Railway template for Sylius, a third party source rather than official guidance, gives a concrete reason of another kind: containers are replaced at each deployment, so file sessions would empty shoppers' carts, and it keeps sessions in Redis.
| Component | Status | Basis |
|---|---|---|
| PHP 8.3 and listed extensions | Required for 2.3 | Composer file |
| Symfony 6.4, 7.4 or 8 | Required | Composer file and Sylius announcement |
| Messenger workers under Supervisor or systemd | Needed in practice | Standard project transports, Symfony documentation |
| Redis for cache and sessions | Optional on one server, recommended across several or with disposable containers | Symfony documentation, Railway template |
| Scheduled tasks | Needed in practice | Railway template: cancels unpaid orders, clears abandoned carts |
One honest limit: I could not read the current docs.sylius.com pages directly, and I found no official Sylius page that sets a server size or makes Redis mandatory. The Railway template suggests 2 GB of memory for the web role and 512 MB each for worker and scheduler. Treat those as a vendor's starting point and not as a Sylius requirement, then measure your own catalog.
The deployment sequence itself
The Symfony deployment guide gives the sequence: upload the code, set production variables and secrets, run composer install --no-dev --optimize-autoloader, compile assets, run database migrations, then clear and warm the cache. Add the worker restart to that. Keep APP_SECRET stable between deployments, since changing it invalidates signed URLs and remember me cookies. For the shop side of launch day, I keep a Sylius go-live checklist (in French).
When a full setup is more than you need
If you sell a few dozen products with simple rules and nobody to look after a server, Sylius may be the wrong tool, and a hosted platform could cost you less effort. Conversely, if you have an internal operations team, you may not need a provider at all: this article and the sources above are enough for a competent administrator. Sylius earns its running costs when your business rules justify them.
What to ask your host or provider
Ask who restarts workers when they crash, who is alerted, how a failed migration is rolled back, how backups are tested, and which Sylius version is planned after the support deadline. If you want those answered for your shop, look at my hosting and maintenance offer. On Coucouroucoucou, a Belgian Sylius shop I took over, the work included moving to a dedicated server without interrupting sales.