Sylius deployment: production, cache and security
The Sylius documentation on deployment, production performance, cache and security is scattered, and the public index I checked on 1 November 2026 lists installation and configuration pages but no dedicated production deployment page. In practice, you follow the Symfony deployment and performance guides, then add what is specific to Sylius: workers, asset builds and channel hostnames. The order of the steps matters more than any single setting.
I host and maintain Sylius shops, so I have an interest in the subject. Everything below can be checked in the linked sources and applied by whoever runs your server.
What the Sylius documentation says about production
The public documentation index covers requirements, installation with or without Docker, and basic configuration. Parts of the wider book were not publicly readable when I checked, so a page may exist behind them. The older 1.14 page on environments gives the basic idea: prod uses proper caching, is much faster than other environments, calls live APIs and sends real emails. The installation guide adds that the worker should run under a process manager such as Supervisor in production. Everything else comes from Symfony, since Sylius is a Symfony application.
Sylius deployment, step by step
The Symfony deployment guide sets the sequence, and the table adds why each step matters to a shop.
| Step | Command or setting | What goes wrong otherwise |
|---|---|---|
| Environment | Real variables or composer dump-env prod | Slower requests, or secrets in the wrong place |
| Dependencies | composer install --no-dev --optimize-autoloader | Development tools on a live server |
| Assets | Front-end build, for example npm run build | Broken pages after a release |
| Database | Migrations | Code expecting columns that do not exist yet |
| Cache | APP_ENV=prod APP_DEBUG=0 php bin/console cache:clear | A slow first visitor, or stale configuration |
| Workers | messenger:stop-workers | Background tasks running old code |
Two remarks. Symfony advises keeping APP_SECRET unique, private and stable across deployments, because changing it invalidates signed URIs and remember-me cookies. And the guide recommends a staging environment, tests and the ability to roll back. For a shop, staging is more than comfort: the prod environment sends real emails and calls live payment APIs, while the Sylius installation guide notes that email delivery is off by default in test, dev and staging. Never test a release by placing orders on the live configuration without a plan.
One thing does not belong in that sequence: fixtures, which the docs describe as mainly for testing. They are not a deployment step for a live shop.
Performance and cache: the settings with the most effect
The largest gains usually come before any extra infrastructure, and they sit in PHP. The Symfony performance page recommends OPcache with preloading, opcache.memory_consumption=256, opcache.max_accelerated_files=32531 and opcache.interned_strings_buffer=32, a realpath cache of 4096K, and an authoritative class map through composer dump-autoload --no-dev --classmap-authoritative.
It also recommends opcache.validate_timestamps=0, which carries a condition people miss: from then on you must clear OPcache after each deployment, because the command line and web processes do not share it. A site that seems to ignore a release has often fallen into exactly this.
The database comes next, once the catalog or customer base is large. The Sylius performance guide for 1.14 reports pages up to 70% faster with fetchJoinCollection on 3 million customers, while warning it can slow small tables. Its page on indexes mentions about 10% on a customer list and says indexes are for huge tables. These are old figures for a specific case, not a promise for your shop. Measure your own slow pages first.
Workers: the part specific to Sylius
The docs state that catalog promotions run through Symfony Messenger, so a stopped worker means discounts that never apply. The Messenger documentation sets out the production rules: keep workers alive with Supervisor or systemd, limit their lifetime with options such as --time-limit=3600, since long-running workers can leak memory, and run messenger:stop-workers after the new code is on disk and the cache is warm. Sylius 2 also has payment request transports, as the 2.0 upgrade guide records, so check how yours is configured.
Security in production
Start with the version: Sylius 1.14 loses security support on 31 December 2026, and the October 2026 patches are 1.14.21, 2.1.17, 2.2.12 and 2.3.2. Add a hostname on each channel or a strict trusted_hosts, following the 2.3 upgrade notes. Beyond that, the usual disciplines apply: APP_DEBUG off, secrets outside the repository, restricted admin access, and tested backups, including uploaded media. A backup you have never restored is a hope more than a backup.
When you should not run this yourself
A managed Platform as a Service can be a better choice than your own server if you have no one to watch it at night and your needs are standard. Conversely, a dedicated server makes sense when traffic or specific integrations justify it. I moved the shop Coucouroucoucou to a dedicated server during its takeover, and that was right for that shop, not a universal recommendation.
Whoever runs your deployment, ask them to show the rollback procedure and the last backup restore, and to explain what happens to orders placed during a release. If you would like me to look at yours, describe your setup through my Sylius developer page; I also offer hosting and maintenance. I reply within 24 working hours.