# Ever Demand: a headless on-demand marketplace platform with its own fleet of client apps

> Ever Demand is an AGPL-3.0 commerce platform for collaborative, on-demand and sharing economies, built as a Nest backend with GraphQL, REST and WebSocket APIs and several separate client applications. It is still labelled alpha, its published releases stop in 2020, and the demos are offline while the team moves to Kubernetes.

**ever-co/ever-demand** — Ever® Demand™ - Open Commerce Platform - https://everdemand.co

- Repository: https://github.com/ever-co/ever-demand
- Website: https://everdemand.co
- Stars: 1,868 · Forks: 474
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/ever-co-ever-demand

## The problem: a marketplace needs five applications, not one

An on-demand marketplace is not a shop with extra fields. The repository topics list the whole shape of the domain in one line: commerce, multivendor, logistics, fleet, routes, warehouse, inventory, driver apps, storefronts and transportation.

Each of those implies a separate application. A customer orders food or goods from a mobile app or a website. A merchant or warehouse accepts and prepares the order on a tablet. A carrier picks it up and delivers it from a phone, with the order's location tracked in real time. An administrator runs the whole thing from a web console. And somewhere underneath, the platform has to keep inventory, pricing, promotions, payments and delivery state consistent across all of them while the catalogue changes under it.

Ever Demand describes itself as an open platform for collaborative, on-demand and sharing economies, and its feature list covers exactly that spread. It supports single store and multi store, multi vendor, peer to peer and digital marketplace setups. It has a headless commerce framework, product catalogues global and per merchant, inventory and stock management, real-time order processing, delivery management with real-time location tracking, discounts and promotions, customer registration with guest checkout, and payment processing through Stripe.

The audience is therefore a company or team that has decided the on-demand marketplace is the product, rather than a developer who wants a nicer checkout. The scale of the codebase reflects that. This is a platform to fork and adapt, not a component to drop into a site.

## The headless core: one backend, three API styles

The architecture is a TypeScript monorepo built on Node and Nest, and the interesting decision is the headless commerce framework. The backend exposes rich GraphQL, REST and WebSocket APIs, which means the store fronts, admin interfaces and client apps are all consumers of the same backend rather than parts of it.

That matters for the number of clients in this repository. The list of front ends is unusually long: an Ionic 5 shopping mobile app, an Ionic 5 carrier mobile app, an Ionic 5 merchant tablet app, an Angular 9.1 shopping website built on an Angular starter, and an Angular 9.1 admin website built on ngx-admin. On top of that there are work in progress clients in React Native with Expo, and in Flutter with Dart.

The reactive claim is not decorative either. RxJS is used heavily throughout the platform, and the real-time part runs over WebSockets using Socket.io. For an on-demand order that moves through preparation, pickup and delivery, a polling design would be a poor fit, and the platform is built around pushed state changes instead.

Dependency injection is handled by InversifyJS in most parts of the platform, and on the backend and API the Nest container provides it. So there are two DI idioms in the codebase, which is a detail to keep in mind if you intend to extend the platform rather than just run it.

## The client apps and the ports the compose file assigns them

The docker-compose.yml file is the most useful single document for understanding the runtime, because it names every service and the port each one listens on. The database comes first:

```yaml
    db:
        image: mongo
        container_name: db
        restart: always
```

The data directory is mounted on a named volume so the database survives container restarts, and the container is exposed on the standard MongoDB port.

The application services follow the same pattern. The admin web service builds from.deploy/admin-web-angular/Dockerfile and runs yarn run:admin, and it is published on 4200:

```yaml
    admin-web:
        container_name: admin-web
        image: ever-admin-web:latest
        command: yarn run:admin
```

The shop web service builds from.deploy/shop-web-angular/Dockerfile, runs yarn run:shopweb and is published on 3000. The carrier mobile service builds from.deploy/carrier-mobile-ionic/Dockerfile, runs yarn run:carrier and publishes 4203 and 4204, which is the usual pattern for an Ionic app where the dev server and the live reload port are both exposed. The shop mobile service builds from the corresponding mobile Dockerfile and runs the shop mobile start script. Every service depends on the api service and joins an overlay network, so the containers reach each other by service name rather than by published port.

The older demo servers are visible in the project history, and the current state of the demos is stated plainly in the project documentation: they are not available at the moment, because the team is moving to Kubernetes and shutting down the old demo server. The commented out block in the project documentation still records the original layout, with the admin website on 4200, the shopping mobile app on 4201, the merchant tablet app on 4202, the carrier mobile app on 4203 and the shopping website on 3000.

## Building the monorepo: lerna, yarn workspaces and per package scripts

The repository is a lerna monorepo with yarn workspaces, and the root package.json is a script index rather than an application. The two commands that matter for a first build are:

```json
		"bootstrap": "yarn install --frozen-lockfile && yarn lerna bootstrap",
		"build": "yarn run build:common && yarn run build:common:angular && yarn lerna run --parallel build",
```

The bootstrap step installs from the lockfile with frozen lockfile enabled and then links the workspace packages with lerna. The build step compiles the shared code, compiles the shared Angular code, and then builds every package in parallel.

Each application has its own run script, and they all delegate into packages/ with a cwd flag:

```json
		"start:api": "yarn run:server",
		"run:server": "yarn run build:server && yarn --cwd ./packages/core run start",
		"run:admin": "yarn --cwd ./packages/admin-web-angular start",
```

The server script builds the server and then starts the core package, and there are equivalents for the merchant tablet, the shop mobile Ionic app, the shop Expo app, the shop web app and the carrier mobile app. So the whole platform can be brought up one service at a time from the repository root, which is what the compose file does.

Around the build there is a wide set of tooling: husky for git hooks, tslint for linting with a fix mode, stylelint configuration, prettier configuration, commitlint with a config file, a greenkeeper file, an ncu configuration for dependency version checks, and a crowdin configuration for translations. The repository also carries both.travis.yml and a Jenkinsfile, plus a.circleci/ directory, which is three CI systems for one project.

## MongoDB today, every other database planned

The database story is the clearest statement of the project's alpha status. MongoDB is used with the Mongoose ORM, with MongoDB version 3.2 supported and version 4 or later recommended.

There is an ongoing effort, marked as work in progress, to add support for other databases using TypeORM and Prisma. The stated list of databases that will be fully supported is MySQL, PostgreSQL, MariaDB, SQLite, MS SQL Server and Oracle. So the intent is a pluggable data layer, and the reality is one supported backend with a plan for six more.

The compose file shows the shape of the current arrangement, with a mongo image, a named volume for the data directory, a restart policy of always and the standard port published:

```yaml
        environment:
            - MONGO_DATA_DIR=/data/db
            - MONGO_LOG_DIR=/dev/null
        volumes:
            - mongo_data:/data/db
        ports:
            - '27017:27017'
```

For production, the project integrates and recommends PM2, and the .deploy/ directory holds the per-service Dockerfiles. The .gitpod.yml file and the Gitpod ready-to-code badge point at a browser based development environment, and the platform documentation is published separately at docs.ever.co with an overview diagram.

The scale of this is worth stating plainly. You are adopting a monorepo with seven or more client applications, two web front ends, a backend, a database and a container orchestration setup. The headless API is the part that is likely to survive contact with your requirements; the clients are the part you will probably replace.

## The feature list, and the four things that are still on the roadmap

The documentation separates current features from planned ones, and the planned list is short enough to be the deciding factor for many projects.

Planned: tax calculations. Third party shipping provider integrations. User roles and permissions across the platform. And large product catalogues with product variants, facets and full-text search. That last one is worth pausing on, because variants and facets are table stakes for any multi-vendor catalogue, and their absence from the shipped feature set tells you how much of the commerce problem is actually solved.

Plugins, extensions and custom fields are listed under current features but marked as work in progress. Payments are handled through Stripe, and the documentation does not describe other gateways. The topic list includes routes and fleet, which points to routing and driver management as part of the platform's scope rather than an add-on.

Multi-language and culture settings across the platform are listed as current, and the crowdin.yml file at the repository root suggests translations are managed through Crowdin. The project also publishes separate documentation repositories for the platform and for demos, and there are roughly thirty minute video introductions covering both Ever Demand and the related Ever Gauzy platform, plus one focused on the mobile shop customer experience.

So the honest read of the feature set is that the operational core of on-demand commerce, orders, inventory, delivery, tracking and payments, is present, while the reporting and merchandising depth is where the gaps are.

## Alpha status, AGPL-3.0, and what a fork commits you to

The project labels itself alpha in no uncertain terms. The disclaimer section says a word of caution, that the platform is very much under development, that you should expect a lot of changes and some bugs, and asks readers to be nice about it.

The dates back the label. The published releases are v0.3.0-alpha.3 on 2020-10-27, v0.3.0-alpha.2 on the same day, and v0.3.0-alpha.1 on 2020-08-30, which was described as a new architecture release with many features and fixes. The package version in the root package.json is 0.4.3, so the tree has moved past the last tagged release without a new tag. The repository is not archived and the last push was on 2026-09-27, and the default branch is develop rather than main.

The licence is AGPL-3.0, recorded both in the repository and in the root package.json. That is the network copyleft licence, and it is a heavy choice for a platform you intend to run as a service, because the copyleft obligation reaches users interacting with it over a network. The repository also ships a LICENSES.md file alongside the LICENSE, and the project documentation points you at the per-folder README and CREDITS files for the licences of the libraries included in the platform, so the licence position of the whole tree is spread across several documents rather than stated once.

The root package.json is marked private, which fits a platform that is meant to be forked rather than installed.

Read LICENSES.md and decide that question before you build a business on the code, because an AGPL platform that you modify and then host changes what you owe to the people who use it.

## Conclusion

Adopt Ever Demand if you are building a multi-vendor on-demand marketplace and want a headless backend with customer, merchant, carrier and admin clients already sketched out, and you are prepared to own an alpha codebase. Do not adopt it for a production launch, since the project describes itself as alpha, the demos are down, and the public releases stop at 0.3.0 alpha. Before you build on it, read LICENSES.md alongside the AGPL-3.0 licence file, confirm that MongoDB is acceptable as your only supported database, and check the planned feature list, because tax calculation, third party shipping providers and user roles are all still on the to-do list.

## FAQ

### What is Ever Demand and who is it for?

It is an open source, real-time, reactive commerce platform written in TypeScript for collaborative, on-demand and sharing economies, covering single store to multi-vendor and digital marketplace setups. It is aimed at teams building a full on-demand marketplace rather than a single store.

### How do I run the Ever Demand platform locally?

The docker-compose.yml file defines a MongoDB service plus one container per application, including admin-web on 4200, shop-web on 3000 and carrier-mobile on 4203 and 4204, all on an overlay network depending on the api service. The root package.json provides the per application run scripts such as run:admin and run:shopweb.

### Which databases does Ever Demand support?

MongoDB with the Mongoose ORM is the supported database, with version 3.2 supported and version 4 or later recommended. Support for MySQL, PostgreSQL, MariaDB, SQLite, MS SQL Server and Oracle through TypeORM and Prisma is described as an ongoing work in progress.

### Is Ever Demand production ready?

The project describes itself as alpha and under active development, with a lot of changes and some bugs expected. The published releases stop at v0.3.0 alpha from 2020, the demo servers are down while the team moves to Kubernetes, and features such as tax calculation, shipping provider integrations, user roles and large catalogues are still planned.

### What licence does Ever Demand use and what does it mean for a hosted deployment?

The licence is AGPL-3.0, recorded in the repository and in the root package.json, and the repository also ships a LICENSES.md file with details of the libraries included. The network copyleft reach of AGPL is the part to think about before running a modified version as a service, and the per-folder README and CREDITS files carry the licence details for the included components.

## Sources

- [ever-co/ever-demand on GitHub](https://github.com/ever-co/ever-demand)
- [License: AGPL-3.0](https://github.com/ever-co/ever-demand/blob/develop/LICENSE)
- [Project website](https://everdemand.co)
- [README](https://github.com/ever-co/ever-demand/blob/develop/README.md)
- [Releases](https://github.com/ever-co/ever-demand/releases)

---

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