Weave Code
Memory Laravel Package
orchestra/memory
Orchestra Memory gives Laravel apps a lightweight in-memory key-value store for the current request lifecycle. Use its simple put, get, has, and forget API to cache computed values and share state between components without touching persistent storage or external cache drivers.
Memory Component for Orchestra Platform
Frequently asked questions about Memory
- How do I install orchestra/memory in Laravel?
- Install it with Composer using composer require orchestra/memory. It is a conventional Laravel package with a service provider and a facade, so no manual bootstrapping is needed beyond package discovery. Publishing the config file is optional unless you need to change the default driver.
- Which Laravel and PHP versions does orchestra/memory support?
- Version 6.0.0 is documented as adding Laravel 8 and Laravel Octane support, which conventionally means older Laravel 6 and 7 support was dropped in that major release. Read the exact Laravel and PHP constraints in the package's composer.json rather than inferring them from release notes. Record those constraints verbatim before planning an upgrade, since a framework bump can dominate the estimate.
- Does Orchestra Memory work with Laravel Octane?
- Version 6.0.0 states that Octane support was added, but that claim should be verified rather than assumed for your workload. Octane correctness here means state is not leaked across long-lived workers, and the failure mode is intermittent cross-request data bleed. Exercise the package under sustained concurrency in an Octane environment before treating it as production-ready.
- What is the difference between the array, cache, and database drivers in Orchestra Memory?
- The array driver keeps values in memory for the current process and request only. The cache driver delegates storage to your configured Laravel cache store, and the database driver persists values in a table. Choose based on whether the values must survive the request or be shared across processes.
- How do I store and retrieve values with the Memory facade?
- The API is a small key-value surface: put to write a value, get to read it, has to check existence, and forget to remove it. Keys are namespaced so components can share state without colliding. This makes it a natural place to cache computed values during a single request lifecycle.
- Does Orchestra Memory persist data between requests?
- Only the persistent drivers do. The array driver holds values in memory for the current request lifecycle and is discarded afterwards, which matches the package's lightweight in-memory positioning. If you need values to survive between requests, use the cache or database driver and account for eviction and process lifecycle.
- Do I need to publish a config file or run migrations?
- Publishing the package config is optional and only needed if you want to change driver settings or defaults. A migration is required only when you use the database driver, since that driver needs a table. The array and cache drivers require no schema changes.
- How do I test code that depends on Orchestra Memory?
- Because the package is a thin facade over a driver-based repository, the simplest approach is to point the driver at the array store in your test environment so tests never touch a real cache or database. That keeps tests fast and avoids cross-test state bleeding through a shared store. If your code depends on specific repository behaviour, wrap access behind your own small interface so you can stub it cleanly.
- How is Orchestra Memory different from Laravel's config and cache?
- It occupies the space between static config files, which are deploy-coupled and developer-owned, and a bespoke settings table you would have to design and maintain yourself. It gives you a namespaced get, put, has and forget API with a selectable driver instead of roughly 50 to 200 lines of settings plumbing. That makes it an enabler rather than a differentiator in a roadmap.
- Is Orchestra Memory safe to use in production and is it actively maintained?
- The package has very low adoption, effectively no dependents, and a single maintainer, so you will be close to the only consumer and cannot borrow community battle-testing. That is a vendor-risk line item rather than an immediate blocker, but it becomes a blocker if multiple teams start depending on it. Keep it behind a thin internal abstraction so the dependency stays cheap to reverse, and pin the version explicitly.
Weaver
How can I help you explore Laravel packages today?