How to Choose Open-Source Ecommerce Software

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

Updated September 2026.

WooCommerce fits a merchant who already has, or can hire, a WordPress developer and wants a theme-and-plugin storefront with no per-order fee. Magento Open Source fits a team with a real engineering budget that needs deep catalog and B2B logic, and can commit to a new major version every few years, because Adobe retires its patches on a clock nobody resets for you. Saleor, Medusa, Vendure, Sylius, and Spree fit a team treating commerce as an API, not a website. PrestaShop, OpenCart, and nopCommerce fit smaller catalogs where an agency or a host runs the server. Shopware sits in between: an open-source core with a commercial cloud edition on top. None of that is a features decision, since every project here can take an order, calculate tax, and send a receipt. The decision turns on one question: who runs this in three years, and what does it cost once the license stops being the expensive line, which for most buyers is on day one?

Open source against the hosted alternative

How to choose an ecommerce platform covers the full field, hosted SaaS included, and the small-business version runs the same decision on a tighter budget. Both treat Shopify, BigCommerce, Wix, and Squarespace as legitimate answers, because for most stores they are. This guide is for buyers who have already decided, or are seriously weighing, that they'd rather own the code than rent the platform.

That decision buys you three things a hosted platform takes off your plate: the servers, the PCI scope a hosted checkout absorbs, and the schedule on which patches ship. It buys back no platform fee, no forced roadmap, and code you can bend into any shape. Whether the trade is worth it depends less on the software than on whether you have, or will pay for, the team to run it.

Approach Who runs the servers Who owns PCI scope Where the real cost lands
Hosted SaaS The vendor Mostly the vendor, with a hosted checkout page Subscription and app fees
Self-hosted monolith (WooCommerce, Magento, PrestaShop, OpenCart, nopCommerce, Drupal Commerce) You, or your host You, scoped down if card fields stay off your server Hosting, patching, extensions, developer time
Headless engine (Saleor, Medusa, Vendure, Sylius, Spree, Bagisto) You, or the vendor's cloud tier You, unless you buy the managed cloud edition All of the above, plus the frontend you build

Key Facts: choosing open-source ecommerce software

What "free" actually costs

None of the numbers below live on a pricing page, because there isn't one. Here's a worked model for a store doing $30,000 a month at roughly 400 orders, comparing self-hosted WooCommerce, self-hosted Magento Open Source, and a hosted Shopify Basic plan for scale. Every figure is a stated assumption, not a vendor quote.

Cost layer WooCommerce, self-hosted Magento Open Source, self-hosted Shopify Basic, hosted (for scale)
Software license $0 $0 Bundled into the plan
Hosting (assumption) $60/month, managed WooCommerce hosting $250/month, server sized for MySQL and OpenSearch $19/month (Basic, annual)
Payment processing on $30,000 GMV About $990/month at roughly 2.9% plus $0.30/order About $990/month, same math About $870 with Shopify Payments; surcharge on another gateway
Developer and patching time (assumption) $300 to $600/month $2,000 to $4,000/month; the hiring pool is smaller and pricier $0, absorbed by the platform
Extensions and themes (assumption) $80 to $150/month $300 to $800/month amortized; extensions often run $200 to $2,000 each $80 to $150/month
PCI and security overhead (assumption) $0 to $500/year if card fields never touch your server $1,000 to $3,000/year if a QSA-assisted assessment is needed $0, handled by the platform
Realistic monthly total Roughly $1,400 to $1,900 Roughly $5,000 to $8,000 or more Roughly $1,000 to $1,300

Read that last row again: a small WooCommerce store can land within a few hundred dollars of a hosted plan once developer time is priced honestly, and Magento Open Source routinely costs more than the SaaS platform it was supposedly cheaper than. That's an argument for pricing self-hosting first, the discipline our software total cost of ownership guide applies to any category where sticker price isn't real price.

What to look for

Score every project on these six criteria: the first three decide whether the software stays safe to run; the second three decide whether your team can operate it.

Criterion Why it matters What good looks like
Release cadence and patch policy An unpatched cart is the most common way a store gets compromised. A published support window per version, and an end date you can calendar
PCI scope and payment integration A custom checkout can pull you into a far heavier compliance tier. Native support for a hosted payment page or a tokenizing field (Stripe Elements, PayPal, Braintree)
Hosting requirements Underestimating server specs is the top reason a store falls over during a sale. A published minimum spec, and a host that's run this at your scale
Hiring pool for this stack Software you can't staff is software you can't maintain. Developers advertising the stack (WordPress/PHP, Symfony, Laravel, Rails, Node) at a rate you can sustain
Extension ecosystem quality Most stores run dozens of third-party extensions; each is a future upgrade risk. A marketplace with visible upkeep and extensions that survive major-version jumps
Upgrade path between major versions Falling behind on versions is how a store ends up unsupported without noticing. A documented, scriptable migration path, not a manual rebuild

PCI scope deserves plain language: the checkout setup decides how much of the standard applies to you.

Checkout setup What it means for your compliance burden
Customer redirects to, or uses an iframe from, your payment processor The smallest questionnaire; card data never touches your servers
Card fields render via a client-side tokenizing script Slightly larger, still well short of storing card data
Your code touches raw card numbers at any point The full assessment, often needing a Qualified Security Assessor

See our security checklist for software buyers for the fuller version, and check your integration requirements if stock syncs across a warehouse and a marketplace: sync extensions break easiest on a major upgrade.

Key questions to ask before you buy

  1. What's the exact date my chosen version stops receiving patches? Get it from the vendor's own lifecycle page, not a forum post.
  2. Who on my team, or which agency, can actually operate this stack? Price a real engagement before assuming "we'll figure it out."
  3. Does card data ever touch our own server? If yes, budget the PCI assessment now, not after a processor flags you.
  4. What did the last major-version upgrade actually cost, for a store our size? Ask an agency that's done one.
  5. How many required extensions still get updates for the current version? Audit before you buy, not after an upgrade breaks half of them.
  6. What's our real hosting spec at peak traffic, not average traffic?
  7. If we're building headless, who owns the frontend once the original developer leaves?
  8. What happens to our data, theme, and extensions if we leave this platform? Ask for the export format before you sign.

Shortlist: platforms you install

These six are monolithic in the sense that matters: install the software, pick a theme, and the storefront and backend ship together.

Platform Best for License Native multi-store or B2B
WooCommerce WordPress sites, developers wanting full code control GPLv2 or later, free Through plugins, not native
Magento Open Source Complex catalogs and B2B, a real engineering budget OSL 3.0, free Native; deeper B2B on paid Adobe Commerce
PrestaShop European SMBs, multi-language and multi-currency out of the box OSL 3.0 core; AFL 3.0 for native modules and theme Native multistore
OpenCart Small catalogs, tight hosting budget GPLv3, free Limited, mostly via extensions
nopCommerce .NET shops wanting a roadmap without WordPress or PHP nopCommerce Public License, free; separate ISV license exists Native multi-store
Drupal Commerce Teams already on Drupal wanting commerce as a module GPLv2, free Via configuration

WooCommerce is the default for a reason: it's the plugin on the CMS that already runs a huge share of the web, so a WordPress developer you already have can pick it up fast. What you're really buying is patching core, theme, and every plugin on the same schedule, since one outdated plugin is the most common way these stores get compromised. See the best WooCommerce alternatives for the head-to-head.

Magento Open Source earns its reputation for depth: catalog price rules, multi-website management, and B2B features most SaaS platforms reserve for their top tier. The reputation leaves out the support clock, covered in full further down: Adobe runs a fixed window per major version, and unlike Adobe Commerce, Open Source gets no extended-support add-on once it closes. See the best Magento alternatives if you're weighing whether to stay.

PrestaShop is the platform most buyers outside North America already know: strong multi-language and multi-currency support in the box, plus a large Addons marketplace. Its split license rarely matters day to day, but matters if you redistribute a customized build.

OpenCart is the lightweight option: smaller codebase, lower hosting needs, a smaller extension marketplace. Reasonable for a simple catalog on a budget host, weak for anything Magento-level.

nopCommerce is the .NET option, useful if your team or infrastructure is already Microsoft-stack. One quirk: the free edition keeps a "Powered by nopCommerce" footer link, and removing it costs a one-time fee, a line that never shows up until you're committed.

Drupal Commerce suits one buyer: a team already on Drupal for content that wants commerce woven into the same CMS. Centarro, the company behind it, sells support plans rather than the software.

Shortlist: headless commerce engines

These six treat commerce as an API: there's no theme, because there's no default frontend, and the trade only pays off when your team can build one.

Platform Stack Best for Managed cloud option
Saleor Python, Django, GraphQL A mature GraphQL API with a real managed tier Saleor Cloud, from $1,599/month
Medusa Node.js, TypeScript JavaScript-first teams wanting fast local dev Medusa Cloud, from $29/month
Vendure Node.js, NestJS, GraphQL An open core with a flat annual commercial license Platform, quoted per project; Cloud, quoted
Sylius PHP, Symfony Symfony shops wanting an API-first core No official cloud; Sylius Plus adds enterprise support
Spree Ruby on Rails Rails shops wanting B2B and multi-tenant features No official cloud; Enterprise Edition through Vendo
Bagisto PHP, Laravel Laravel shops wanting a managed hosting add-on Bagisto Cloud Hosting, quoted

Saleor is the most enterprise-shaped of the six, with cloud pricing that scales by GMV instead of a vague "contact sales." Enterprise still needs a call, but Select and Volume are real, printed numbers. Medusa is the fastest path from zero to a running backend for a Node-first team. Vendure is the flat-fee outlier: a free GPLv3 core plus a flat annual Platform subscription with no per-order or per-GMV fee.

Sylius and Spree have the longest track records here, both older projects still active through multiple major-version rewrites. Spree is worth a flag: its core license briefly moved off BSD-3-Clause between late 2024 and early 2026, then reverted after community pushback, a real example of the risk covered below, since terms can move under you and a reversal isn't guaranteed twice. Bagisto is the newest of the six, most focused on being easy for a Laravel shop that doesn't want to hand-roll infrastructure.

Shopware doesn't sit cleanly in either list: its Community Edition installs like a monolith, but the same core can run API-first if you want a headless frontend. Layered on top is a real cloud business: Rise from 600 euros a month, Evolve from 2,400 euros a month, and a quote-only Beyond tier, all excluding VAT, printed prices rather than a sales call.

Magento Open Source: the version-support story

This is the fact that changes the calculus for anyone running Magento. Adobe publishes a fixed support window per major release, and the extended-support period after it is sold to Adobe Commerce customers only. Open Source gets the same start and standard-support end date, then nothing more.

Version General availability Standard support ends (Open Source's real deadline) Extended support (Adobe Commerce only)
2.4.4 April 12, 2022 April 12, 2025, already passed Ended April 14, 2026
2.4.5 August 9, 2022 August 12, 2025, already passed Ends August 11, 2026
2.4.6 March 14, 2023 August 11, 2026, already passed Ends August 31, 2027
2.4.7 April 9, 2024 May 31, 2027 Ends May 31, 2028
2.4.8 April 8, 2025 May 31, 2028 Not yet announced
2.4.9 May 12, 2026 May 31, 2029 Not yet announced

Confirmed against Adobe's own software lifecycle policy. Three dates are already behind us: 2.4.4 and 2.4.5 have been unsupported on the Open Source track for over a year, and 2.4.6 lost its patches on August 11, 2026, weeks before this update. A store still on those versions isn't theoretically at risk; it's running without vendor patches today. The only currently safe line for a new build is 2.4.7 or later, and that carries its own hard date: May 31, 2027, with no extended-support option to buy past it.

How to choose: a decision framework

Match your situation to a starting point, then trial your top two with real catalog data.

Your situation Start here Why
WordPress site exists, developer on staff or retainer WooCommerce Lowest friction, largest hiring pool, no platform fee
Complex B2B catalog, real engineering budget Magento Open Source, on 2.4.7 or later Unmatched depth; budget the upgrade cycle from day one
European multi-language, multi-currency store PrestaShop Native multistore and localization
Small catalog, tight hosting budget OpenCart Lightest footprint on this list
.NET shop, no WordPress or PHP in-house nopCommerce Matches existing infrastructure
Already running Drupal for content Drupal Commerce Commerce inside the CMS you run
JavaScript team, custom storefront, fast Medusa Fastest path from zero to a running API
Want a flat annual license, no GMV fee Vendure Priced per project, not per transaction
Symfony or Rails team, long-term project Sylius or Spree The two longest-running frameworks here

What it actually costs

The license is free below. What you pay for, if anything, is support, a managed cloud tier, or a commercial edition with features the open core lacks.

Platform Open-source core Paid tier
WooCommerce Free None official; cost is hosting, extensions, developer time
Magento Open Source Free Adobe Commerce, no published price; third-party estimates run $22,000 to $125,000+/year (reported, not vendor-published)
PrestaShop Free None official; Addons marketplace sells modules and themes
OpenCart Free None official; marketplace sells paid extensions
nopCommerce Free $50 one-time to remove the footer link; ISV commercial license is quote-only
Drupal Commerce Free Centarro support from $500/month; Retainer from $1,500+/month
Shopware Free (Community Edition) Rise from 600 euros/month; Evolve from 2,400 euros/month; Beyond, quote-only
Saleor Free Cloud Select $1,599/mo (to $200K GMV); Volume $3,999/mo (to $1M GMV); Enterprise, quote-only
Medusa Free Cloud Develop from $29/mo; Launch from $99/mo; Scale from $299/mo; Enterprise, quote-only
Vendure Free (GPLv3) Platform, quoted flat annual, no GMV or order fees; Cloud, quoted
Sylius Free Sylius Plus, enterprise features and support, quote-only
Spree Free (BSD-3-Clause core) Enterprise Edition modules, commercial license, through Vendo
Bagisto Free (MIT) Bagisto Cloud Hosting, quoted

Adobe Commerce is the only product here whose price never appears on the vendor's own site, so treat any figure you read elsewhere as someone else's estimate. nopCommerce's $50 fee is, genuinely, the only fixed, published price on this list: everything else is free or a conversation.

Migration and lock-in

Open source is sold on removing vendor lock-in, and it removes one kind: you're never one acquisition away from a shutdown notice, since you hold the code. What replaces it is implementation lock-in, and for most stores that's the stickier version. A typical WooCommerce store runs 58 active plugins, climbing to 66 at seven-figure revenue, and each one is a dependency your next developer has to understand first. Losing a vendor is a bad afternoon; losing the one person who knew why twelve custom plugins were wired together in a specific order is a bad quarter. The Spree episode above shows the same risk differently: even a permissive license can move under you, and a community reversal isn't guaranteed twice.

Three moves reduce the damage regardless of platform.

Move Why it helps
Inventory every extension, who built it, and why, updated each time you add one Your next developer isn't reverse-engineering the stack from scratch
Audit that inventory against the compatibility list before any major-version upgrade An abandoned extension usually turns a routine upgrade into a rebuild
Confirm you can export your catalog, customers, and order history in a usable format Before you need to, not after

If stock syncs across a warehouse and a storefront, pick inventory management software that survives the same upgrade cycle, and price an in-house developer hire properly with our payroll for startups guide.

Frequently asked questions

Is Magento Open Source actually dead?

No, and that's part of why it's dangerous. Adobe still ships new major versions, most recently 2.4.9 in May 2026, and the software works the same the day its support window closes as the day before. What ends is the patches, on a fixed calendar Magento Open Source can't buy its way past. A live store running dead code looks identical to one running supported code, until it doesn't.

What's the real difference between a monolithic platform and a headless commerce engine?

A monolithic platform ships a theme and admin panel together, so a merchant launches by picking a template. A headless engine ships only the backend and an API; your team builds the storefront and calls the API to render every page. Monolithic launches faster for a non-technical merchant; headless gives a technical team more control, at the cost of building the frontend a theme would give away.

Do I need a PCI compliance audit if I self-host?

It depends on whether card data touches your server. A checkout that redirects to, or embeds an iframe from, your processor keeps your burden small. If your own code touches card data at any point, you're in a much heavier tier, often needing a Qualified Security Assessor. Pick the checkout integration before the theme.

How many developers does it take to run WooCommerce versus Magento Open Source?

A single WordPress developer working a few hours a month keeps a modest WooCommerce store patched. Magento Open Source, at similar catalog size, typically needs someone Magento-specific working closer to part-time, since its complexity and smaller, pricier hiring pool both push that way. Price a real quote before assuming either number.

Is nopCommerce actually free, or is that $50 fee a licensing cost?

The core is free under the nopCommerce Public License, and the $50 is a one-time fee to remove the "Powered by nopCommerce" footer link, not a license to use the software. A separate commercial license exists for ISVs who want to redistribute without the public license's terms, and that one is quote-only.

When does a hosted SaaS platform beat any open-source option, even for a technical team?

When your team's time is worth more building the product than building infrastructure. A team building a genuinely novel storefront has real reason to go headless; a team building a fairly standard store is better served starting with our ecommerce platform guide and revisiting self-hosting once growth justifies it.

What happens if the open-source project I pick changes its license?

Usually nothing for a version already deployed, since changes apply going forward. What can change is your ability to take future updates, fork it, or redistribute a customized build. Spree's brief move away from its license and back is the clearest recent example: read the license file, not the marketing page, before depending on anything for years.

Buy the runway, not the free tag

The license price is the only number in this category that's genuinely zero, and also the smallest number in the total. Everything that determines whether an open-source project was the right call (hosting, patching, extension maintenance, PCI scope, the eventual major-version upgrade) lands on a bill with your company's name on it, not the vendor's. That's not a reason to avoid this category: plenty of businesses running WooCommerce, PrestaShop, or a headless Medusa build get real value from money spent deliberately. It's a reason to price the three-year picture before you install anything, and pick the platform your team can actually patch, not the one with the longest feature list. If you can answer who patches this in 2029 and what it costs, you're ready to choose.

About the author

Calvin D.

Calvin D.

Head of Enterprise Solutions

Calvin D. is Head of Enterprise Solutions at Rework, with 5+ years and 40+ enterprise engagements spanning 20 to 500+ user deployments. Calvin helps Heads of Operations, IT Directors, and VPs connect CRM, workflow automation, and data into one stack that actually fits together. Readers get field-tested architecture decisions they can apply as their teams scale.