- How do I install vanilo/framework in a Laravel application?
- Installation is conventional Composer work: require the package (or individual modules such as vanilo/cart or vanilo/order), register the service providers, publish the configuration and migrations, then run migrations. No additional infrastructure is required beyond what a Laravel app already runs, meaning your existing database, queue, cache, and scheduler are sufficient. You can also start with a subset of modules rather than the full framework.
- Which Laravel versions does Vanilo support?
- Vanilo major versions track Laravel majors, so each Vanilo release targets a matching Laravel generation. That also means adopting Vanilo commits you to a recurring upgrade obligation aligned with Laravel's annual release cadence. Check the composer constraints in the repository for the exact supported Laravel and PHP versions before planning an upgrade window.
- What modules does Vanilo include out of the box?
- Vanilo ships as a family of Composer packages covering products and catalog, properties (EAV-style attributes), channels, cart, checkout adjusters, orders, payments, shipments, taxation, and promotions, plus an optional admin package. A Concord-based contract and override layer (konekt/concord) sits underneath so implementations can be swapped or extended. Features like multi-warehouse inventory, returns/RMA, subscriptions, B2B price lists, and marketplace mechanics are not core and should be treated as extensions.
- Can I use Vanilo headless without the bundled admin panel?
- Yes. Vanilo is headless-first, and the admin package (vanilo/admin) is optional rather than required. This suits API-driven or storefront-agnostic architectures where you build your own frontend, SPA, or mobile client against the framework's domain logic. Teams often defer the admin decision until operations requirements are clearer.
- Can I adopt only part of Vanilo, like products, cart, and orders without payments or shipping?
- Partial adoption is realistic because the framework is split into independent packages. Taking products, cart, and orders without the payment or shipment modules reduces the blast radius for a pilot and keeps integration work focused. You can add the remaining modules later as scope expands.
- How do I override or extend Vanilo models such as Product or Order?
- Models and contracts are overridable through konekt/concord, so you can change behavior without forking the upstream packages and keep a viable upgrade path. This is the recommended way to add custom fields, business rules, or relationships. Be aware that overrides are powerful and can silently drift from upstream behavior across upgrades, so cover them with tests and review them whenever you bump versions.
- Do I have to replace my existing users table or customer model?
- Usually not. Vanilo's authentication and customer models are configurable, so an existing users table can typically be reused rather than replaced. That keeps migrations and existing auth flows intact during adoption. Confirm the mapping against your current schema early, since customer identity touches carts, orders, and admin access.
- Which payment providers and shipping carriers does Vanilo support?
- Payments and shipping are adapter-based: the framework provides the seams and contracts, and each gateway or carrier is an integration task with its own credentials, webhook handling, and reconciliation logic. Vanilo does not guarantee operational behavior on the provider side, so plan for real test scenarios per gateway. Decide which providers and carriers must be supported at launch before scoping the build.
- Will Vanilo perform well with a large product catalog and many attributes?
- The property/value modeling is flexible but can produce expensive queries at catalog scale, so search and caching architecture must be designed rather than inherited. Expect to pair the framework with a dedicated search index or carefully tuned queries as SKU counts grow. Load-test against your expected catalog size and peak concurrency instead of assuming defaults will hold.
- Is Vanilo production-ready, and what are the maintenance risks?
- The framework covers core commerce domains and is MIT licensed, with a modular architecture that maps cleanly onto standard Laravel service providers and events. The main risks are vendor concentration around a small core team, an upgrade obligation tied to Laravel majors, and a growing dependency surface across many vanilo/* and konekt/* packages. Third-party ecosystem validation is limited, so expect to own most extension code, and validate tax rules, promotion stacking, and inventory reservation with your own test scenarios. If commercial support matters, confirm availability and terms during evaluation.