Bagisto: a Laravel multi-vendor marketplace you install with Composer or Docker

What Bagisto solves, and who ends up running it

The README frames Bagisto as an open-source Laravel eCommerce and multi-vendor marketplace platform for building scalable online commerce solutions, built with Laravel and Vue.js. The problem it addresses is concrete: most teams that need vendor onboarding, per-vendor catalogues, commission handling and a shared checkout end up writing those features on top of a general-purpose framework. Bagisto ships them as part of the application, so the work starts at configuration rather than at a blank schema.

The audience is narrower than the tagline suggests. Bagisto is a PHP application with a Laravel backend and a Vue frontend, and the repository is organised like one: app/, bootstrap/, config/, database/, routes/, resources/, tests/, plus an artisan entry point and a composer.json. The people who get value from it are teams that already run Laravel, understand Eloquent models and service providers, and are comfortable reading framework code when a behaviour is not documented. Teams that want a hosted dashboard with no deployment surface are not the audience, even though a managed cloud hosting option is offered on the project site.

The stated scope covers three shapes: a single-vendor store, a B2B eCommerce platform, and a multi-vendor marketplace. Those are not three separate products. They are the same codebase with different configuration and different vendor-facing modules enabled, which is why the repository carries a packages/ directory alongside the core application.

How the Laravel application, packages directory and queue config fit together

The architecture visible in the repository is a standard Laravel application with a modular layer. The core lives in app/, routes/ and resources/, while packages/ holds the modules that extend it. The composer.json at the root is the dependency entry point, and the .env.example shows the runtime services the application expects to talk to: MySQL on DB_PORT=3306, Redis on REDIS_PORT=6379, and a dynamic SMTP mailer configured through MAIL_MAILER=bagisto-dynamic-smtp rather than a fixed mail transport.

Two configuration choices reveal how the platform is meant to be deployed. QUEUE_CONNECTION defaults to sync, which means queued work runs inline during the request. That is fine on a laptop and wrong on a storefront handling real order volume, where catalogue imports, order notifications and index updates should go through a worker. CACHE_STORE defaults to file, and FILESYSTEM_DISK to public, so a default install keeps state on the local disk. Moving to Redis and object storage is a configuration change, not a code change, but it is a change you have to make deliberately.

The docker-compose.yml file goes further than the minimum. It defines the laravel.test application container built from vendor/laravel/sail/runtimes/8.3, and it declares dependencies on mysql, redis, elasticsearch, kibana and mailpit. Elasticsearch appearing in that list is the clearest signal of intended scale: product search and filtering are expected to run against an index rather than raw SQL LIKE queries once the catalogue grows. The compose file also maps the application port through ${APP_PORT:-80} and the Vite dev server through ${VITE_PORT:-5173}, with VITE_HOST and VITE_PORT exposed in .env.example for the frontend build.

Installing Bagisto with Composer or Docker and reaching the admin

The README does not inline the install steps. It links to the installation guide at devdocs.bagisto.com, states that Bagisto can be installed with or without Composer, and points at a separate Docker installation section of that same guide. The repository ships the files those paths rely on: composer.json, artisan, .env.example and docker-compose.yml. What follows is what those files contain, not a run I performed.

The .env.example file is the starting point for a manual install. It sets APP_NAME=Bagisto, APP_ENV=local, APP_URL=http://localhost and APP_ADMIN_URL=admin, and it leaves APP_KEY and the database credentials empty.

cp .env.example .env

The example configures the database connection and the queue driver as follows, which you would edit before booting the application.

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
QUEUE_CONNECTION=sync
CACHE_STORE=file

The admin panel is mounted at a path rather than a subdomain. APP_ADMIN_URL is set to admin in the example, so the back office is reached at /admin relative to APP_URL, which defaults to http://localhost. Frontend assets are built with Vite, and package.json defines exactly two scripts, dev and build.

npm run build

If you prefer the container route, the compose file defines a laravel.test service that mounts the working directory at /var/www/html and depends on mysql, redis, elasticsearch, kibana and mailpit. The application port is ${APP_PORT:-80} and the Vite port is ${VITE_PORT:-5173}, both overridable from .env.

docker compose up -d

What you should see after this is a storefront at APP_URL and an admin login at APP_URL plus the APP_ADMIN_URL value. The example also names three mail identities you will want to change before launch: ADMIN_MAIL_ADDRESS, CONTACT_MAIL_ADDRESS and MAIL_FROM_ADDRESS, all defaulting to example.com addresses.

Where Bagisto gets expensive: the services it expects beside it

The honest limitation is not in the PHP code. It is in the dependency list. The compose file declares depends_on for mysql, redis, elasticsearch, kibana and mailpit. A team that wants a small single-vendor shop has to decide whether to run that stack or to strip it down, and stripping it down means changing QUEUE_CONNECTION, CACHE_STORE and the search backend away from their defaults. The README does not document which of those services are optional, so the compose file is the only signal, and it lists them as hard dependencies of the application container.

Elasticsearch is the sharpest example. It is a JVM service with its own memory profile, and running it alongside Kibana on the same host as the application is a real cost for a catalogue of a few hundred products. If you keep the default file cache and sync queue instead, you avoid those containers but you accept inline queue processing and local-disk cache, which will not survive a multi-instance deployment.

The second limitation is version discipline. The newest tag in the release list is v2.5.0-beta3, published on 2026-09-17. The stable line is v2.4.11, published on 2026-09-16, and the default branch is 2.4. If a feature you need only exists in the 2.5 beta, you are running beta software on a storefront. The repository root contains an UPGRADE.md file, which tells you upgrades between versions are treated as a documented procedure rather than a drop-in composer update.

The third is the extension model. Bagisto's value comes partly from modules, and the packages/ directory is where they live. The README does not enumerate what ships in that directory, so the only way to know whether a capability is core or an add-on is to read the repository. A store that depends on a module maintained outside the core repository inherits that module's release cadence.

Bagisto against WooCommerce, Magento and Aimeos

The comparison that matters is not feature count, it is where the code lives. WooCommerce is a WordPress plugin. Your store is a WordPress site with WooCommerce activated, and everything you build sits inside WordPress conventions: hooks, shortcodes, custom post types for products. Bagisto is the opposite arrangement. It is a full Laravel application that owns its routes, models and migrations, and WordPress is nowhere in the stack. If your team is fluent in WordPress, WooCommerce is the shorter path; if your team is fluent in Laravel, Bagisto removes the layer of translation between the framework you know and the commerce logic.

Magento, now Adobe Commerce in its commercial form, occupies the same territory as Bagisto: a PHP commerce platform with a module system and a heavy service footprint. The difference an adopter will notice first is licensing and packaging. Bagisto is MIT-licensed and installs from Packagist as bagisto/bagisto, with the whole application in one repository you can read end to end. Magento's ecosystem has a longer history and a larger body of third-party extensions, and that history comes with a correspondingly larger surface to learn.

Aimeos is the closest comparison on architecture. It is also a PHP eCommerce framework, and it is also designed to be embedded in a host application rather than deployed as a finished store. The practical divergence is the host framework: Bagisto is built specifically around Laravel and Vue.js, with a Laravel Sail based compose file and Vite for assets, so a Laravel team gets a familiar shape. Aimeos is not tied to Laravel in the same way, which makes it more portable and less immediately familiar to a Laravel developer. Neither choice is wrong; the question is whether you want the commerce layer to be a Laravel application or a library inside one.

Licence, upgrade cost and what the MIT terms actually cover

Bagisto is released under the MIT licence, and the LICENSE file sits at the repository root alongside composer.json. MIT is permissive: it allows commercial use, modification and redistribution, and it requires that the copyright notice and permission notice be preserved. It does not impose copyleft obligations on your own code, which is the practical reason a company can build a private storefront on top of it without publishing its customisations.

One thing the licence does not do is cover the services around the application. The project site offers a managed cloud hosting product, and the README links to it as a separate commercial offering. Running Bagisto under MIT says nothing about the terms of that hosting, and nothing about third-party extensions, which carry their own licences. If you plan to redistribute a modified Bagisto as a product, the MIT text is the document to read, not this article.

Upgrade cost is where the operational budget goes. The repository ships UPGRADE.md, and the release history shows a stable line (v2.4.11) running in parallel with a beta line (v2.5.0-beta3). That parallel structure is normal for a project of this size, and it also means an upgrade is a decision with a branch attached. The CHANGELOG.md at the root is the file to read before moving between versions. Because Bagisto is a full application rather than a library, upgrading means merging changes into code you may have edited in app/, resources/ and config/, not just bumping a version constraint in composer.json.

Editorial conclusion

Adopt Bagisto if you have PHP and Laravel engineers who want to own the storefront code and need vendor onboarding, commissions and per-vendor catalogues without writing them. Do not adopt it if you have no PHP capacity, or if you need a stable 2.5 feature set today, because v2.5.0-beta3 is the newest tag and v2.4.11 is the stable release. Before committing, read UPGRADE.md in the repository root, confirm whether the packages/ directory holds the modules you actually need, and decide whether you are running the docker-compose.yml Sail stack or your own MySQL, Redis and Elasticsearch services.

Frequently asked questions

Official sources

1. bagisto/bagisto on GitHub
2. License: MIT
3. Project website
4. README
5. Releases