Mercur Review: Independent Deep-Dive (2026)

Nobody reviews Mercur. Search for it and you find the maker's own website, the maker's own comparisons, and the maker's own docs — all written by Rigby, the agency that builds it. That's not a criticism; it's just what happens with young open-source projects. But if you're deciding whether to bet a marketplace build on it, you deserve at least one assessment from someone who doesn't sell it.

This is that review. I run a production marketplace on Medusa v2 (10,000 products, 50 vendors), so I know exactly which problems a marketplace layer must solve, and I've set Mercur up myself to see what it delivers. Every number below was checked on August 27, 2026, at the primary source: the GitHub repo, the official docs, and Mercur's own editions page. Where something is a marketing claim rather than a verifiable fact, I say so.

What is Mercur?

Mercur is an open-source platform for building multi-vendor marketplaces, built on Medusa's commerce core. The MIT-licensed edition ships vendor onboarding and a dedicated vendor panel, multi-vendor checkout with order splitting, split payments, commissions, payouts, and returns — the layer you would otherwise build yourself on top of a bare commerce framework.

The GitHub description sums up the ambition: "The complete open source platform to run your entire marketplace. Storefront, vendor panel, admin console, and integrations in one enterprise-grade platform you own." After working with it, I would call that description accurate in scope and slightly ahead of reality in polish. More on both below.

Who is behind Mercur?

Mercur is built by Rigby, a Polish e-commerce agency headquartered in Warsaw with offices in Wrocław and Rzeszów, operating since 2018. Rigby positions itself squarely in the Medusa ecosystem: the company was rated a top Medusa development team on Clutch in 2023 and 2024, and per its own blog, Medusa investors Piotr and Tomasz Karwatka (the founders of Divante and VueStorefront) have joined as backers.

Two things follow from this ownership structure, one good and one worth watching. The good: Mercur isn't a side project; it's the flagship product of an agency whose business depends on it, which explains the near-daily commit activity. The caveat: every comparison you read on mercurjs.com or rigbyjs.com is vendor content, including their claims of "30-day migration" and "~30% TCO reduction": those are Rigby's marketing numbers, not independent measurements. Treat them the way you would treat any vendor benchmark.

What does Mercur add on top of Medusa v2?

The honest way to evaluate Mercur is against its baseline: bare Medusa gives you products, carts, orders, and payments for a single seller; everything multi-vendor is your problem. Here is what the tiers actually contain, per the editions page:

Note what is in the open-source tier: the whole core marketplace loop (onboarding, splitting, commissions, payouts) is MIT-licensed. Mercur's pitch is "zero GMV fees; the license is your only platform cost," and for the OS edition even that cost is zero. Enterprise buys you the financial-operations layer (a real ledger with reconciliation is not a small thing once money flows through fifty sellers) plus integrations and support. There is no public Enterprise pricing anywhere; it's sales-contact only, which for budgeting purposes means: plan a conversation, not a line item.

One thing I could not verify: KYC. You will see vendor verification discussed around marketplace platforms, but neither the docs nor the editions page names KYC as a feature of either tier. The closest Enterprise item is "payout cycles with AML." If regulated seller verification matters to you, ask Rigby directly rather than assuming.

What is the setup experience like?

Fast, and more modern than I expected. The documented path, per the official docs, is bun create mercur-app@latest. Bun, not npm, is the recommended package manager (Bun v1.3+, Node v20+ LTS, PostgreSQL v14+). The CLI asks for a project name and a template (basic or plugin), then creates the database, runs migrations, seeds data, and starts the dev server. After that you have three surfaces on one port: the API at localhost:9000, the admin console at /dashboard, and the vendor panel at /seller.

No local PostgreSQL? The docs offer a Docker one-liner running postgres:16 for development. The CLI also takes flags when you want control instead of prompts: --template, --db-connection-string, --no-deps, and --skip-db; after the initial run, bun dev restarts the stack. All of this mirrors the create-medusa-app experience closely enough that the knowledge transfers both ways.

In my own setup runs, the whole thing was up in minutes rather than hours: genuinely simple, and it slotted into my usual deployment flow without friction. I host on Railway, and with the Railway MCP server the infrastructure side (services, databases, variables) is manageable straight from an AI coding workflow. If you have deployed a stock Medusa app before, nothing here will surprise you; Mercur inherits Medusa's operational shape — PostgreSQL underneath, Redis and worker processes when you go to production.

What is genuinely good

The scope of the MIT tier. Commissions, payouts, and order splitting are exactly the features SaaS marketplace platforms monetize hardest. Shipping them under MIT is a real commitment, not open-core theater where the free tier is a demo.

Development velocity. The repo shows releases roughly monthly (v2.2.0 on July 9, v2.2.1 on July 28, v2.3.0 on August 11, v2.3.1 on August 14, 2026), with commits landing almost daily (the week I checked: RBAC feature work and canary builds). The last push was the day before I wrote this. Young projects often stall; this one visibly does not.

Standing on Medusa. Mercur inherits a mature commerce core (catalog, orders, payments, shipping, tax, stock) instead of reinventing it. That's the architecturally right call, and it means Medusa skills transfer directly: modules, workflows, the admin extension model. Your team learns one system, not two. (Whether that underlying system should be Medusa at all, versus Vendure or Saleor, is its own question — my three-way production comparison answers it.)

A real vendor panel out of the box. A separate seller UI is one of those features that sounds trivial and consumes weeks when you build it yourself — authentication, scoped data access, order views per vendor. It's simply there.

Limitations and maturity — the honest part

Now the numbers vendor content doesn't lead with, all pulled from the GitHub API on August 27, 2026:

• 1,738 stars, 433 forks. Respectable for a niche B2B tool, but this is not a mass ecosystem. Compare Medusa's ~36,000 stars.
• ~882 commits on main, of which 706 by one person. Viktor Holik, Rigby's lead maintainer. The contributors API lists nine people total (Rigby's site says 24; the discrepancy likely reflects a repo history reset, which is why I pulled the numbers myself instead of quoting anyone's about page). Either way, the bus factor is what it is: this is effectively a one-lead-maintainer project backed by one agency.
• Public since April 2024 — two and a half years old. The core flows work; the long tail of marketplace edge cases (disputes, partial refunds across sellers, exotic tax setups) has had less production mileage than a decade-old platform, and you should expect to hit some of it yourself.
• 21 open issues — low, which cuts both ways: small backlog, but also a small reporting community.

One more practitioner's gripe belongs here: the docs do not document the tier split. docs.mercurjs.com describes the platform as one thing; which features are open source and which are Enterprise lives only on the marketing site's editions page. While evaluating, I kept two tabs open and cross-referenced. Workable, but a maturity signal in itself.

What does this mean practically? Version 2.x is iterating fast, and fast iteration on a young platform means breaking changes are a matter of when, not if. If you build on Mercur, pin your versions, read release notes before upgrading, and budget maintenance time for it. None of this is a reason not to use it; my own stack is full of tools this age. It's a reason to go in with a maintenance budget instead of a set-and-forget mindset.

What does running Mercur in production take?

Operationally, Mercur is a Medusa application, and Medusa's production requirements apply unchanged: separate server and worker processes (worker mode), Redis backing events, caching, and the workflow engine, an S3-compatible object store for files, and at least 2 GB of RAM per the deployment docs. If those words are new to you, budget learning time — this is self-hosted infrastructure, not a SaaS toggle.

If they are not new to you, none of it is heavy. My own Medusa marketplace — same operational shape, one layer down — runs on Railway with usage-based billing: individual services build in two to three minutes and deploy in parallel, and I have had zero infrastructure incidents since going live. For the full cost picture of the underlying stack, my Medusa vs Shopify breakdown runs three scenarios over three years; the short version is that the operational side of this stack has been quietly boring for me, which is exactly what you want from infrastructure.

Mercur vs. building your marketplace from scratch on Medusa

I've effectively run both sides of this experiment (my production marketplace is custom-built on Medusa v2), so here's my practitioner's estimate of what Mercur saves you. These are judgment calls from my own build, not benchmarks:

The from-scratch route buys you exactly one thing: nobody's opinions between you and Medusa. That mattered for my build: the vendor model I needed didn't match any platform's assumptions. If your marketplace is structurally conventional (sellers list products, buyers buy, the platform takes a cut), building the plumbing yourself is mostly paying tuition for knowledge Mercur already encodes.

Who should use Mercur — and who should not

Use it if you have a JavaScript/TypeScript team, a structurally conventional multi-vendor model, and you want the commission-payout-splitting plumbing solved so you can spend your engineering on what differentiates you. The MIT tier is a serious foundation, and the Proof-of-Concept route (two weeks, real data, real vendors) will tell you more than any review, including this one.

If you do evaluate it, structure the PoC around the risks this review surfaced rather than a generic demo. Five checks that will tell you more than any feature list:

• model your commission structure in the OS tier and confirm it fits without forking
• run one full payout cycle to a real test account, including a partial refund across two vendors
• put a non-technical test seller through vendor onboarding and watch where they stall
• dry-run one version upgrade (e.g. v2.2 → v2.3) on a copy, and time what it costs you
• load your realistic catalog size and vendor count before judging performance

Skip it if your vendor model is exotic (Mercur's assumptions will fight you; build on bare Medusa instead), if you need a battle-tested decade-old platform with a large agency ecosystem (that is not any Medusa-based stack today), or if there is no developer capacity at all — then a SaaS marketplace product is the honest choice despite the fees — my Mercur vs Sharetribe vs Mirakl comparison maps that decision in detail.

Verdict

Mercur is the most credible open-source answer to a real gap: multi-vendor commerce without GMV taxes or platform lock-in. The MIT edition includes the features that matter most, development is demonstrably active, and standing on Medusa is the right architecture. Against that: it's young, its commit history runs through one maintainer, its independent ecosystem is thin, and the Enterprise tier is a sales conversation with no public price.

My one-line summary: a strong foundation for teams who can carry some platform risk — not yet a platform you adopt and forget. I'd build a conventional marketplace on it today, and I'd put a reminder in my calendar to recheck the maturity numbers above in six months.

All articles in this cluster live on the E-Commerce topic page; how AI agents speed up Medusa work specifically is covered in my Medusa.js and AI agents guide. If you want a read on your specific marketplace model rather than the general case, book a free 30-minute call: an honest assessment of whether this stack fits, nothing more.