InnoShop: a Laravel 13 storefront with MCP built into the core

What InnoShop solves, and for whom

Most PHP storefronts assume one language and one currency until you bolt on the rest. InnoShop inverts that. The README describes it as a globally oriented system with multi-language and multi-currency support, and the flag strip at the top of the file lists the locales it ships: Arabic, German, English, Spanish, French, Indonesian, Italian, Japanese, Khmer, Korean, Malay, Dutch, Portuguese, Brazilian Portuguese, Russian, Thai, Turkish, Vietnamese, Simplified Chinese and Traditional Chinese. Those are the languages the project advertises, and the .env.example sets APP_LOCALE=zh-cn with APP_FALLBACK_LOCALE=en, so the default install is not English-first.

The target reader is a PHP team that wants to own the storefront code rather than rent it. InnoShop is a Laravel application, not a hosted service, and the repository layout puts app/, plugins/, themes/ and innopacks/ at the top level. That layout is the pitch: the same codebase holds the application, the extension points and the bundled packages. A developer who has run any Laravel project will recognise routes/, config/, database/ and resources/ immediately. There is no separate admin framework to learn before you can change a template.

How the Laravel 13 core, plugins and MCP fit together

The stack is conventional Laravel with two additions. The first is the extension system. The README describes a highly cohesive, low coupling modular design intended to make plugin development quick, and the repository carries three directories that support it: plugins/, themes/ and innopacks/. The README does not spell out how a plugin registers itself, so the loading contract has to be read from the code rather than the documentation. That is a real gap if you plan to publish extensions.

The second addition is MCP, the Model Context Protocol. The README states that InnoShop integrates multiple AI models and native MCP for intelligent automation, and the repository topics include mcp and mcp-server. MCP is the interface an AI client uses to call tools exposed by an application, so a native implementation implies InnoShop exposes store operations to an AI client rather than only calling an AI API from PHP. The README does not document which operations are exposed, which models are supported, or how authentication works. Treat the MCP layer as the most interesting and least specified part of the project.

Front-end assets are built by a custom script rather than a stock Vite config. package.json maps dev, build, prod and production all to node build.js, and the dependencies are Bootstrap 5, Bootstrap Icons, CodeMirror 6, jQuery and Sass. If you maintain a theme, that build.js file is the entry point you will be editing.

Installing InnoShop with Composer and reaching the setup wizard

The README gives three install paths and recommends Composer. The requirements are PHP 8.3 or newer with bcmath, cURL, dom, fileinfo, libxml, OpenSSL, PDO and simplexml; Composer 2.x; Node.js 18 or newer with npm 9 or newer; and MySQL 5.7 or 8.0, with SQLite offered for a local try-out.

The Composer route creates the project and starts Laravel's development server:

composer create-project innoshop/innoshop
cd innoshop
php artisan serve

According to the README, create-project also installs PHP dependencies, generates the application key, and runs npm install and npm run build. Open http://localhost:8000 and the installation wizard collects the database settings and the admin account. If the build step fails, the storefront will load without compiled assets, so check the npm output before assuming the install is fine.

If the server has PHP but no Node.js, the README points to the prebuilt archives on GitHub Releases. Download innoshop-vX.Y.Z.zip, unpack it, fix permissions on the two writable directories, and start the server:

git clone https://github.com/innocommerce/innoshop.git
cd innoshop
composer install
npm install
npm run build
cp .env.example .env
php artisan key:generate
php artisan serve

That third block is the README's contributor path, useful when you intend to modify the core. Note the .env.example defaults: DB_CONNECTION=mysql, DB_PREFIX=inno_, DB_HOST=127.0.0.1, DB_PORT=3306, SESSION_DRIVER=database, QUEUE_CONNECTION=database and CACHE_STORE=database. The inno_ prefix means InnoShop can share a database with another application without table collisions, which is convenient on a box that already runs something else. The database-backed session, queue and cache defaults also mean a fresh install has no Redis dependency, though the example file does list REDIS_HOST and REDIS_PORT for when you add one.

Where InnoShop falls short

The licence is the first problem. The README badge says OSL 3.0, but the repository metadata reports the licence as NOASSERTION, meaning GitHub could not map LICENSE.txt to a recognised identifier. Those two signals disagree, and the README does not explain the discrepancy. Before you ship a commercial storefront on this, read LICENSE.txt itself. The Open Software License is a copyleft licence with a network-distribution clause, so the terms matter for anyone running a modified InnoShop as a public service. This is a description of the file, not legal advice.

The second problem is release maturity. The most recent release listed is v0.9.2 from 2026-08-09, preceded by v0.9.0 and v0.8.2. A 0.9 version line means the project has not declared a 1.0 yet, and the README does not document an upgrade procedure between releases or a rollback path if one goes wrong. For a store that takes payments, that is the question to answer before adopting, not after.

The third is documentation depth on the parts that make InnoShop distinctive. The README links to docs.innoshop.cn in English and to two API hosts, front-api.innoshop.cn and panel-api.innoshop.cn, but the README text itself does not describe the plugin registration API, the MCP tool surface, or the theme override rules. If your adoption decision depends on those, you are reading source code, not docs.

Finally, the project is not the right tool if you want a storefront with no server to run. Every install path here ends with PHP serving the application.

InnoShop against Bagisto and Aimeos

The two comparisons that come up most often are Bagisto and Aimeos, and both are also Laravel-based, so the difference is not the framework.

Bagisto is the closer match in shape: a Laravel e-commerce platform with its own admin panel and a package-based extension model. The practical difference is where the AI and MCP layer sits. InnoShop advertises native MCP support and multiple AI model integrations as core features, while the README gives no indication that Bagisto does the same. If exposing store operations to an AI client is the reason you are shopping, InnoShop is the one making that claim. If you want the platform with the longer record of third-party extensions, that is a different question and this article does not answer it.

Aimeos takes a different architectural route. It is built as a set of Composer packages that you pull into an existing Laravel or Symfony application rather than a standalone application you clone. That makes Aimeos the better fit when e-commerce is one module inside a larger system you already control. InnoShop is the opposite: a complete application with its own admin panel, its own front-end theme system and its own install wizard. Choose based on whether you want to embed a shop or run one.

Maintenance, upgrades and what the licence file implies

The repository is not archived, and the last push was on 2026-09-07, which is recent. The release cadence visible in the release list is three releases between 2026-05-28 and 2026-08-09, roughly one every four to six weeks. That is a project still moving, and it also means the code you build against today will move under you.

Upgrade cost is the part the README does not cover. There is no migration guide in the README, no changelog excerpt, and no documented rollback step. Because InnoShop is a Laravel application rather than a library, an upgrade means replacing application code, not bumping a version in composer.json. If you customise app/ or themes/, you will be merging. The plugins/ and innopacks/ directories exist to keep customisation out of the core, and using them is the cheapest insurance against that merge work.

On licensing, the README badge states OSL 3.0 and the repository metadata states NOASSERTION. Those are the two facts available. Anyone planning to modify InnoShop and run it as a public service should read LICENSE.txt and get their own advice, because the OSL's network clause is the kind of term that changes what you can do with a derivative.

Editorial conclusion

Adopt InnoShop if your team already runs PHP 8.3 and Laravel and you want a storefront whose plugin and theme directories you can edit directly, with multi-language and multi-currency present from the first install. Skip it if you need a long track record of production deployments or a licence your legal team can classify from the repository alone, because LICENSE.txt is not recognised as a standard identifier and the README does not document an upgrade or rollback path between releases. Verify two things before committing: open LICENSE.txt and read the actual terms, and read the plugin and theme loading code under innopacks/ to confirm the extension points match how your team works.

Frequently asked questions

Official sources

1. innocommerce/innoshop on GitHub
2. Issues
3. Project website
4. README
5. Releases