This review tests Sylius 2.2.7 against the question a feature-comparison table never asks: does your team have the Symfony depth to build what the box doesn’t ship? The findings below are checked against Sylius 2.2.7, PHP 8.2+, Symfony ^7.2, Node ^20/^22, and the sylius/mcp-server-plugin at 0.2.0, current as of July 2026.
Who should shortlist Sylius in 2026, and who should not
Shortlist Sylius if you have a Symfony-capable engineering team building a commerce domain with genuinely non-standard business rules — the kind a packaged cart models badly — and you’re willing to write PHP/Symfony code to cover whatever plugins don’t. Skip it if your team has no in-house Symfony capacity and you want a configurable, merchant-ready store out of the box, or if you need B2B, role-based access control (RBAC) or request-for-quote (RFQ) workflows without budgeting for a commercial add-on.
Sylius’s own GitHub repository (opens in a new tab) describes the project as a “Headless open-source eCommerce platform on top of PHP/Symfony/API Platform.” It’s MIT-licensed and carries roughly 8.5k stars — a permissive license with no source-available clause to negotiate around.
That popularity doesn’t show up in usage-share measurements. w3techs measured Sylius’s install base at under 0.1% of tracked ecommerce websites (opens in a new tab) as of July 2026. Treat that number with a caveat: w3techs fingerprints storefront markup, and a large share of real Sylius deployments run the admin and API layer behind a fully custom or headless frontend that leaves no detectable Sylius signature. Low market share here likely means “hard to fingerprint,” not “rarely deployed.”
This review exists to test one hypothesis: that Sylius fits bespoke commerce domains with strong developer modelling, and that its failure boundary is teams lacking Symfony capability who expected a turnkey store. Everything below is evidence for or against that claim.
flowchart TD
A[Evaluating Sylius] --> B{In-house Symfony<br/>experience today?}
B -- No --> C[Skip: budget for Symfony<br/>hiring or a packaged cart instead]
B -- Yes --> D{Business rules are<br/>genuinely non-standard?}
D -- No --> E[Skip: a configurable cart<br/>ships faster for standard rules]
D -- Yes --> F{Need B2B/RBAC/RFQ/<br/>marketplace workflows?}
F -- Yes --> G[Shortlist, and budget<br/>Sylius Plus from EUR800/yr GMV]
F -- No --> H[Shortlist Community Edition]
You should now see: a one-sentence verdict on whether your team’s Symfony capability and business-rule complexity clear Sylius’s bar.
What Sylius Community Edition ships free, and what Sylius Plus gates behind a GMV price
Sylius Plus (opens in a new tab), the commercial edition, is priced from €800 per year on a model based on the store’s gross merchandise volume (GMV). Sylius sells it as a full bundle or as individually purchasable modules, so a team can license only the piece it needs rather than the whole commercial layer.
The module boundary is exact, and it matters more than the headline price. B2B Suite, Marketplace Suite, RBAC, returns merchandise authorization (RMA), multi-source inventory, partial shipment, loyalty, RFQ, product configurator, subscriptions and advanced multi-store all sit behind Plus. None of them is purchasable a-la-carte inside the free core, and none of them exists in the Community Edition codebase to extend — they aren’t there at all.
Community Edition is not a stripped-down demo; it’s the actual framework. It models the commerce domain in PHP/Symfony code and ships a working admin panel plus a basic, themeable Twig storefront. What it is not is a configurable packaged cart with B2B, RBAC and RFQ built in and waiting behind a settings toggle.
That split is the real driver of total cost of ownership. Every business rule that Sylius Plus doesn’t cover and Community Edition doesn’t ship becomes bespoke Symfony engineering time, not a plugin purchase. A team that budgets only for the Plus subscription and assumes the rest is configuration will find that assumption wrong the first time a rule falls outside both.
The common failure mode: a team scopes a B2B rollout — quote requests, tiered pricing, role-based admin permissions — against Community Edition, then discovers those modules are absent from the codebase entirely, mid-build. Map the required workflow list against the current Sylius Plus module page (opens in a new tab) before scoping, not after.
Every price and module boundary here is a snapshot: Plus pricing and packaging are dated and move. This review checked the module set as of July 2026 — re-verify before you sign anything against it.
flowchart LR
subgraph Community Edition - MIT, free
A[Admin panel]
B[Basic Twig storefront]
C[Core commerce domain in code]
end
subgraph Sylius Plus - from EUR800/yr GMV
D[B2B Suite]
E[RBAC]
F[RFQ]
G[Marketplace Suite]
H[RMA, multi-source inventory,<br/>partial shipment, loyalty,<br/>subscriptions, advanced multi-store]
end
C -.extend in code.-> A
C -.no path without license.-> D
You should now see: the exact module and price tier your required B2B, RBAC or marketplace workflow forces you onto.
The architecture behind Sylius 2.2: a Symfony core wearing a storefront
The 2.2.x line requires PHP 8.2 or newer with the gd, exif, fileinfo, intl and sodium extensions, Node ^20 or ^22, and one of MySQL 8.0+, MariaDB 10.4.10+ or PostgreSQL 13.9+. It also expects a Unix-based OS — Windows is supported only through WSL, per Sylius’s own system requirements doc (opens in a new tab).
That floor moves between minors, not just majors. Sylius’s 2.2 release line raised its minimum Symfony requirement from ^7.1 to ^7.2, a change documented in the project’s own UPGRADE-2.1.md file on the 2.2 branch (opens in a new tab) — not in the headline changelog. A tutorial written against 2.1 that still cites Symfony ^7.1 is already wrong for 2.2.
Despite Sylius’s “headless” framing, the Sylius-Standard distribution — the one most getting-started guides install — bundles a full Symfony admin panel and a themeable Twig storefront by default. “Headless” here describes an architecture direction, not what ships when you run the installer.
That direction is visible but unfinished. An open GitHub RFC, issue #13143 (opens in a new tab), proposes removing the theme-bundle coupling from the admin package as the project pushes further toward an API-first core. It’s a proposal under discussion, not a shipped change — plan around what 2.2 ships today, not what the RFC describes.
The practical consequence: most real Sylius deployments replace the bundled storefront with a custom or fully headless frontend built against the API Platform layer. Treat the default Twig storefront as a working backend testing surface, not a production design.
flowchart TB
A[MySQL 8.0+ / MariaDB 10.4.10+<br/>/ PostgreSQL 13.9+] --> B[Symfony ^7.2 core]
B --> C[API Platform layer]
C --> D[Admin panel - Symfony/Twig]
C --> E[Bundled Twig storefront<br/>- reference implementation]
C --> F[Custom/headless frontend<br/>- what most production sites build]
style E stroke-dasharray: 5 5
You should now see: the exact PHP/Symfony/Node/database floor to pin for 2.2.x, and that “headless” is a direction, not a default.
Where Sylius earns its keep as a framework, not a cart
The Community Edition core is genuinely MIT-licensed, not source-available with a commercial carve-out. A team can fork it, self-host it or resell a distribution built on it without negotiating an agreement with Sylius first — a real difference from platforms that gate self-hosting behind a paid tier.
API Platform-backed boundaries give integrators a documented, generated API surface to build against, instead of reverse-engineering admin form behaviour to work out what a write operation actually touches.
Sylius’s case studies page (opens in a new tab) lists named production implementations: di-soric Group (B2B content and commerce with ERP integration), Tediber (a five-month migration for an online mattress retailer), and HBX (a fashion retailer operating 160 stores across 15 countries). These are vendor-published outcomes, not independently audited ones, so read them as evidence the platform has shipped in production at scale, not as a guarantee of your own timeline.
The real differentiator is that the commerce domain is expressed directly in PHP/Symfony code. A genuinely non-standard business rule is something you build, not something you wait on a plugin marketplace to cover.
You should now see: the specific, verifiable reasons a framework model beats a packaged cart for a bespoke commerce domain, independent of price.
Where the fit weakens: the Symfony-capability wall and the packaged-cart mismatch
The primary failure boundary is a team without in-house Symfony experience adopting Sylius because it’s marketed as “open source Symfony ecommerce.” The demo store runs fine; the stall comes later, once a business rule shows up that the admin UI and existing plugins don’t cover. At that point every uncovered rule is bespoke engineering work, on a stack the team doesn’t already know well.
The Symfony version floor has already moved once inside the current major line — ^7.1 to ^7.2 in 2.2 — and that detail lives in the per-release UPGRADE-x.x.md file (opens in a new tab), not the headline changelog. Plan upgrade time around reading that file for your target version, not around skimming release notes.
The bundled storefront is a reference implementation, not a production design. A stakeholder who browses demo.sylius.com (opens in a new tab) or the Sylius-Standard default theme and assumes that’s what launches is planning against the wrong artefact — budget a separate frontend build from day one.
There’s also vendor-longevity context worth weighing if you’re considering a Plus subscription for its SLA-backed support. Third-party company data from Latka (opens in a new tab) reports the company behind Sylius at approximately $3.6M revenue in 2025, with a 33-person team and no external venture funding raised. That’s self-reported data to an aggregator, not audited disclosure — treat it as low-confidence context on vendor size, not a verdict on stability.
You should now see: whether your team’s Symfony depth and business-rule complexity land inside or outside Sylius’s real fit, before committing budget.
Scoring Sylius on the CodeNx modernity and AI/agent-readiness rubric
Modernity score components, and how Sylius rates on each: maintained runtime and framework posture scores well — PHP 8.2+, Symfony ^7.2, an actively released 2.2.x line. API-first boundaries via API Platform score well too, and the bundle/plugin extension model keeps customisation out of core files rather than forcing patches to it. The open RFC process — issue #13143 (opens in a new tab) on removing theme-bundle coupling — signals an active architecture direction, but it’s also unfinished business: the headless/storefront boundary the project markets isn’t fully built yet.
AI/agent readiness gets a more mixed score, and it’s worth breaking down rather than stating as one number. Sylius maintains an official first-party MCP server — Model Context Protocol, the emerging standard for connecting LLM agents to external tools — sylius/mcp-server-plugin (opens in a new tab), MIT-licensed and versioned 0.2.0, released 2026-02-23 per Packagist (opens in a new tab).
It exposes roughly 14 pre-built tools (opens in a new tab) for product search, variant lookup and checkout steps. That earns real credit under “official AI, MCP, agent tooling exists” — this isn’t a bolted-on chatbot plugin from a third party.
Points get withheld for what the tool set doesn’t do. The documented tools operate in guest-mode only (opens in a new tab), driving anonymous storefront checkout rather than authenticated admin writes — updating stock, applying a promotion, issuing a refund. That directly discounts the rubric’s component for safe authenticated write operations and granular permissions, because that capability doesn’t exist in the plugin yet.
The plugin’s pre-1.0 version number, 0.2.0, further discounts confidence in its maturity even where the documented tool count looks respectable for a first release.
State the rubric’s own rule plainly: a platform isn’t “AI-ready” merely because a chatbot or plugin exists somewhere in its ecosystem. Sylius clears the “official first-party tooling exists” bar. It does not yet clear the “authenticated write operations” bar.
You should now see: which rubric component drove each point gained or withheld on both scores, and you could recompute the totals from the same evidence.
Production concern: the fixture and upgrade risk a Sylius feature table never shows you
Feature tables compare what a release does. They don’t show what happens when a routine-looking upgrade or a bulk data operation breaks in production, because that risk lives in operational detail, not the feature list.
The Symfony floor has already moved between Sylius minors once — ^7.1 to ^7.2 in 2.2 — and that fact lives only in the per-release UPGRADE-x.x.md file (opens in a new tab), not the top-line release notes (opens in a new tab). A minor version bump can fail CI on a version-constraint error the changelog never called out.
Bulk data generation has its own sharp edge. sylius:fixtures:load throws SQL uniqueness exceptions when a custom suite requests large randomised counts — for example, 100,000 shop_user fixtures — per a closed GitHub issue filed against Sylius 2.2.4. The root cause: example factories such as ShopUserExampleFactory generate fields like email through Faker without forcing uniqueness, so large counts collide.
Two operational lessons follow. Read the specific UPGRADE-x.x.md for your target minor before upgrading, and test the upgrade against a pinned composer.lock in staging first. Keep custom fixture counts modest, or patch the factory yourself, before you treat any generated-data load test as routine.
sequenceDiagram
participant Dev as Developer
participant CI as CI pipeline
participant Changelog as Top-line release notes
participant Upgrade as UPGRADE-x.x.md
Dev->>Changelog: Reads before bumping Sylius minor
Changelog-->>Dev: No mention of Symfony floor change
Dev->>CI: Bumps composer.json, pushes
CI-->>Dev: Fails on Symfony version constraint
Dev->>Upgrade: Reads UPGRADE-x.x.md (too late)
Upgrade-->>Dev: Symfony ^7.1 to ^7.2 documented here all along
You should now see: to check the per-minor UPGRADE file before any version bump, and to cap or patch bulk fixture generation before treating it as routine.
The five-question proof-of-concept checklist for a Sylius commitment
Run these five questions against your own team and codebase before committing budget to Sylius, not against the vendor’s marketing copy.
- Does your team have production Symfony experience today? Verify it by scoping one genuinely non-standard business rule end to end, not by installing and browsing the demo store.
- Does your required B2B, RBAC, RFQ or marketplace workflow exist in Community Edition, or does it force a Sylius Plus subscription? Check this against the current Plus module page (opens in a new tab) rather than general marketing copy.
- What exact PHP, Symfony, Node and database floor does your target 2.2.x patch require? Confirm it against that release’s own
UPGRADE-x.x.md, not an older tutorial or the headline changelog. - If you plan to use the official MCP server plugin (opens in a new tab), does your use case stay inside its guest-checkout scope, or does it need authenticated admin writes the plugin doesn’t yet expose?
- Have you load-tested
sylius:fixtures:loador your own data-import path at your real target volume, not just the default demo fixture set?
You should now see: five yes/no checks to run against your own Sylius proof of concept.
Limitations
This review draws on a companion hands-on install article for install-time evidence, but it did not independently test a production Sylius Plus deployment. The revenue and team-size figures in the vendor-longevity section are third-party self-reported data, not confirmed directly by Sylius. Every price, module boundary and version requirement cited here is a dated snapshot, current as of July 2026 — re-check each one against the primary source before you rely on it for a purchasing decision.