Medusa 2.19 Is Out: What It Actually Means for Your Store

Medusa 2.19.0 shipped on 13 August 2026, and it's now the current version of the platform. The official release title — “Vite v7 Update, Inventory Export, Custom Fulfillment Addresses” — tells you most of what you need to know: one large infrastructure upgrade, and a handful of features your operations team will use every week.

If you run an ecommerce business on Medusa, you probably don't need to read the changelog line by line. You need to know three things: what your team gets, what might break, and what to ask your developers before anyone touches production. That's what this post covers.

The short version

Good news for operations. You can now export inventory to CSV, ship to addresses that differ from the customer's shipping address, and control whether customers get emailed when you edit their order. All three remove manual workarounds that store teams have been living with.

Good news for IT and security. Medusa now ships a generic OIDC authentication provider, which opens the door to putting staff logins behind your existing identity system.

Something to plan for. This release includes three changes officially labelled as breaking, plus new minimum requirements for both your hosting environment and the browsers your staff use to access the admin dashboard. None of it is dramatic, but none of it should be discovered on a Friday afternoon either.

The thing your store managers will notice first

Let's start here, because it's the change most likely to generate a confused Slack message on day one.

Medusa 2.19 upgrades the admin dashboard to Vite 7.3.6 and React Router 7.18.2 — modern versions of the tooling the dashboard is built with. A side effect of that upgrade is that the minimum browser versions have moved up:

For most teams this is a non-event — anyone on a browser that updates itself is comfortably past these versions. But it matters in two specific situations that are common in retail and wholesale operations:

• Shared or locked-down machines. Warehouse terminals, in-store POS-adjacent computers, and any machine where IT has pinned the browser version.
• Older Macs. Safari 16 needs macOS Big Sur or later. A store manager on a Mac too old to run it will need to switch to Chrome or Firefox, or get a machine refresh.

Before you upgrade, it's worth a five-minute audit: which machines does your team actually use to log into the admin, and what browsers are on them? Finding one stale terminal now is much cheaper than finding it when someone can't process a return.

The same upgrade also raises the Node.js requirement for your server environment to ^20.19.0, ^22.12.0, or a newer LTS release. Node 20.0–20.18 and 22.0–22.11 are no longer supported. This one isn't your problem to solve directly, but it's a fair question to put to whoever manages your hosting: are we on a supported Node version?

Inventory export finally exists

If you've ever needed your current stock levels in a spreadsheet — for a supplier conversation, a stocktake, a planning session, or just to send to your accountant — you know the drill: ask a developer to run a query, or click through the dashboard copying numbers by hand.

Medusa 2.19 adds inventory item export as a CSV file, available both through the admin dashboard and through the API. It follows the same pattern Medusa already used for product and order exports, so it should feel familiar to anyone who has exported either of those.

This is a small feature with a disproportionate impact on how much your ops team has to bother your engineering team. Bulk stock reconciliation, supplier reporting, and inventory planning all become self-serve.

Fulfillments can now go to a different address

Here's a scenario most growing stores hit eventually: a customer orders something, but the item needs to ship from somewhere other than your warehouse — a supplier, a manufacturer, a third-party logistics provider — or needs to go to a location that isn't the address on the order.

Until now, that meant workarounds. In 2.19, when you create a fulfillment you can supply a custom delivery address independently of the order's shipping address, and pass additional data through to the fulfillment provider alongside it.

The practical unlocks:

• Drop-shipping. Route a fulfillment to a supplier's dispatch address without editing the customer's order.
• Multi-warehouse and 3PL setups. Give your logistics partner the exact address and instructions the shipment needs.
• Provider-specific requirements. The additional_data field means your team can pass carrier or partner metadata — reference numbers, handling instructions, account codes — without a custom code change every time a partner asks for a new field.

If any part of your catalogue ships from somewhere you don't own, this is the feature in 2.19 worth asking your developers about.

You control the emails on order edits

Order edits are a routine part of customer service: a customer calls to add an item, change a size, or remove something before dispatch. Previously, the notification behaviour around those edits wasn't something you could tune.

Order edit workflows now respect notification preferences, meaning that when your team triggers an order edit, they can opt in or out of sending the customer a notification — consistent with the preference controls Medusa already offered on other order operations.

The value here is judgement. Some edits genuinely warrant an email — a customer should know if you removed an out-of-stock item. Others are internal corrections that only generate confusion and a support ticket if they land in someone's inbox. Giving your team control over which is which is a small change that quietly reduces contact volume.

Staff logins can go behind your identity provider

Medusa 2.19 adds a generic OIDC authentication provider. OIDC (OpenID Connect) is the open standard that sits behind most corporate identity systems, which means Medusa can now be wired into the same login your team already uses for everything else.

Why an ecommerce CEO should care about a line item that sounds like plumbing:

• Offboarding actually works. When someone leaves, revoking their central account cuts their admin access too. No more hunting for orphaned logins with order-refund permissions.
• Your existing security policy applies. Mandatory MFA, session timeouts, conditional access rules — enforced in one place rather than reimplemented per system.
• Audits get easier. “How do you control access to your commerce admin?” is a much better question to answer when the answer is “the same way we control access to everything else.”

This is a foundation, not a finished integration — connecting it to your specific identity provider is work for your engineering team. But it's the piece that had to exist first, and it's now there.

Search moved to the backend

Authentication isn't the only piece of plumbing 2.19 rebuilds. The release also changes how finding things works inside the admin — the search box your team uses dozens of times a day.

2.19 introduces a search module with a backend search endpoint, along with a DSL — a structured way of defining how search indexes are built — and admin search has been switched over to use that backend endpoint.

Medusa hasn't published performance figures for this, so treat any specific speed claim you read elsewhere with scepticism. What's structurally true is that search work now happens server-side through a proper module rather than being handled the way it was before, which is the architecture you want if your catalogue is large or growing. If your team has been frustrated by admin search on a big catalogue, this is the release where that foundation changed — worth re-testing after you upgrade.

The three breaking changes, in plain language

The release notes flag three changes as breaking. Here's what each one actually risks.

1. The Vite 7 and React Router 7 upgrade. Covered above — browser and Node requirements move up. The risk sits with any custom admin dashboard extensions your team has built; those may need updating. Ask your developers whether you have any.

2. Four product-option methods removed from the JS SDK. Methods for creating, updating, retrieving, and deleting product options were removed; the replacement is the general product update method. This only affects custom code or integrations your team wrote against those specific methods. It's a targeted change, but if you have a PIM sync or a bulk product tool, it deserves a check.

3. Cart and order totals are now included by default. Previously, requesting all fields on a cart or order left out the computed totals. Now they're included. This makes the default behaviour more intuitive, but it means those requests do more work than they used to. Medusa's own guidance is to request only the fields you actually need rather than asking for everything — so if your storefront or any integration pulls carts and orders broadly, this is worth a performance look after upgrading.

What to ask your team before you upgrade

You don't need to run the upgrade. You do need to make sure the right questions get asked. These are the ones worth putting in writing:

1. Are we on a supported Node version (^20.19.0, ^22.12.0, or newer LTS), and if not, what's the plan?
2. Which browsers is our team using to access the admin, and does anything fall below Chrome 107 / Edge 107 / Firefox 104 / Safari 16?
3. Have we built custom admin dashboard extensions, and have they been tested against Vite 7 and React Router 7?
4. Does any of our code use the removed product-option SDK methods?
5. Do we request all fields on carts or orders anywhere? If so, what does the totals change do to response times?
6. Have we tested this on a staging environment that mirrors production, including running the database migrations?
7. What's our rollback plan if something surfaces after we go live?

So should you upgrade?

Yes, on a sensible timeline.

The operational features in 2.19 are the kind that remove friction rather than add capability you have to learn: inventory export, flexible fulfillment addresses, and notification control are all things your team will simply start using. The OIDC provider is strategically valuable if you're at the stage where access control and audits are becoming real concerns — which, for most growing commerce businesses, arrives sooner than expected.

The breaking changes are narrow and well-documented. The realistic risk isn't that the upgrade fails; it's that nobody checked the browser on the warehouse terminal, or that a custom admin extension nobody has touched in eight months quietly stops loading.

Put it on staging, work through the seven questions above, and schedule the production upgrade for a morning when your developers are around and your order volume is low. That's the whole plan.

Running a Store on Medusa?

We handle Medusa development for stores where the staging pass, the extension audit and the upgrade window described above are somebody's actual job — ours. It is the same discipline behind builds like AURA&CO's multi-region storefront on Medusa 2.18. If you'd rather someone else carried the 2.19 upgrade, talk to us.