GrandNode is a .NET marketplace where the plugins and the storefront are separate layers

One application, several shops and several vendors

GrandNode is described as a free, open source e-commerce platform written in C# on ASP.NET Core with MongoDB as its database. The pitch in the README is that it runs a single online shop just as well as a multi-store installation or a multi-vendor marketplace, serves B2B and B2C customers from the same catalog, and exposes a REST API for headless storefronts, mobile apps and integrations with ERP, PIM and CRM systems.

That combination is what separates it from a plain shopping cart. The multi-store story means many storefronts, domains and catalogs from one installation, each with a separate store owner panel, so a company with several brands is not running several applications. The multi-vendor marketplace story means vendors manage their own products and orders in a dedicated vendor panel, which is a different role from the store owner, and the two panels are separate in the feature list rather than one admin with a role switch.

B2B and B2C from the same catalog is the third axis, and it is implemented as customer groups, tier prices and sales employees, so a wholesale customer and a retail customer can browse the same products with different prices.

The audience is stated plainly: developers and agencies on .NET who need a shopping cart they can host anywhere, on Linux, Windows, in Docker or Kubernetes, and extend with plugins and themes, without per-store licence fees. That last clause is the commercial argument, and it is worth pricing against a hosted platform that charges per additional store.

MongoDB is the core store, with document databases as options

The database story is the technology stack's most consequential choice, and it is narrower than a relational store would be.

The stack table says MongoDB 4.0 or newer, and the prerequisites repeat it: a local server, a Docker container or a MongoDB Atlas cluster all work. Alongside it the table lists Azure Cosmos DB and Amazon DocumentDB through the MongoDB API, and LiteDB for small installs.

The Cosmos DB and DocumentDB entries are the ones to read carefully, because the qualification is through the MongoDB API rather than native drivers. That is the difference between a database you can point the application at with a connection string and one the application was written for. The API compatibility is designed to let existing MongoDB applications run against them, and it generally does, but the set of supported operations is a subset, and a project that leans on an operation outside that subset finds out at runtime rather than at design time.

LiteDB for small installs is a different kind of accommodation, an embedded option for a small shop that does not want to run a database server. It is listed as an option rather than a supported scale path.

For a buyer, the practical question is whether the deployment target is a plain MongoDB server or one of the API compatible services, because the latter is where a schema assumption can become a production incident. The README does not document a feature matrix for the differences.

Plugins, themes and modules are three separate extension points

The extensibility column of the technology stack lists plugins, themes and modules, and the plugin categories are named: payments, shipping, tax, widgets, authentication and discount rules.

That list is the practical shape of the platform. Payments arrive through plugins, with Stripe Checkout, Braintree and cash on delivery all named, so a new payment provider is a plugin rather than a fork. Shipping is the same, with fixed rate, by weight and pickup points. Taxes too, fixed rate or by country, state and zip code.

Themes are a second layer, and here the platform ships three: Default, Modern and Nordic Editorial, with per-store theme selection, so two stores in the same installation can look different. The storefront is Vue 3 with Bootstrap 5, bundled with Vite, and the admin panels are Bootstrap 5 with Tabulator grids, with three of them: the Admin panel, the Store owner panel and the Vendor panel.

Modules sit alongside plugins in the source tree, and the Dockerfile shows that they are separate build targets. The build stage compiles every directory under Modules and then every directory under Plugins, each as its own dotnet build, before publishing the web project. That is the architecture in one file: the application is the host, plugins and modules are units that are built and dropped in, and the entry point is a single managed assembly.

It also means a plugin is a first class software artifact with its own build, which is what makes a third party extension ecosystem plausible.

Marketing, SEO and merchandising are in the box

The feature list is long, and the parts worth singling out are the ones that usually need a plugin in a smaller platform.

On the search engine side the platform claims clean URLs, meta tags, canonical URLs, XML sitemaps and schema.org JSON-LD carrying price, availability, rating, shipping and return policy. The JSON-LD detail matters more than it looks, because a product feed without price and availability markup is a common reason a shop indexes but does not rank, and returning the policy fields is a level of care that suggests the templates were written by people who have run a store.

Discounting is not just coupons. The list covers coupon codes, discount rules, loyalty points and gift vouchers, and the discount rules are a plugin category, so a bespoke pricing rule is an extension rather than a patch. Customer segmentation can target customer groups and tags with content, prices and discounts, which is the mechanism behind tier pricing for B2B.

Messaging covers message templates, campaigns and push notifications, and analytics integrations with Google Analytics and Facebook Pixel are built in rather than bolted on.

The catalog is the other deep area. It supports product attributes and combinations, bundles, grouped products, downloadable products, reservations and auctions, and the last two are not things every platform bothers with. Whether those are the features you need, or whether they are features the platform needs to justify its scope, is a question worth asking before you commit.

The Docker image is a two stage build with a non-root runtime

The Dockerfile is short and tells you the deployment model.

The build stage uses the .NET SDK 10.0.301 image, copies Directory.Packages.props and the src/ tree, and then builds each module and each plugin in turn with dotnet build in Release configuration, passing SourceRevisionId and GitBranch as build properties from ARG values. It finishes by publishing the Web project with dotnet publish into a release directory.

The runtime stage uses the ASP.NET 10.0 image, exposes 8080, and copies the published output in. It then creates the media directory and gives ownership of App_Data, wwwroot, Plugins and media to the app user, and switches to USER app. The entry point is dotnet Grand.Web.dll.

The non-root user and the explicit ownership of those four directories are the details to note, because they are what makes the container work with a read-only root filesystem and a volume mount for the media. The media directory has to be writable, and it is the one path that a deployment will normally back up.

The build properties are also worth a mention for anyone who wants a versioned artefact, since embedding the commit and branch into the build means a running container can be traced back to a commit.

Quick start with Docker and one connection string

The quick start is a Docker sequence, and it is short enough to run as written.

docker network create grandnode
docker run -d --name mongo --network grandnode -v grandnode_db:/data/db mongo
docker run -d --name grandnode2 --network grandnode -p 80:8080 -e Application__MediaPath=/app/media -v grandnode_appdata:/app/App_Data -v grandnode_media:/app/media grandnode/grandnode2

The first command creates a network so the two containers can talk by name. The second runs MongoDB with a named volume for the data directory, and the third runs the application with the media path set through the Application__MediaPath environment variable, with named volumes for the application data and the media, and with host port 80 mapped to the container's 8080.

After that, open http://localhost, and the installer asks for the MongoDB connection string, which in this setup is mongodb://mongo:27017/grandnode.

The volumes are the part to understand. Two named volumes are mounted, one for the application data and one for the media, so both survive a container replacement and both need to be in your backup. The environment variable is worth noting as well, because the double underscore is the standard way to express a nested configuration key in.NET, and it tells you the application's configuration is read from environment variables with the settings tree flattened into names.

Branches, releases and where the support comes from

The branching model is stated in the prerequisites section and it is the thing to check before you pick a version. The develop branch is the development version and may be unstable, main holds the latest stable version, and stable versions are also on the Releases page. The default branch of the repository is develop, which means a clone of the repository by default gives you the development branch rather than a released state.

The recent releases are 2.4.0 on 2026-10-04, a 2.4.0 Beta on 2026-09-13, and 2.3.0 from March 2025. The last push was on 2026-10-15 and the repository is not archived, so the project is being worked on. The README also links an LTS and support page, which is the commercial answer to the question of who maintains it over years.

The engineering infrastructure is visible in the badges. There is a workflow running the tests on Linux, macOS and Windows, a Docker image CI workflow, and CodeQL Advanced for static analysis of the code. azure-pipelines.yml holds the build pipeline, .sonarcloud.properties the SonarQube configuration, and there is a GrandNode.slnx solution file, which is the newer sparse solution format, along with Directory.Packages.props for central package management across the modules and plugins.

The repository also carries the documentation a commercial project needs: SUPPORT.md, SECURITY.md, CODE_OF_CONDUCT.md, PULL_REQUEST_TEMPLATE.md, CONTRIBUTING.md, an AGENTS.md and a CLAUDE.md for automated agents, and a docs/ directory.

The licence is GPL-3.0, which is the one item to weigh carefully. An open source e-commerce platform that you host and extend is a normal use of copyleft code, but the obligation to publish modifications of the platform itself is a real consideration for an agency that plans to keep its customisations private, and it is a question to answer before the first plugin is written.

Editorial conclusion

GrandNode suits a .NET agency or developer who needs a shop, several shops, or a marketplace with vendor panels, and who wants to run it on their own infrastructure without per-store licence fees. It does not suit a merchant who wants a hosted storefront with someone else's operations team, and it is the wrong choice for a catalogue that is small enough for a hosted platform to run in minutes. Verify first that your hosting target matches what the runtime image expects, since the container publishes port 8080 and runs as a non-root user with a media volume, and that the release you take is the stable branch rather than develop, which the README warns may be unstable.

Frequently asked questions

Official sources

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