EverShop: a TypeScript ecommerce platform you self-host

What EverShop is for, and who it is actually aimed at

EverShop is a self-hosted storefront and admin panel written in TypeScript, with Express on the server, React on the client, GraphQL as the data layer, and Postgres underneath. The package.json description says it plainly: a shopping cart platform with Express, React and Postgres. That sentence is the whole product thesis. This is not a hosted service and not a plugin marketplace you install from a dashboard. It is a codebase you clone, run, and extend.

The audience follows from that. A developer who wants to add a loyalty rule, a custom checkout step, or a warehouse-specific shipping calculation has source files to edit and a module system to hang the change on. The README points at three separate documentation tracks: an installation guide, extension development, and theme development. Those three tracks are the intended workflow. If your plan is to open an admin panel and toggle features, EverShop gives you less than a hosted platform would, and you are paying the cost of running Postgres and Node yourself for no return.

The repository is a monorepo. The workspaces field lists packages/* and extensions/*, so both first-party code and add-ons live side by side under one lockfile. The top level also carries a seed/ directory, a translations/ directory, and a tests/ directory with an e2e subproject. That layout tells you what the maintainers expect to be part of a normal deployment: seeded catalog data, translated storefront strings, and browser-level tests.

The mechanism: Postgres, GraphQL, and a build step between you and production

The runtime shape is conventional and easy to reason about. A Node process serves the storefront and the admin, talks to Postgres over a connection described by DB_HOST, DB_PORT, DB_USER, DB_PASSWORD and DB_NAME, and exposes data through GraphQL. The client is React. Nothing here is exotic, which is a point in its favour for teams that already run Node services.

The part worth understanding before you commit is the build pipeline. The root package.json defines dev, build, start and setup as separate scripts, and they operate on compiled output rather than source. The dev and start scripts both point into packages/evershop/dist, not into src. The compile script uses swc to transform src into dist and copies non-TypeScript assets along the way; a separate compile:tsc script runs tsc and then copies .graphql, .scss, .css and .json files into dist and marks the CLI entry executable. GraphQL schema files and stylesheets are therefore build artifacts, not files loaded from source at runtime.

This matters operationally. Editing a .graphql file in a running production container does nothing until you rebuild. The Dockerfile comments make the same point from a different angle: dist/ is gitignored, and the comment states that no install hook creates it, so a container built from a working tree has to compile src into dist itself before the app will start. If you deploy by mounting your checkout over an image built for the released npm package, you will get a process that cannot find its entry point.

Installing EverShop with Docker and reaching the admin

The README gives a Docker path as the fastest route. It fetches the compose file from the repository and starts the stack in the background. Run these two commands from an empty directory:

curl -sSL https://raw.githubusercontent.com/evershopcommerce/evershop/main/docker-compose.yml > docker-compose.yml
docker compose up -d

The compose file defines two services. The app service uses the image evershop/evershop:latest, maps port 3000 to 3000, and waits on the database service. The database service is postgres:16, exposes 5432, and stores its data in the postgres-data volume. Both sit on a bridge network named MyEverShop. After the containers report healthy, the storefront should answer on port 3000 of the host.

The app service receives its database settings as environment variables, and they line up with the Postgres container's own defaults:

environment:
  DB_HOST: database
  DB_PORT: 5432
  DB_PASSWORD: postgres
  DB_USER: postgres
  DB_NAME: postgres

Those are the credentials in the published compose file. They are fine for a local look, and they are exactly what you must replace before the port is reachable from anywhere you do not control. The database service also publishes 5432 to the host, so on a machine with a public interface you have an open Postgres port with a known password.

To see the admin side without installing anything, the README links a demo store and a demo admin. The credentials it lists are [email protected] with the password 123456. For a source install rather than Docker, the README defers to the installation guide at evershop.io, and the root package.json shows the CLI commands a source setup uses: setup runs evershop install, user:create runs evershop user:create, and seed runs evershop seed.

Where the Docker defaults and the build model will bite you

The compose file is a starting point that reads like a finished deployment, and that gap is the first real hazard. Credentials are hardcoded, the database port is published, and restart: always is set on the app. None of that is wrong for a laptop. All of it is wrong for a host with an address. The README does not document a hardened production compose file, so the work of separating development defaults from production settings falls to you.

The second hazard is the build model described earlier. There are two Dockerfiles in play and the repository is explicit that they are not interchangeable. The published evershop/evershop image is built from docker/Dockerfile and installs the released @evershop/evershop package from npm. The root Dockerfile is a development image that builds the monorepo from source, and its comments state it must build from a clean checkout. If you fork EverShop to customize it, you are now maintaining a build that compiles src into dist on every image build, with swc or tsc, plus asset copying. That is a real CI cost, and it is the price of the customization the platform invites.

The third is scale of change. A platform that expects you to write modules and themes also expects you to track its internals across upgrades. The changelog.md at the repository root is where that history lives; the README does not describe an upgrade procedure or a rollback path, so treat version movement as something to test in a staging store with its own Postgres volume before it touches a live catalog.

EverShop against Medusa and Shopify

The comparison people search for is EverShop versus Medusa, and the difference is not which one has more features. Both are Node and TypeScript commerce backends you self-host. The distinction that matters is where the storefront lives. Medusa positions itself as a headless commerce backend: it supplies the commerce APIs and leaves the storefront to you, which is why Medusa projects commonly pair it with a separate frontend framework. EverShop ships a React storefront and an admin panel as part of the same repository and the same Docker image, so a fresh install gives you a working shop rather than an API waiting for a client.

That is a genuine trade. If your team already has a frontend it wants to keep, EverShop's bundled storefront is something you work around rather than something you get for free, and a headless backend would fit better. If you want a shop that renders on day one and you are willing to adopt its React conventions, EverShop removes a whole integration step.

The Shopify comparison is a different axis entirely. Shopify is a hosted service where the platform owns the infrastructure, the upgrade cycle and the compliance surface. EverShop is GPL-3.0 software you run on your own Postgres. Choosing EverShop means accepting the operational load that Shopify absorbs, in exchange for source-level control and no per-transaction platform fee. There is no version of this where EverShop is the lower-effort option; it is the higher-control option.

Licence, maintenance and the cost of staying current

EverShop is licensed GPL-3.0, and the repository states this in both the README and the LICENSE file. For a store owner running a modified EverShop on their own servers, the practical question is what obligations attach to distributing those modifications. GPL-3.0 is a copyleft licence, so if you convey a modified version to someone else, the source of your modifications generally has to travel with it under the same terms. Running it as your own storefront is a different situation from shipping it inside a product you sell. This is a real consideration for agencies building client stores and for anyone embedding EverShop in a commercial offering, and it is the kind of question to put to a lawyer rather than to a README. Nothing here is legal advice.

On maintenance, the facts are straightforward. The repository is not archived, and the last push was on 2026-09-17, days before this writing. The most recent release listed is v2.2.1 from 2026-08-12, preceded by v2.1.2 in April 2026 and v2.1.1 in February 2026. The root package.json carries version 2.2.1, matching that release. That is a cadence of a few releases a year, not a continuous stream, and the gaps between them are worth noting if you depend on a fix landing quickly.

The upgrade cost is tied to the build model. Because the deployed artifact is compiled from src, an upgrade means pulling new source, recompiling, and re-running your own modules and themes against the new GraphQL schemas and React components. The README does not document a migration tool or a rollback command, so a staging store with a disposable Postgres volume is the only safe place to find out what broke.

Editorial conclusion

Adopt EverShop if you have TypeScript developers who intend to write modules and themes against a GraphQL and React codebase, and if distributing your store under GPL-3.0 is acceptable. Do not adopt it if you need a vendor to carry the compliance burden, if you want a hosted SaaS with no server to run, or if your team will only ever click through an admin panel, because the value here is in the extension surface. Verify first that the current release installs cleanly under Node 20, that your Postgres 16 instance is reachable with the DB_HOST, DB_PORT, DB_USER, DB_PASSWORD and DB_NAME variables the docker-compose.yml expects, and that you are comfortable with the npm package name @evershop/evershop being the thing your production image actually runs.

Frequently asked questions

Official sources

1. evershopcommerce/evershop on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases