Open-source project
beikeshop/beikeshop avatar
beikeshop/beikeshop

BeikeShop: A Laravel 12 Storefront Where Plugins Replace Core Edits

Free and Open-Source, Easy-to-Use Laravel eCommerce Platform,It supports multiple languages and currencies, Integrates AI agents and MCP.The platform features customizable visual design and a rich plugins on marketplace.

1,963 stars423 forksPHPNOASSERTION

At a glance

What is it?
BeikeShop is a self-hosted PHP ecommerce platform on Laravel 12 that ships products, checkout, multi-currency and a plugin marketplace. The interesting part is not the feature list but the hook and event system that keeps extensions out of the core, and the licence file that does not name a licence.
Who is it for?
Adopt BeikeShop if you are a PHP team that wants a Laravel 12 storefront you can extend through hooks and events without forking the core, and you are willing to run your own server. Do not adopt it if you need shared hosting (the README rules it out), if you cannot read the licence text before launch, or if you expect a plugin ecosystem you can audit before installing.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository last received commits 7 days ago.
What is it written in?
Mainly PHP, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem BeikeShop targets: extension without forking

Most self-hosted storefronts fail at the same point. The first month is fine. Then a payment gateway, a shipping rule or a checkout field needs to change, someone edits a core file, and every later upgrade becomes a merge. BeikeShop's answer is architectural rather than commercial: the README describes a modular, event-driven design with a Hook and Event-based system, and states that developers extend features through non-intrusive customization so the core code remains untouched. The stated goal is maintainability across upgrades. The audience is narrow and clear: PHP developers and small businesses who want to own the code and the data, run the store on their own server, and treat the platform as a base to build on rather than a service to rent. The README lists the use cases directly: PHP and Laravel ecommerce projects, custom online stores, international ecommerce, and open source ecommerce learning. The multi-language and multi-currency support is listed as native, which matters if you sell across borders, but the platform itself is not a hosted product. You supply the server, the database and the upgrade discipline.

How the hook and event layer changes the upgrade math

The mechanism worth understanding is the extension model. BeikeShop is a Laravel 12 application following MVC, with Blade templates and Vue.js on the frontend, and the README places the Hook and Event-based system alongside middleware and a Webhook Engine as the security and logic layer. The practical consequence is that a plugin subscribes to events the core emits instead of patching core files. When you upgrade, the documented source-code path is git pull, composer install, php artisan migrate. If your customizations live in plugins that hook into events, that sequence does not have to reconcile your edits against upstream changes. This is the same trade-off every event-driven platform makes: you gain upgrade safety and you lose the ability to see the whole request path in one file. Debugging a checkout behaviour means tracing which listeners fired, not reading one controller top to bottom. The README does not document the event catalogue or the hook registration API, so the depth of coverage is something you would have to check in the docs or the source before committing to the pattern. The repository also carries a multi-vendor ecommerce topic, and the description mentions AI agents and MCP integration, but the supplied material gives no configuration detail for either, so treat both as unverified until you read the docs.

Three install paths and what each one commits you to

BeikeShop documents package distribution, source code and Docker, and the differences matter more than the README admits. The source path is the most transparent: git clone the repository, composer install, cp .env.example .env, php artisan key:generate, npm install, npm run prod, then php artisan beikeshop:install. Set public as the web root. Upgrades are git pull, composer install, php artisan migrate. The package path is for people who do not want a git checkout on the server: download from beikeshop.com, unzip, point the web root at public, and complete the browser wizard. Upgrades there mean overwriting files while keeping .env, then running php artisan migrate. That overwrite step is the one to think about, because it is exactly the operation that clobbers core edits, which is why the hook system exists. The Docker path is the most reproducible. The repository ships install.sh, which the README says you can run after chmod +x install.sh. Manually, the documented sequence is cp .env.example .env, append APP_CODE_PATH=. and DB_HOST=mysql to .env, then docker compose --profile nginx up -d --build, docker compose exec nginx composer install, and docker compose exec nginx php artisan beikeshop:install --force. The README also points AI agents at AGENTS.md and install.sh for automated installation, which is an unusual thing to find in an ecommerce README and suggests the maintainers expect agent-driven deployment. Environment requirements are explicit: an independent server, shared hosting not supported, Ubuntu 22+ or CentOS 8.5, PHP 8.2+, MySQL 5.7+, Nginx 1.10+ or Apache 2.4+, plus a long extension list including BCMath, cURL, GD, Mbstring, PDO, SimpleXML and ZIP. Check that list against your host before anything else.

The licence file does not name a licence

The repository metadata reports the licence as NOASSERTION. That is not a licence name. It means the automated classifier could not map the licence file to a known identifier, which can happen for a custom licence, a modified licence, or a file the tooling does not recognise. The README calls the project 100% open-source and promises full ownership of code and data, and the homepage and download page are the commercial surface. None of that tells you the terms. If you are evaluating BeikeShop for a commercial store, read the licence file in the repository yourself, and if the terms are unclear, ask the maintainers directly before you build on it. This is not a legal opinion and it is not a reason to avoid the project; it is a gap in the supplied material that you should close before adoption. The same caution applies to the plugin marketplace. The README says a rich plugin marketplace exists, but plugins are separate artifacts with their own licences, and nothing in the supplied material describes how they are distributed, versioned against core releases, or reviewed. A platform whose extension story is its main selling point needs that story documented.

Where a Laravel shop stops being the right answer

The clearest limitation is hosting. The README states that shared hosting is not supported and that an independent server is required. That single line removes a large part of the audience that picks up PHP ecommerce platforms, because the appeal of PHP has traditionally been cheap shared hosting. BeikeShop asks for Ubuntu 22+ or CentOS 8.5, PHP 8.2+, MySQL 5.7+, and a web server you configure, with public as the document root. If you cannot operate that, the platform is the wrong tool regardless of features. The second limitation is operational rather than technical: self-hosting means you own upgrades, backups, security patches and the database. The README's upgrade instructions are three commands, which is honest about the mechanical cost but silent about the rest. The third is the plugin dependency. The README says the platform features a rich plugin marketplace, but the supplied material does not describe a compatibility policy between plugin versions and core versions. Given that the recent release history jumps from v1.6.0.23 in May 2026 to v2.0.0.31 in July 2026, a major version boundary, anyone running custom plugins should confirm v2 compatibility before upgrading rather than assuming it. If your store depends on a plugin that has not been updated for v2, an upgrade is a project, not a command.

BeikeShop against WooCommerce and Sylius

The honest comparison is with WooCommerce and Sylius, because they sit at different points on the same axis. WooCommerce runs as a WordPress plugin, which means the extension model is WordPress hooks and the operational model is a WordPress site. You get a vast plugin ecosystem and hosting that ranges from cheap to managed, but you inherit WordPress as the substrate, and the storefront is a theme inside it. BeikeShop inverts that: the storefront is the application, Laravel 12 is the substrate, and extension happens through the platform's own hook and event system. You get a cleaner separation between commerce logic and presentation, and you lose the WordPress ecosystem entirely. Sylius is the closer architectural relative, a Symfony-based ecommerce platform built for customization through its own extension patterns. The difference is the framework and the surrounding assumptions: Sylius expects a Symfony developer and a more deliberate build, while BeikeShop presents itself as out-of-the-box with a browser installer and a documented command-line path. If your team already writes Laravel, BeikeShop keeps you in a framework you know. If your team writes Symfony, Sylius is the shorter path. If your team does not write PHP at all, none of these three is the right choice, and a hosted platform will cost less than the engineering time.

Maintenance cost and what to verify before you commit

The maintenance story visible in the material is a rolling release cadence with patch-level version numbers. v2.0.0.31 landed in July 2026, v1.6.0.23 in May 2026, v1.6.0.19 in March 2026. That is frequent enough that you should plan upgrades as routine work rather than annual events, and the documented upgrade path is short: git pull, composer install, php artisan migrate for source installs, or overwrite files keeping .env and run php artisan migrate for package installs. The cost that is not in the README is plugin compatibility across those releases, particularly across the v1.6 to v2.0 boundary. Before adopting, verify four things. Read the licence file, because NOASSERTION is not an answer. Check the plugin you need against v2.0.0.31. Confirm your server meets the extension list, since a missing GD or BCMath will surface during installation rather than before it. And read the event and hook documentation, because the non-intrusive customization claim is the whole reason to choose this platform over a simpler cart, and the supplied material does not show how deep that API goes. If those four checks pass, the platform does what it says: a Laravel 12 storefront you can extend without forking.

Editorial conclusion

Adopt BeikeShop if you are a PHP team that wants a Laravel 12 storefront you can extend through hooks and events without forking the core, and you are willing to run your own server. Do not adopt it if you need shared hosting (the README rules it out), if you cannot read the licence text before launch, or if you expect a plugin ecosystem you can audit before installing. Verify three things first: the actual licence terms in the repository, whether the plugin you need is compatible with v2.0.0.31, and that your host provides PHP 8.2 with BCMath, GD, ZIP and the rest of the required extension list.

Official sources

  1. beikeshop/beikeshop on GitHub
  2. Issues
  3. Project website
  4. README
  5. Releases
Community notes

Community notes