EverShop

Last reviewed Aug 26, 2026 · 879 words

EverShop is a store for people who are comfortable inside a Node.js codebase, and a frustrating one for anyone else. The admin panel is clean, the storefront is React, the API is GraphQL, the Docker packaging is tidy. But the moment you need a payment gateway, a shipping rule or a theme change that the core does not ship, you are writing TypeScript. With about 10,400 GitHub stars and a first release in 2022, it is the most promising of the JavaScript-native stores. It is not yet a place a non-developer merchant should be left alone.

The stack is the selling point, and also the bill

Everything runs as one Node process plus PostgreSQL. No PHP, no MySQL, no Elasticsearch, no Redis to babysit. The catalogue lists 1 GB as the minimum and that is honest for the app on its own; put Postgres on the same box and 2 GB is the comfortable number. The storefront is server-rendered React with a build step, so the first start after an image pull takes a minute or two while it compiles, and a low-RAM VPS can OOM during that build even though it idles happily afterwards.

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: evershop
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: evershop
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    restart: unless-stopped
  evershop:
    image: evershop/evershop:latest
    environment:
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: evershop
      DB_PASSWORD: change-me
      DB_NAME: evershop
    ports:
      - "3000:3000"
    depends_on:
      - db
    restart: unless-stopped

The store answers on port 3000 and the admin lives at /admin. The first admin user is created from the CLI rather than a setup wizard, with npm run user:create inside the container, passing an email, password and name. Check the current flags in the project docs before you rely on my memory of the syntax; they have changed once already.

Extensions are code, not downloads

This is the section that decides whether EverShop is for you. WooCommerce has a marketplace of tens of thousands of plugins; you click, you pay, you have a loyalty scheme. EverShop has a module system where a feature is a directory under extensions/ with its own routes, GraphQL resolvers and React components, and a theme is a directory under themes/ that overrides storefront components. The official catalogue of ready-made extensions is short, with payment integrations for the big two card processors and a handful of others. Anything beyond that, you build.

For a developer that is a feature. The codebase is small enough to read in an afternoon, the module boundaries are real, and adding a custom pricing rule is a few files rather than a fight with hooks. For a merchant it means every "can the store do X" question has a labour cost attached. The catalogue's two listed cons, young project and smaller ecosystem, are the same con seen from two angles.

Where it fits against the other open-source stores

I place it like this. Medusa is headless: it gives you a commerce backend and expects you to build the storefront, which is more work than EverShop but more freedom. nopCommerce is the opposite: feature-complete out of the box, multi-store and multi-vendor in core, but you customise it in C#. WooCommerce and PrestaShop are the PHP incumbents with the biggest plugin markets and the most security bulletins. EverShop sits between Medusa and the PHP crowd: a working storefront on day one, a modern codebase, a thin ecosystem. The rest of the ecommerce category is worth ten minutes before you commit, and if you are leaving Shopify specifically, the Shopify alternatives page covers what you lose (mostly hosted payments and fraud screening).

Running it in production means three unglamorous jobs

First, TLS and a reverse proxy. Caddy with a one-line reverse_proxy localhost:3000 gives you certificates automatically, and a store without HTTPS is not a store. Second, backups: a nightly pg_dump of the database plus the uploaded media directory, shipped off the machine. Product images are not in Postgres, and I have watched someone restore a perfect database into a store with 400 broken thumbnails. Third, version pinning. A project this young ships breaking changes between minors more often than a decade-old platform does, so replace latest with an explicit tag, read the release notes, and upgrade on purpose. Test the upgrade against a copy of the database first; migrations on a live catalogue are not the place to learn.

What I'd do

If I were a developer building a store for myself or a client, and the requirements were "sell physical products, take cards, look modern", I would pick EverShop over the PHP options and enjoy the codebase. I would pin the image tag, run Postgres 16 alongside it on a 2 GB VPS, put Caddy in front, and budget a week for the extension I inevitably need to write. If I were a merchant with no developer on call, I would not, and I would say so plainly: nopCommerce or a hosted platform will cost less in stalled Tuesday afternoons. EverShop's trajectory is good. Its ecosystem is not there yet, and the honest verdict is to buy the codebase, not the marketplace.