# Mercur Marketplace Platform: Self-Hosted Multi-Vendor Commerce

> Mercur is an open-source TypeScript marketplace platform built on Medusa for teams that need vendor onboarding, offers, commissions, payouts, admin tools, and seller workflows without adopting a marketplace SaaS. It suits B2C, B2B, and hybrid operations, but its MIT-licensed core and separately licensed enterprise modules make feature boundaries important to check before adoption.

**mercurjs/mercur** — The complete open source platform to run your entire marketplace. Storefront, vendor panel, admin console, and integrations in one enterprise-grade platform you own.

- Repository: https://github.com/mercurjs/mercur
- Website: https://www.mercurjs.com
- Stars: 1,883 · Forks: 480
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/mercurjs-mercur

## Why Mercur targets marketplace operations

Mercur addresses a specific problem that a conventional single-seller commerce engine leaves open: several vendors need to participate in the same marketplace while each seller has products, offers, orders, commissions, and payout activity. The README positions Mercur as an alternative to Mirakl and as a platform for B2C, B2B, and hybrid marketplaces. Its target users are marketplace operators who need customer and vendor interfaces under their own control, rather than a hosted service that retains the marketplace data and imposes platform fees.

The platform covers the operational surface of a marketplace rather than only the checkout path. Operators can manage vendors, catalogs, categories, commissions, and rules through the Admin Panel. Sellers can manage products, orders, and payouts through the Vendor Panel. Customer-facing storefronts provide multi-vendor browsing, carts, and checkout. That division makes Mercur relevant to teams that need distinct workflows for marketplace administrators, vendors, and buyers.

Self-hosting is the central economic choice in the documentation. The README says deployments can run on the customer's infrastructure, with PostgreSQL and Redis as the backing services. This can remove dependence on a proprietary marketplace runtime, but it also places database, cache, payment, email, search, and deployment operations on the adopting organization.

## Mercur's Medusa-based architecture and data flow

Mercur is not an isolated commerce engine. It is a marketplace layer built on top of Medusa, whose documented core areas include catalogs, orders, payments, shipping, tax, and stock. Mercur adds marketplace primitives such as vendors, commissions, payouts, offers, and multi-vendor catalog behavior. The README describes the result as event-driven, API-first, headless, and customizable, which means storefronts and administrative clients can communicate through APIs instead of depending on one fixed frontend.

The repository is a development monorepo containing the `@mercurjs/core` plugin, React and Vite admin and vendor dashboards, `@mercurjs/cli`, a typed API client, the dashboard SDK, a Stripe Connect payout provider, and integration suites. Based on that layout, the repository is intended for development across several packages and applications, not merely for running a single dashboard binary.

The package configuration identifies Turbo as the build and development orchestrator and pins many Medusa packages to version `2.21.2`. Bun is declared as the package manager in the root `package.json`. These details make Mercur a stack with version-sensitive dependencies rather than a frontend-only library. The repository also contains `integration-tests`, `e2e-tests`, `scripts`, `templates`, and provider packages, indicating that validation spans more than the visible dashboard screens.

## Installing Mercur and opening the first panels

The README gives a short path for creating a local marketplace. It requires Node.js `>=20.x`, PostgreSQL `>=13.x`, Redis, and recommends Bun. The repository metadata separately declares Node.js `>=18`, so the setup instructions are stricter than the package engine field. That difference is worth resolving before automation relies on the lower package constraint.

Create a project with the documented command:

```sh
bun create mercur-app@latest my-marketplace
```

The project is then started from its directory:

```sh
cd my-marketplace
bun run dev
```

After the development server starts, the README lists three routes. The backend API is at `http://localhost:9000`, the Admin Panel is at `http://localhost:9000/dashboard`, and the Vendor Panel is at `http://localhost:9000/seller`. The generated project is described as seeded with a demo store, a seller account, products, and offers. The documented seller credentials are `seller@mercur.dev` and `supersecret`.

Start with the seeded seller flow, then open the admin route to inspect marketplace configuration. The README also says Stripe Connect, Resend, Algolia, and Meilisearch integrations may require additional credentials placed in `.env`. It does not document the exact values or setup sequence for those integrations, so they should not be treated as enabled by the basic installation.

## What the marketplace layer adds to Medusa

The distinctive feature is the treatment of offers from multiple sellers. The README specifically says that several sellers can list offers against the same product. That model is more expressive than treating each seller as an isolated store, especially when a buyer can compare offers or when a marketplace applies a commission rule to a resulting transaction.

Vendor onboarding is also part of the core proposition. Sellers have a separate panel for products, orders, and payouts, while operators have controls for vendors and commissions. The documentation describes a headless composition model in which workflows, products, and vendor rules can be extended or overridden without patching the core. The repository includes a typed API client and dashboard SDK, which are relevant for teams building an external seller or operations interface.

The admin and vendor panels are described as independently deployable apps that communicate with the core over APIs. Storefronts are also separate in the architecture. This separation can fit organizations with separate frontend teams or multiple customer-facing brands, but it introduces more deployment and integration work than installing a conventional admin extension. Mercur is therefore more compelling for a multi-party commerce operation than for a simple catalog with one seller.

## Limits of the documented core and enterprise boundary

Mercur has a genuine boundary between the open repository and Mercur Enterprise. The README states that the MIT-licensed repository contains the marketplace engine, dashboards, and APIs. It separately lists EAN matching and deduplication, a Buy Box or winning-offer engine, master-data governance, multi-channel stock sync, automated split payouts, vendor KYC, and other advanced modules as part of Mercur Enterprise. Those modules are not established as freely available core features by the repository description.

This distinction affects both evaluation and upgrade planning. A team may adopt the core for vendors, catalogs, offers, commissions, and payouts, then discover that catalog matching, winner selection, stock synchronization, KYC, or split payouts belong to a licensed suite. The README does not provide prices, module boundaries beyond the named examples, or a feature-by-feature licensing table. It therefore should not be used as a substitute for checking the current enterprise terms.

The documentation also does not specify rollback procedures, backup routines, database migrations, observability configuration, or production readiness checks. Those omissions do not prove that the features are absent, but they are not available as documented procedures for an operator. The repository is not archived, and the last push was on 2026-10-16, but recent repository activity alone does not remove the need to assess release compatibility and upgrade work.

## How Mercur differs from Medusa and a hosted marketplace

Medusa supplies the commerce foundation, while Mercur adds marketplace-specific concepts such as vendors, commissions, payouts, seller offers, and vendor-facing administration. Choosing Mercur does not remove Medusa from the design. The root `package.json` pins Medusa packages to `2.21.2`, including the core, flows, admin SDK, framework, and related packages. Teams adopting Mercur should evaluate both projects together because changes in Medusa dependencies can affect the marketplace layer.

A hosted marketplace platform can reduce infrastructure ownership and may provide a more prescriptive vendor workflow. Mercur instead emphasizes source access, self-hosting, API access, and control over the data and roadmap. The trade-off is operational: PostgreSQL, Redis, application deployments, payment configuration, and integration credentials remain explicit concerns. The documentation mentions managed deployment through Medusa Cloud, but that is an option rather than a requirement.

The practical comparison is therefore between ownership and operational responsibility. Mercur is the better fit when the marketplace model requires custom seller behavior and the organization can maintain a TypeScript and Medusa stack. A hosted service may be easier when the team wants a vendor and payout process with fewer infrastructure decisions. The README does not provide a formal comparison with Mirakl, so that alternative is described only by Mercur's own positioning as an open-source Mirakl alternative.

## Release and maintenance considerations for Mercur

The repository is not archived. Its last push was on 2026-10-16, and the listed releases include `v2.3.7` on 2026-10-08, `v2.3.6` on 2026-10-06, and `v2.3.5` on 2026-09-17. Those dates show recent release activity in the repository. They do not, by themselves, define the upgrade path for a particular deployment.

The root package uses Bun workspaces and pins numerous Medusa packages through overrides. It also defines build and test scripts such as `bun run build`, `bun run lint`, `bun run test:unit`, and `bun run test:integration:http`. These scripts are available in the monorepo package configuration, but the README's beginner instructions create an application rather than instructing users to clone this repository. Contributors and teams modifying Mercur itself have a different workflow from teams consuming the generated application.

The MIT License covers the Mercur core repository. Mercur Enterprise adds a separately licensed suite, so license review must cover both the repository and any enterprise modules used. The README does not state support terms, upgrade compatibility guarantees, or migration instructions for changing Medusa versions. Those are concrete items to verify before treating the platform as a low-maintenance hosted service.

## Conclusion

Adopt Mercur when you need an owned, self-hosted multi-vendor foundation and can operate Node.js, PostgreSQL, Redis, and the Medusa-based stack. Do not treat the MIT core as equivalent to every feature advertised by Mercur Enterprise. Verify the required Medusa services, payout provider configuration, vendor rules, and enterprise module licensing before committing.

## FAQ

### What is Mercur used for?

Mercur is an open-source, headless platform for building multi-vendor B2C, B2B, and hybrid marketplaces. It adds vendor onboarding, multi-vendor catalogs, offers, commissions, and payouts to a Medusa commerce core.

### How do I create a local Mercur marketplace?

The README instructs users to run `bun create mercur-app@latest my-marketplace`, enter the generated directory, and run `bun run dev`. The setup requires Node.js `>=20.x`, PostgreSQL `>=13.x`, Redis, and Bun is recommended.

### Is Mercur Enterprise included in the MIT-licensed repository?

The README describes the repository as MIT-licensed Mercur core and separately identifies Mercur Enterprise modules, including EAN matching, a Buy Box engine, master-data governance, split payouts, and vendor KYC. The license section does not say that every Enterprise module is included in the core repository.

## Sources

- [License: MIT](https://github.com/mercurjs/mercur/blob/main/LICENSE)
- [mercurjs/mercur on GitHub](https://github.com/mercurjs/mercur)
- [Project website](https://www.mercurjs.com)
- [README](https://github.com/mercurjs/mercur/blob/main/README.md)
- [Releases](https://github.com/mercurjs/mercur/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mercurjs-mercur