Swell vs Saleor vs Vendure: Hosted Convenience or Source-Level Control?

Pick Swell if you never want to touch a server. Pick Saleor or Vendure if you need the source code in your own hands, not just an API endpoint you can call. This comparison is written against Saleor Core 3.23.22, Vendure Core 3.7.1 (released 2026-07-14), and swell-js (opens in a new tab) 5.8.0, with self-hosting steps targeting Docker 28.1.1 on Ubuntu 24.04 LTS with PostgreSQL 17.5. Nothing here was deployed for this article — every claim traces to a vendor’s own documentation, licence file, or pricing page, dated 2026-07-28.

Only Saleor and Vendure let you self-host — Swell doesn’t

Swell’s only reachable backend surface is the managed SaaS running behind api.swell.store. There is no self-hosted or open-source Swell backend at any pricing tier — the Backend API introduction (opens in a new tab) documents a fixed base URL and a REST interface, not a repository you check out and run yourself. Whatever infrastructure Swell operates behind that URL, you never see it.

Saleor Core and Vendure Core are the opposite: both ship as source you clone and run. Saleor Core is licensed BSD-3-Clause (opens in a new tab) and Vendure Core is licensed GPLv3, and for both, managed cloud is an add-on rather than the only way to run the platform. This article targets Saleor Core 3.23.22 (opens in a new tab), a security patch also backported to 3.22.63 and 3.21.67, and Vendure Core 3.7.1 (opens in a new tab), released 2026-07-14.

The reference stack for self-hosting either platform is Docker 28.1.1 on Ubuntu 24.04 LTS with PostgreSQL 17.5. Vendure’s supported Node range is ^20.19.0 || >=22.12.0, so pin your container’s Node image to that range before you start.

Swell’s Backend API has no reader-facing version number to pin. It is continuously deployed behind that fixed base URL, so there’s no tag, release, or commit hash to audit before you build against it — you are always integrating with whatever Swell happens to be running that day.

# Saleor Core: a local, versioned codebase
git clone https://github.com/saleor/saleor.git
cd saleor && git log -1 --format='%H %ci'
cd ..

# Vendure Core: same story
git clone https://github.com/vendurehq/vendure.git
cd vendure && git log -1 --format='%H %ci'
cd ..

# Swell: there is no backend repository to clone.
# The only integration surface is a fixed, hosted API endpoint.
echo "No backend source available — see https://api.swell.store"

You should now see: which of the three platforms gives you a local, versioned codebase to run and audit, and which gives you only a hosted API endpoint with no version to check out.

Compare licensing: Saleor’s BSD-3-Clause vs Vendure’s GPLv3

Saleor Core carries a BSD-3-Clause licence with no field-of-use restriction. You can run it, modify it, and sell a product built on it, with no obligation to publish your changes back.

Vendure Core is different, and the difference is recent enough that older comparisons still miss it. Vendure moved from MIT to GPLv3 with the v3.0 release on 17 July 2024 (opens in a new tab) — the codebase itself was functionally identical to v2.3; the licence was the only thing that changed. Vendure’s own LICENSE.md (opens in a new tab) states that plugins may be released under any licence you choose, even though the core package they extend is GPLv3.

That core-versus-plugin line is also what decides whether GPLv3 reaches your storefront. A typical headless build talks to Vendure over HTTP or GraphQL from a separate process — a Next.js app, a mobile client, a service with its own repository. GPLv3’s copyleft obligation attaches to modifying and distributing Vendure core itself, not to something that merely calls it over a network.

So: does Vendure’s GPLv3 licence force you to open-source your storefront? No, if the storefront runs as a separate process consuming the API. Obligations that look like “yes” only attach if you fork and distribute a modified Vendure core. That line can blur in a monorepo or a tightly coupled build, so run your specific architecture past legal review before you commit to it, not after.

Compare extensibility: Saleor Apps, Vendure Plugins and Swell integrations

Saleor extends through Apps (opens in a new tab) — separately hosted services, written in any language, that subscribe to webhooks and call back into the GraphQL API. Saleor’s own documentation describes Apps as the recommended integration path, not one option among several. The app process never runs inside Saleor’s server; it’s a client with elevated permissions.

Vendure extends through Plugins, and the model is structurally the opposite. A VendurePlugin (opens in a new tab) is a NestJS module compiled directly into the server process. From one TypeScript package, a plugin can extend the GraphQL schema, add database entities through TypeORM, and subscribe to the core event bus, all with direct, in-memory access to the running server.

Swell has neither model. There is no SDK for arbitrary server-side extension, only a curated list of pre-built integrations you either use as-is or don’t use at all. If the integration you need isn’t on that list, Swell gives you no path to build it against the backend yourself.

import { PluginCommonModule, VendurePlugin } from '@vendure/core';

@VendurePlugin({
  imports: [PluginCommonModule],
  compatibility: '^3.0.0',
})
export class LoyaltyPointsPlugin {}

{
  "id": "app.example.loyalty-sync",
  "version": "1.0.0",
  "name": "Loyalty Sync",
  "appUrl": "https://loyalty-sync.example.com",
  "tokenTargetUrl": "https://loyalty-sync.example.com/api/register",
  "permissions": ["MANAGE_ORDERS"],
  "webhooks": [
    {
      "name": "Order created",
      "targetUrl": "https://loyalty-sync.example.com/webhooks/order-created",
      "asyncEvents": ["ORDER_CREATED"],
      "query": "subscription { event { ... on OrderCreated { order { id } } } }",
      "isActive": true
    }
  ]
}

The two open-source models fail in different places, and it’s worth planning monitoring around both before you pick one. A Saleor App can stop receiving events with nothing visible anywhere in the Saleor dashboard — an unreachable HTTPS endpoint and a manifest permission scope that no longer covers the subscribed events both fail silently, out of process. A Vendure server fails differently: because plugins compile into the same process as the core, a TypeScript, NestJS, or TypeORM version drift between a plugin and a newly upgraded Core can stop the server compiling, or booting, at deploy time — a failure mode Saleor’s network-isolated Apps don’t share.

flowchart LR
    subgraph SaleorFail["Saleor App failure"]
        A1["Endpoint unreachable or scope missing"] --> A2["Webhook delivery fails"]
        A2 --> A3["No error shown in Saleor dashboard"]
    end
    subgraph VendureFail["Vendure Plugin failure"]
        B1["Core upgraded, plugin deps unchanged"] --> B2["TypeScript or TypeORM version drift"]
        B2 --> B3["Server fails to compile or boot"]
    end

You should now see: which platform’s extension model breaks your CI pipeline (Vendure, on a Core upgrade) versus fails silently in production (Saleor, on an App outage), and can plan monitoring for each accordingly.

Compare real cost structures, not marketing tier names

Compare vendor tier names and Swell, Saleor and Vendure look similar: a handful of named plans plus an enterprise option. Compare the actual numbers and they diverge sharply, starting with the fact that Swell’s own two pricing pages don’t agree with each other.

As of 2026-07-28, the live Swell pricing page (opens in a new tab) lists Starter at $29/month (billed yearly), Basic at $79/month, Standard at $299/month, and Unlimited at $2,250/month. The help-center pricing article (opens in a new tab) lists the same four names — Starter, Basic, Standard, Unlimited — at $299, $599, $999, and $2,000/month. That’s roughly a 10x gap on Starter and Basic, for tier names that should mean the same thing.

Saleor Cloud (opens in a new tab) is generally available with four published tiers, and the figures are consistent across the page: a free Sandbox tier, Select at $1,599/month for up to $200,000 in monthly GMV with 0.8% overage, Volume at $3,999/month for up to $1,000,000 in monthly GMV with 0.4% overage, and a custom-quoted Enterprise tier.

Vendure Cloud (opens in a new tab) is not yet generally available and carries no published price. Vendure’s own pricing page marks capabilities like regional data residency and bring-your-own-cloud as “At GA” — features promised once the product ships, not features you can buy today.

B2B is where the three diverge furthest. Vendure’s B2B feature set — company accounts with roles, quote-to-order approvals, contract and customer-group pricing, credit limits, and a dedicated B2B storefront — ships only inside the commercial Vendure Platform, priced from €40,000/year flat with no GMV, order, user, or capability-based charges. None of it is in free, GPLv3 Vendure Core. Saleor ships no dedicated B2B module at all; its documented pattern is mapping B2B customers to Channels (opens in a new tab) plus draft orders, assembled by hand.

flowchart TB
    subgraph Core["Vendure Core - free, GPLv3"]
        C1["Products, orders, customers"]
        C2["CustomerGroups"]
        C3["Plugins and GraphQL API"]
    end
    subgraph Platform["Vendure Platform - from EUR 40,000/year"]
        P1["Company accounts with roles"]
        P2["Quote-to-order approvals"]
        P3["Contract and customer-group pricing"]
        P4["Credit limits and B2B storefront"]
    end
    C2 -.manual build required.-> P3

Screenshot whichever Swell tier price you’re about to quote a stakeholder, with a date stamp, before it goes into a proposal. Then confirm the number with Swell sales — the page you screenshot may not match the number they quote you later.

Check AI agent and MCP support before you build automation

Saleor ships an official Model Context Protocol server, saleor-mcp (opens in a new tab) v0.1.4, compatible with Saleor 3.21 and later. It is explicitly read-only: it exposes query tools to an agent but has no path to trigger a mutation, so a connected agent can inspect orders, products, and customers but can’t change any of them.

No equivalent official MCP server or agent SDK exists for Vendure or Swell, as far as this research pass found. Swell’s documented Backend API authentication (opens in a new tab) is a single store-wide secret key per store, with no scoped or role-based key types. There is no way to issue a key limited to one resource or permission level — a leaked credential, or an agent pointed at the wrong key, gets full read/write access to the entire store.

{
  "mcpServers": {
    "saleor": {
      "command": "node",
      "args": ["/path/to/saleor-mcp/dist/index.js"],
      "env": {
        "SALEOR_API_URL": "https://<YOUR_STORE>.saleor.cloud/graphql/",
        "SALEOR_APP_TOKEN": "<YOUR_READ_ONLY_TOKEN>"
      }
    }
  }
}

Check saleor-mcp’s own README for the exact build and run steps for your setup — the snippet above shows the general MCP client config shape, not a command Saleor publishes verbatim.

curl -s https://api.swell.store/orders \
  -u "<YOUR_STORE_ID>:<YOUR_SECRET_KEY>"

Nothing in that request narrows what the key can reach. There’s no scope parameter to add — the same secret key that lists orders can also delete them.

That leaves two very different positions on the same question. Saleor is the platform where an agent can safely read but not act, so the blast radius of a compromised MCP connection is bounded to disclosure. Swell is the platform where any API access, agent or otherwise, carries the largest blast radius available today, because there’s no permission model narrower than the whole store.

You should now see: which platform’s current AI-agent posture matches your risk tolerance — read-only and scoped (Saleor) versus full-access and unscoped (Swell) — before you connect an agent to production data.

Best fit and dealbreakers for Swell, Saleor and Vendure

flowchart TD
    Q1{"Need to self-host the backend?"}
    Q1 -->|No| Swell["Swell"]
    Q1 -->|Yes| Q2{"Need B2B: quotes, approvals, credit limits?"}
    Q2 -->|Yes, budget covers EUR 40,000/year| VendurePlatform["Vendure Platform"]
    Q2 -->|No| Q3{"Extension code: out-of-process, any language?"}
    Q3 -->|Yes| Saleor["Saleor + Apps"]
    Q3 -->|No, prefer in-process TypeScript| Vendure["Vendure Core"]

Swell fits teams that want zero infrastructure ownership and will trade vendor lock-in for delivery speed. There’s no server to patch, no database to back up, and no compose file to maintain — you write a storefront against the API and ship it. Avoid Swell if you need self-hosting, a plugin SDK for server-side logic, scoped API keys, or a stable frontend GraphQL API: the GraphQL Frontend API (opens in a new tab) is documented as experimental alpha, missing nested queries, saved cards and addresses, payment tokenization, and abandoned-cart recovery.

Saleor fits teams that want a generally available managed cloud with published, GMV-based pricing, a permissive BSD-3-Clause licence, and an out-of-process extension model that doesn’t care what language your integration is written in. Avoid Saleor if you need a first-party B2B module — you’ll be assembling one from Channels and draft orders — or an MCP server that can act on your data rather than only read it.

Vendure fits teams that want deep, in-process TypeScript control over the commerce server and are comfortable running Docker, Ubuntu, and PostgreSQL themselves. A Vendure Plugin has direct access to the event bus and database schema in a way no out-of-process Saleor App does. Avoid Vendure if you need a generally available managed cloud today, can’t accept GPLv3’s obligations on modified-and-distributed core, or can’t reach €40,000/year for the Vendure Platform, which is where the B2B feature set actually lives.

Use this comparison table to make the call

The table below restates every figure already established in this article, aligned by dimension, all dated 2026-07-28. Cells sourced from a vendor’s own pricing or marketing page are marked (vendor claim); everything else is confirmed against a changelog, licence file, or docs page.

You should now see: where each platform stands on self-hosting, licensing, cost, and lock-in, without cross-referencing three separate sets of marketing pages.

What this comparison didn’t test

No production deployment, load test, or migration was run against Swell, Saleor, or Vendure to produce this comparison. Every licensing, pricing, and architecture claim above comes from vendor documentation, changelogs, and pricing pages, not from operating any of these three platforms in production — treat this as a documentation-based comparison, not a benchmark.

Vendure’s GitHub organisation moved from vendor-ecommerce to vendurehq (opens in a new tab) at some point before this article was written. That move was confirmed by checking the repository itself, but no official, dated announcement of the rename was located during this research pass — hold that fact at medium confidence until you find Vendure’s own statement on it.

Actual Vendure Cloud pricing, once the product reaches general availability, wasn’t available to verify at the time of writing. Swell’s own pricing pages disagree with each other, and Saleor and Vendure both update pricing and licence terms on their own schedule — confirm current numbers directly against each vendor’s pricing page and changelog before any figure from this article goes into a budget.