Virto Commerce: a modular .NET platform for B2B and headless commerce

What Virto Commerce is

Virto Commerce is an open source platform for building extensible ecommerce applications. The README scopes it to complex digital commerce for B2B, B2C and B2B2C businesses, to marketplaces, and to SaaS commerce platforms derived from it. The main site is virtocommerce.com, and the repository is the platform itself, written in C#.

The stated purpose is to let development teams work on business features rather than on the clean architecture underneath. Everything else in the project follows from that goal. The architecture is described with five principles: microservices, API-first, cloud-native, headless and advanced extensibility, and the documentation for each of those is linked from the README as a separate page, which is how the project explains what it means rather than asserting it.

The five are not independent. A module is a headless microservice with its own business logic, reached through an API, so it can be deployed and scaled on its own. Because the business logic is reachable through an API, the storefront and the admin interface are clients of the same services, which is what makes the platform headless in practice rather than in principle. And because a module can extend the API model, the persistence model and the business logic, a custom module is a first class way of building rather than a fork.

The licensing is not a standard open source licence. The repository badge names it as VC OSL, the Virto Commerce Open Source License, and the metadata lists a custom licence GitHub cannot categorise, with the terms in the LICENSE file. That is a material fact for a platform meant to be extended commercially, and it is the first thing to read before evaluating the rest.

The architecture vocabulary: modules and atomic architecture

The layers in the README's architecture description are worth reading as a map.

The Virto Commerce Platform is the layer that launches the commerce applications in public, hybrid and private cloud environments. Above it sit the commerce applications, which are an API-based, modular and extensible set of one or more headless microservices focused on a business area: digital catalogue, order management, content management, marketing and others. Next come custom extensions, described as Virto Commerce modules that extend the API model, the persistent model, the business logic and the admin user interface within those applications. Then external commerce applications, third party services. Then the touchpoints, the places a customer actually meets the platform: a website, a mobile application, a chatbot, a marketplace, a dropshipping arrangement. The admin SPA is the operator interface, and the integration middleware handles asynchronous declarative integration with non-real-time and legacy services.

Atomic architecture is the term the project uses for assembling a solution from ready-made modules, and the commerce application is the unit of assembly.

The Storefront Kit is what connects the touchpoints: it lets an operator manage several brands and stores in one environment with the same features, which is the mechanism behind the marketplace and multi-brand cases.

The integration middleware is the piece with a specific job, and it is the one that shows how the platform thinks about legacy systems. Rather than calling a legacy service synchronously from inside a business flow, the platform describes the interaction declaratively and processes it asynchronously, which keeps a slow partner system from becoming a latency problem inside an order transaction.

API-first, headless and the admin SPA

The API-first principle in the README is a specific commitment: all business logic is accessible through an API, either REST or GraphQL. That is the difference between a headless platform in name and one in practice, because with no server-rendered pages in the way, a storefront, a mobile app and a partner integration all consume the same contract.

The extension story is what makes the platform distinctive, and the README is explicit about the three layers a module can extend: the API model, the persistence model and the business logic. Extending the API model means adding endpoints, extending the persistence model means changing how data is stored, and extending the business logic means changing what the domain does. Most platforms let a plugin add a route or a field. Allowing a module to change the data model without a fork is the part that determines whether a platform can absorb a business requirement that was not anticipated when it was written.

The admin interface is a single page application, and the README describes it as extensible and intuitive, with the ability to manage data across all channels from one place. The repository topics list Angular, so the admin is an Angular application, and the storefront side is separated from it entirely, which is the split a headless architecture requires.

The interesting consequence is that the admin and the storefront are both clients. An operator action in the admin SPA is an API call like any other, which means the same module that adds a catalogue field also has to add the admin screen for it, and the extension contract covers the interface as well as the data.

What the repository contains and how it deploys

The tree is that of a large .NET solution. VirtoCommerce.Platform.sln is the solution file, with Directory.Build.props at the root for shared build properties, and src/, tests/, specs/ and benchmarks/ as the code directories. MkDocs.md and mkdocs.yml are the documentation setup, which matches the documentation site at docs.virtocommerce.org.

The deployment artefacts are the most telling part of the tree, because they show which platforms the platform is expected to run on:

VirtoCommerce.Platform.sln
Directory.Build.props
DockerCompose/
argoDeploy.json
azureDeployPlatformAndFrontend.json
cloudDeploy.json
deploy.cmd
mkdocs.yml

There is a Docker Compose setup, a set of Azure deployment descriptors for the platform, for the platform with the frontend, and for a web app for containers, an Argo deployment file, and a Windows deploy script. The repository topics list Azure and Microsoft Cloud, and the cloud-native principle in the README is described in SaaS terms, so the Azure path is the primary target and the container and Kubernetes paths are the more portable ones.

There is also a .deployment directory, an overrides/ directory, a module.ignore file, a cve-ignore.json for vulnerability handling, and a 3rd-party-components.md that records the third party components used, which is the kind of file an enterprise buyer asks for during a security review. The CI workflow runs against the dev branch, and the README badges show a SonarCloud quality gate with reliability, security and maintainability ratings, so the project enforces static analysis rather than treating it as optional.

Releases, versioning and the dev branch

The release numbers are unusual and are worth understanding before you plan an upgrade. The recent tags are 3.1084.0, 3.1076.5 and 3.1039.14, all published on 2026-10-15. The third component looks like a build number rather than a semantic version, which means the platform is versioned per module and per bundle rather than as a single application version.

That is consistent with the module model. A customer running a subset of modules needs to know the version of each one, and the release train publishes them together. The default branch is dev, and the CI workflow and the SonarCloud badges all point at dev, so the branch is the integration point rather than a release branch.

The project also publishes release material outside the repository. The README links release decks presented at virtocommerce.github.io/vc-release-notes, including one document for business users on the release strategy, which describes how the platform ships, the module and bundle structure, the cadence and what it means for a roadmap, and another on integration capabilities. There is an interactive demo linked from the README, which is the fastest way to see what the platform looks like before reading the architecture pages.

The community is a Discourse forum at virtocommerce.org, and there is a YouTube channel, both of which are the usual places to look for how other teams run the platform.

Where Virto Commerce is the wrong tool

The first case is a small shop with a simple catalogue. The platform is built for complex B2B: approval workflows, tiered pricing, multiple catalogues, contracts. A team with a hundred products and one customer type is paying for a module system, an admin SPA, a headless API and a deployment pipeline it will not use, and the alternative of a hosted SaaS store or a simpler .NET commerce product costs less in both money and attention.

The second case is a team that does not want to write modules. The value proposition depends on the extension model. If the requirements fit the existing modules, the platform is a good fit; if they do not, someone has to build a module, and a module is not a plugin, because it can change the API, the persistence and the business logic and therefore has to be maintained against every platform upgrade. That is a long term engineering commitment, not a configuration exercise.

The third limitation is the licence. VC OSL is not a permissive licence, and it is not one of the familiar ones, so a company with an open source policy will need legal review rather than a glance. For a platform intended to be modified and resold, the terms of that modification are the whole question, and the README does not summarise them.

The fourth is the operational surface. Microservices, a headless API, an Angular admin, container and Kubernetes deployment and an asynchronous integration middleware is a lot of infrastructure for an ecommerce team that may be three developers. The alternative for a team of that size is a hosted platform with the operational burden taken away, and for a team that has already chosen Azure and already runs containers, the platform's deployment scripts are a genuine advantage over assembling the same stack by hand.

Editorial conclusion

Virto Commerce fits a team with complex catalogue, pricing and approval rules, especially a B2B operation that needs to extend the platform without forking it, since the module model is the product. It does not fit a small shop with a simple catalogue, where the platform machinery costs more than the feature set is worth. Check first that your requirements fit the modules you would buy, because the architecture assumes a custom module is a normal way to build.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. VirtoCommerce/vc-platform on GitHub