EverShop in 2026: A Coherent TypeScript Store with a Young Ecosystem

EverShop earns a shortlist slot when a team wants one TypeScript codebase — storefront, admin and API — instead of assembling a headless commerce backend, a separate frontend and a CMS. It loses that slot the moment multi-vendor selling, B2B account workflows or role-scoped admin access moves from nice-to-have to requirement, because none of the three exist in EverShop today. This review is verified against EverShop 2.1.2, Node.js 20.x, npm 9.x and PostgreSQL 15, current as of the research pass described below.

Two kinds of teams should put EverShop on a shortlist. The first is a small-to-mid JavaScript or TypeScript team that wants a single deployable application — storefront and admin together — rather than wiring up separate headless services. The second is a team that already runs its own PostgreSQL instance and values type safety end to end, from database queries through to the admin UI.

Two kinds of teams should look elsewhere for now. Anyone building a multi-vendor marketplace, a B2B account and quoting workflow, or an admin panel with per-role permissions will not find any of that in EverShop today. Anyone who needs a deep third-party extension catalogue or a list of enterprise reference customers before signing off a budget will also come up short.

flowchart TD
    A[Need one deployable app,<br/>JS/TS team, own PostgreSQL?] -->|Yes| B[Shortlist EverShop]
    A -->|No| C[Look at headless engines instead]
    B --> D{Need multi-vendor, B2B,<br/>or role-scoped admin?}
    D -->|Yes| E[EverShop is not a fit today]
    D -->|No| F[Proceed to a proof of concept]

This review tests one hypothesis: whether owning storefront, admin and API in one language offsets a materially smaller ecosystem than Saleor, Vendure or Shopware — three platforms already covered elsewhere in this series.

EverShop’s product model: a modular monolith, not a headless engine

EverShop’s core is licensed under GPL-3.0, confirmed directly in the repository’s LICENSE file (opens in a new tab). That is a copyleft licence: distributing a modified binary, or hosting a customised build for a client, can trigger source-disclosure obligations that the MIT-style licences used by several peers in this series — Vendure, Saleor core — do not carry. That is a fact this review returns to, not a footnote.

EverShop’s own architecture documentation (opens in a new tab) describes the project as a “modular monolith”: one deployable Node.js application bundling storefront and admin together, with business logic organised into self-contained modules rather than separate services. Internally, both the storefront and admin talk to the backend over GraphQL and REST (opens in a new tab) — the dual API is a development-experience choice, not only an external integration surface.

flowchart LR
    subgraph Headless engine e.g. Saleor, Vendure
        H1[Commerce API] --- H2[Storefront you build or buy]
        H1 --- H3[Admin you build or buy]
    end
    subgraph EverShop modular monolith
        E1[Node.js/Express process] --> E2[Storefront module]
        E1 --> E3[Admin module]
        E1 --> E4[GraphQL + REST]
    end

That product model is the opposite trade-off from the headless-only engines covered elsewhere in this series. Saleor and Vendure ship an API and expect you to build or buy a storefront. EverShop ships a working default storefront and admin from npm run setup onward. EverShop Cloud, the vendor’s managed-hosting plan at $10/month (Personal) and $20/month (Professional), is listed as “Coming Soon” (opens in a new tab) as of this research pass — self-hosting is the only option available today.

Verifying the Node.js, npm and PostgreSQL baseline before you install

EverShop’s system requirements page (opens in a new tab) states minimums, not recommendations: Node.js 20.x or higher — versions below 20.x are explicitly unsupported — npm 9.x or higher, and PostgreSQL 13 or higher, with 15+ recommended for performance. Supported operating systems are Linux, macOS 10.15+, and Windows 10+ or Server 2019+. Check all three before you clone the repository, not after npm run setup fails.

The installation guide (opens in a new tab) also requires write permission on four paths for the process user: public/, .evershop, media and .log. This is easy to miss on a fresh clone, and even easier to miss after a container rebuild that resets filesystem ownership. A process that can read its own code but not write to media/ fails uploads in ways that look unrelated to permissions.

Three failure modes show up repeatedly. Node below 20.x produces an unsupported-engine warning at best and silent misbehaviour at worst. npm run setup against an existing, older default PostgreSQL instance — common on a distro-default install — fails to connect or migrates unpredictably. Permission errors after a fresh clone or a rebuilt container filesystem crash the process outright.

Run these checks before you clone anything:

node -v
npm -v
psql --version

Expected output:

Compare each version against the minimums above. If the process user needs write access after a fresh clone or a container rebuild, grant it explicitly:

chmod -R u+w public .evershop media .log

You should now see: Node.js, npm and PostgreSQL versions that meet EverShop’s documented minimums, and a process user with confirmed write access to public/, .evershop, media and .log, before you run the installer.

EverShop’s pricing model and the real total cost of ownership

EverShop’s pricing page (opens in a new tab) describes self-hosting as “100% free and community-driven,” with no cap on the number of products. That is accurate as far as it goes: there is no licence fee for the core software. It says nothing about what running EverShop in production actually costs.

The Cloud tiers — Personal at $10/month, Professional at $20/month — are marked “Coming Soon” as of this research pass, so there is no managed-hosting price to compare self-hosting against today. Every EverShop deployment right now is a self-hosted one.

Self-hosting’s real cost drivers are the ones any self-hosted platform carries: your own PostgreSQL instance, compute for the Node/Express process, and developer time. The last one matters more for EverShop than for a platform with a deep extension catalogue, because a thin marketplace — covered next — means you cannot buy a pre-built integration to skip custom work.

GPL-3.0 belongs in the TCO conversation too. Distributing a modified build, or hosting a customised version for a client, can trigger source-disclosure obligations that MIT-licensed peers in this series do not carry. And unlike OroCommerce, Spryker or commercetools elsewhere in this series, there is no quote-based enterprise tier to move to if a deployment outgrows self-hosting.

Where EverShop’s cohesive TypeScript stack pays off

The strongest case for EverShop is boring in the best way: one language, TypeScript, across storefront, admin and API. A JavaScript-only team does not context-switch into PHP and Vue, or Python and a separate GraphQL layer, to make a change that touches the full stack. That is a real cost for peers elsewhere in this series, and EverShop removes it by design.

The modular monolith also reaches a first order faster than a headless-only stack. There is no separate storefront service to build or buy, and no API gateway to bolt on before the two sides can talk — GraphQL and REST are both available from npm run setup onward, so integrators pick a query style without adding infrastructure.

Release cadence backs up “actively maintained,” even if it is not fast. EverShop shipped v2.0.0 through v2.1.2 roughly every two to four months between July 2025 and April 2026, per the release history (opens in a new tab). The repository’s 10.2k GitHub stars point to genuine developer attention — this series treats stars as a signal of interest, never as proof of production adoption.

Where EverShop’s young ecosystem creates real friction

The official extensions marketplace (opens in a new tab), checked in this research pass, is small and entirely free. It covers notification and chat tools (Resend, SendGrid, Tawk, Tidio), one login provider (Google), one merchandising extension (Product Reviews), two storage connectors (Amazon S3, Azure Blob), and one theme. That is the complete catalogue as observed on this date, not a sample.

Nothing in that catalogue addresses multi-vendor selling, B2B account workflows, or AI-specific tooling. A team that needs any of those today is building it from scratch against EverShop’s core, not buying an extension off the shelf.

The REST API compounds the gap. Access control per route (opens in a new tab) is a single “public” or “private” flag defined in route.json — “private” means any authenticated admin credential can call it. There is no documented role or scope model, no idempotency-key handling, no rate limiting, and no OpenAPI or Swagger specification to generate a client from.

Outbound webhooks show the same pattern. No official system for delivering signed, retried HTTP callbacks to an external endpoint could be found in EverShop’s documentation. The documented “Events and Subscribers” (opens in a new tab) mechanism is an in-process event emitter: a subscriber runs inside the same Node.js runtime as core, so an external system waiting on an order event gets nothing over HTTP.

sequenceDiagram
    participant Core as EverShop core
    participant Sub as In-process subscriber
    participant Ext as External system (ERP, search index)
    Core->>Sub: emit('order.placed')
    Sub->>Sub: runs inside same Node.js process
    Note over Sub,Ext: No outbound HTTP call exists
    Ext--xCore: never receives a webhook

None of this is hidden — it is documented plainly, just easy to miss if you evaluate the stack name instead of the actual API surface. Adoption is modest but real: the npm registry recorded 362 downloads (opens in a new tab) of @evershop/evershop for the week of 18–24 July 2026, a concrete number alongside the star count rather than a replacement for one.

Modernity and AI/agent-readiness scores, with the working shown

This series’ modernity rubric weights seven components out of 10. Applied to EverShop 2.1.2:

That puts modernity in the middle of the range, roughly 5.5–6.5 out of 10: solid on maintenance, penalised where API boundaries and the extension model are thin.

The AI/agent-readiness rubric tells a harder story:

That puts AI/agent-readiness lower, roughly 3.5–4.5 out of 10 — the flat permission model and in-process-only events are the two components dragging it down hardest. Both ranges assume the hands-on installation pass finds nothing the documentation missed; treat them as provisional until it runs.

A modern stack is not automatically good architecture. This series’ rubric already discounts stack novelty and rewards boundaries, tooling and maintenance instead — a mature platform in an older language with strong API boundaries can outscore a TypeScript platform with a flat permission model, and here it does.

Production concern: every admin credential carries full access

EverShop’s access-control model is binary, and it applies to every private route the same way. Any admin credential that successfully authenticates — regardless of which user created it or why — can call any route flagged “private.” There is no per-role or per-scope restriction in the documented REST access model.

That is not an oversight buried in the code; it is an open, tracked gap. GitHub issue #359 (opens in a new tab), “Admin user/role management,” opened 12 October 2023, asks for multiple admin roles with API-scoped permissions. As observed in this research pass it is still open, sitting in the project’s “Backlogs” board with no maintainer roadmap comment. The documented admin workflow, npm run user:create, still creates flat, unscoped admin accounts — there is no role parameter to pass.

The practical consequence lands on integrations, not the storefront. A team that provisions a narrow, limited-purpose credential — say, a script that only updates inventory counts — gets full administrative reach the moment that credential authenticates at all. There is no way to scope it down inside EverShop itself.

Two mitigations work today, neither of them inside EverShop. Restrict which credentials exist at all, and treat every one as a master key. Put a reverse proxy or network-level gate in front of admin routes, so a compromised integration credential cannot reach the admin panel directly even if the API itself will not stop it.

{
  "url": "/api/products/:id",
  "methods": ["PATCH"],
  "access": "private"
}

The access field takes only "public" or "private" — there is no roles, scopes or permissions field to add. A role-based model would need something like this, which does not exist in EverShop today:

{
  "url": "/api/products/:id",
  "methods": ["PATCH"],
  "access": "private",
  // Not implemented — issue #359 requests a field along these lines
  "requiredScopes": ["products:write"]
}

Five questions to answer in an EverShop proof of concept

Run these five checks before committing engineering time to EverShop, not after.

Q1: Does the marketplace already cover what you need? The official extensions catalogue (opens in a new tab) is currently small and entirely free — payment, search, tax and marketplace integrations you assume exist may not. Confirm before scoping.

Q2: Can you live with flat admin access? Every valid admin credential has full access today, and issue #359 (opens in a new tab) has sat open since October 2023 with no roadmap comment. If go-live requires role-scoped admin accounts, that is not currently available.

Q3: Does your integration plan assume webhooks? EverShop’s event system is documented as in-process only. If an external system needs an HTTP callback, plan to build and sign that delivery layer yourself.

Q4: Have you tested against your real environment, not a laptop default? Run npm run setup and a full request cycle against your target’s actual Node 20.x, npm 9.x and PostgreSQL 13+ (15+ recommended) — not whatever happens to be installed locally.

Q5: Have you reviewed GPL-3.0 against your delivery model? If you plan to modify core or host a customised build for a client, get the source-disclosure obligation checked before you ship — this differs from the MIT-style terms some competing platforms in this series carry.

You should now see: a five-item go/no-go checklist you can run against your own environment and constraints before committing engineering time to EverShop.

Limitations

This review is based on EverShop’s documentation, repository and public issue tracker — not yet a hands-on install against this series’ evidence-box and platform-matrix requirements. Treat the version-compatibility and pitfall sections as documented behaviour until that installation pass confirms them directly.

Confirm before publication: whether v2.1.2 is still current, whether issue #359 has moved, and whether EverShop Cloud has left “Coming Soon.” Any of the three would change a section of this review.

This review checked the official extensions marketplace only. It did not survey community forks, unofficial extensions, or the project’s Discord for multi-vendor or B2B work happening outside that catalogue — absence from the marketplace is not proof of absence elsewhere.

It also does not offer a legal conclusion on GPL-3.0’s practical obligations for any specific commercial delivery model. Get that reviewed by counsel for your situation rather than relying on the general description here.