Vanilo: a Laravel e-commerce framework delivered as one package

Vanilo answers a packaging problem, not a storefront problem

The repository vanilophp/framework describes itself in one phrase: "The truly Laravel E-commerce Framework". The primary language is PHP, the licence is MIT, the default branch is master, and the homepage is vanilo.io. The project topics list is telling in what it leaves out. It contains e-commerce, e-commerceplatform, laravel, laravel-package, php, php8 and hacktoberfest, but no entry for theming, payment provider or storefront design.

The stated aim in the README is that "Laravel developers" can "rapidly" create E-commerce applications with "pleasure". Read literally, that is a claim about development speed inside an existing Laravel application, not about handing a shop to a non-developer. A team already running Laravel with users, sessions and a database connection is the natural buyer. A team that wants a turnkey store with a theme, an admin panel and a payment gateway already wired up is not, because the README points to neither a bundled theme nor a starter store, and the documentation link leads to a general documentation entry point rather than a demo.

So the useful question is not whether Vanilo is good e-commerce. It is whether a Composer package is the right container for your store, and whether the boundaries of that container are clear enough for you to plan around.

Version 6.0.0 hardens the PHP and Laravel compatibility window

The stable line is 6.x, and the README names 6.0.0 as the latest stable release, released on September 25, 2026. It states that Vanilo v6.0 supports Laravel 12.61+ and 13.12+ versions and PHP 8.4 - 8.5.

Those two lines together give you a hard floor. Laravel 12.61 and 13.12 are minimums, not suggestions, so an application parked on an earlier Laravel 12 patch cannot simply bump the package. The PHP range is a two-version window, which is unusually narrow by the standards of a Laravel package and means an application stuck on PHP 8.3 has no supported combination to fall back on. That is the single most likely reason to skip the project rather than a shortcoming of the design.

The three most recent releases listed are 6.0.0 on 2026-09-25, 5.2.1 on 2026-05-28 and 5.2.0 on 2026-04-21. The 6.0.0 tag lands about four months after 5.2.1, which is the point at which a major version bump normally signals a batch of breaking changes. The README does not summarise them, so the changelog becomes mandatory reading rather than optional.

One inconsistency is worth flagging early. The stable section says 6.x, but the roadmap link in the same README points at vanilo.io/docs/5.x/roadmap, a documentation path under the previous major version. Anyone who follows that link expecting the current roadmap lands one version behind.

No install command in the README, so the docs are the install guide

The README contains no installation section. There is no composer require line, no service provider snippet, no environment variables and no database migration step. The only trace of the package on a distribution channel is a Packagist badge pointing at packagist.org/packages/vanilo/framework, which fixes the package name as vanilo/framework.

That makes the documentation at vanilo.io/docs/ the actual installation guide, and it is also where you need to look for the compatibility matrix that the README compresses into a single line:

Laravel 12.61+ and 13.12+ versions and PHP 8.4 - 8.5

The practical first step for a new user is therefore not to type anything but to read the documentation and the composer manifest at the top of the repository, which lists the framework requirements. If the documentation has drifted from the tagged release, composer.json is the authority, since it is what the resolver actually reads. Confirm the required PHP extensions there too, because the README does not list any.

For a first real use, the sensible sequence is: pin the package to 6.0.0, confirm the Laravel and PHP floors match your environment, then work through the documentation for model and configuration names before wiring anything into a route. A community route exists for questions that the documentation does not answer, through a new issue on the GitHub repository, alongside a Telegram channel, a Discord server, an X account and a newsletter sign-up on the project homepage.

src/, build-tools/ and module-status.md describe a layered codebase

The top level of the repository lists .editorconfig, .gitattributes, .github/, .gitignore, .styleci.yml, CONTRIBUTING.md, Changelog.md, LICENSE.md, README.md, SECURITY.md, build-tools/, composer.json, module-status.md, phpunit.xml.dist and src/.

Most of these entries are self-describing, with one exception worth attention: module-status.md. Nothing in the README explains what that file records, and its name suggests it tracks the state of individual modules or components within the framework. If it does, it is the place to look for the difference between a mature part of Vanilo and a newly added one, and the place to check whether a feature you intend to depend on is still moving. Confirm that by opening the file rather than assuming it, because the README leaves the question open.

The presence of src/ together with composer.json is the standard shape of a Laravel package: the source lives under src/, and the manifest declares how the package attaches to the host application. The separate build-tools/ directory suggests a second toolchain, probably for asset or front-end compilation, distinct from PHP dependencies. The README does not describe either directory, so any conclusion about the internal architecture stays tentative.

Automated checks define the real rules for a contribution

The contribution rules live outside the README. The tests badge links to a GitHub Actions workflow file at .github/workflows/tests.yml on the master branch, and the repository root carries phpunit.xml.dist, which is the standard PHPUnit configuration file. Together they imply a test suite that runs in continuous integration and a PHPUnit configuration that defines how that suite is executed, including which directories and suites are included.

Style is handled separately. A .styleci.yml file sits at the root and the README carries a StyleCI badge, so formatting and code style are checked by that service rather than left to reviewers. The .editorconfig and .gitattributes entries cover editor and line ending behaviour, and .gitignore keeps build output out of the index.

Two files have particular value for anyone planning to contribute. CONTRIBUTING.md holds the project's own process expectations, and SECURITY.md is the designated place for responsible disclosure. Their existence is visible from the file listing even though the README does not mention either, and the topics include hacktoberfest, which means the project does receive outside pull requests and that a contribution has to clear these automated gates to land.

For an adopter, the practical implication is narrower but real: the framework is under continuous automated scrutiny, and a fork that skips the StyleCI and PHPUnit steps will not match the upstream codebase's standards.

The MIT licence and the absence of a versioning policy

The licence is MIT, stated in the repository listing and marked by a badge on the README, with the text held in LICENSE.md. That is the most permissive common choice and it removes the usual commercial restriction question, although how it interacts with a commercial extension is a separate matter that no document in this repository addresses.

The repository also contains Changelog.md, which the README never links to or summarises. Given that 6.0.0 followed 5.2.1 across a roughly four month gap, that file is where breaking changes for the major bump should be recorded, and it is the first thing to read before upgrading an existing 5.x store.

Maintenance is recent by the numbers in the file listing. The last push was on 2026-10-19, and the three most recent releases listed are dated 2026-04-21, 2026-05-28 and 2026-09-25, so tags have continued through 2026 rather than stopping. The README also points to a roadmap for upcoming versions, which is the closest thing to a stated direction. No support policy, no long term support branch and no upgrade support window appear anywhere in the README, so the cost of staying current rests entirely on following the changelog yourself.

Editorial conclusion

Adopt Vanilo if your team already runs Laravel and wants e-commerce primitives as a Composer dependency rather than a separate service. Do not adopt it if you need a ready-made storefront, because the README names no theme, admin panel or sample store. Before writing code, verify three things in the documentation at vanilo.io/docs/: the actual install command and required configuration, the breaking changes listed in Changelog.md for the move from 5.x to 6.0.0, and the catalogue and order model names you will bind to your own templates.

Frequently asked questions

Official sources

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